Australian ISM
The Australian Information Security Manual (ISM) is the Australian Signals Directorate’s (ASD) framework for securing Australian Government ICT systems. IDProva’s identity, delegation, and audit capabilities directly address ISM controls across multiple security domains.
This mapping targets OFFICIAL: Sensitive and PROTECTED maturity levels and is relevant to agencies deploying AI agent systems subject to ISM compliance obligations. It is also relevant for IRAP assessors evaluating the security posture of such deployments.
Access Control
Section titled “Access Control”Access control is one of the most directly addressed ISM chapters. DATs provide cryptographically enforced, scope-limited, time-bounded access tokens — a significant improvement over traditional API key or role-based approaches for agent access.
ISM-0430 — Identification of Users and Processes
Section titled “ISM-0430 — Identification of Users and Processes”Requirement: Users and processes accessing systems are uniquely identified.
IDProva Coverage: ✅ Full
Every AI agent is assigned a unique did:idprova: identifier — a W3C Decentralized Identifier that is globally unique, cryptographically bound to the agent’s public key, and published in a verifiable registry. Unlike service accounts or shared API keys, an agent DID cannot be reused across agents.
Evidence for IRAP assessment: AID Document for each agent, available via GET /v1/aid/:id on the agency’s IDProva registry.
ISM-0431 — Authentication of Users and Processes
Section titled “ISM-0431 — Authentication of Users and Processes”Requirement: Users and processes are authenticated before being granted access to systems and their resources.
IDProva Coverage: ✅ Full
Authentication in IDProva is cryptographic. A DAT presented by an agent carries an Ed25519 signature. The verifier checks this signature against the agent’s public key from their AID Document — no shared secrets, no password transmission. An agent that cannot produce a valid signature is rejected.
For MCP integrations, authentication occurs at session establishment. For HTTP APIs, it occurs on every request via the Authorization: IDProva <token> header.
ISM-0432 — Authorisation of Users and Processes
Section titled “ISM-0432 — Authorisation of Users and Processes”Requirement: Access to systems and their resources is limited to what is required for users and processes to undertake their duties.
IDProva Coverage: ✅ Full — via DAT scope enforcement
DAT scope grammar (namespace:resource:action) enables fine-grained, resource-level authorisation that is:
- Explicit — agents only have permissions that appear in their DAT
- Enforceable — verifiers check scope before executing any action
- Auditable — scope is recorded in every Action Receipt
- Time-bounded — authority automatically expires
The scope reduction rule ensures sub-agents can never acquire permissions broader than their parent delegation.
ISM-1508 — Privileged Access Management
Section titled “ISM-1508 — Privileged Access Management”Requirement: Privileged access to systems is controlled and monitored.
IDProva Coverage: ✅ Full
Privileged agent actions are constrained at the DAT level:
- Privileged scopes (e.g.,
idprova:aid:write,mcp:tool:admin:*) require explicit inclusion in the issuer’s DAT - The
maxActionsconstraint limits blast radius of a compromised privileged agent - Every privileged action produces a signed Action Receipt, creating an immutable audit trail
- Privileged DATs should use short expiry windows (1–4 hours) for high-risk operations
Evidence for IRAP assessment: DAT tokens with privileged scopes + corresponding Action Receipt logs showing privilege usage.
Cryptography
Section titled “Cryptography”ISM-0336 — Cryptographic Algorithms
Section titled “ISM-0336 — Cryptographic Algorithms”Requirement: Approved cryptographic algorithms are used to protect the confidentiality, integrity, and authenticity of information.
IDProva Coverage: ✅ Full
IDProva uses ASD-approved cryptographic algorithms:
| Algorithm | Use | Standard |
|---|---|---|
| Ed25519 | Signing AIDs, DATs, receipts | FIPS 186-5 / RFC 8037 |
| BLAKE3 | Receipt hash chaining | Modern, NIST-compatible |
| SHA-256 | Config attestation, interoperability hashing | FIPS 180-4 |
| ML-DSA-65 | Post-quantum signature (hybrid, planned) | FIPS 204 |
The hybrid Ed25519 + ML-DSA-65 scheme provides defence in depth: an attacker must compromise both classical and post-quantum keys simultaneously to forge signatures.
ISM-0457 — Key Management
Section titled “ISM-0457 — Key Management”Requirement: Cryptographic keys are generated, distributed, stored, used, and destroyed in a secure manner.
IDProva Coverage: ✅ Partial (full lifecycle management planned for v0.2)
| Key Lifecycle Phase | IDProva Support |
|---|---|
| Generation | idprova keygen — OS CSPRNG, Ed25519 |
| Distribution | Public key published in AID Document via registry |
| Storage | Private key stored locally; HSM recommended for high-assurance |
| Use | Signing DATs and receipts; verification via AID Document |
| Rotation | AID update with new verification method |
| Destruction/Revocation | AID deactivation — all DATs issued by agent become invalid |
Implementation guidance for PROTECTED: Store private keys in a FIPS 140-2 Level 2+ HSM. Do not store private keys on shared infrastructure.
ISM-0459 — Transport Layer Security
Section titled “ISM-0459 — Transport Layer Security”Requirement: TLS is used to protect information in transit.
IDProva Coverage: ✅ Complementary
IDProva protocol messages (DATs, receipts) include cryptographic integrity at the application layer regardless of transport. This means a compromised TLS session cannot result in undetected tampering of identity tokens. TLS remains required for confidentiality. Use TLS 1.3 with ASD-approved cipher suites for all registry and API communications.
System Monitoring
Section titled “System Monitoring”ISM-0580 — Audit Logging
Section titled “ISM-0580 — Audit Logging”Requirement: Audit logs are created for significant events and are protected from unauthorised modification.
IDProva Coverage: ✅ Full
Action Receipts are signed audit records — each receipt is protected from modification by:
- An Ed25519 signature over the entire receipt payload (the agent cannot deny authorship)
- A BLAKE3 hash chain linking each receipt to its predecessor (insertion, deletion, or modification of any receipt breaks the chain)
Any party with access to the agent’s public key can independently verify the integrity of the receipt chain.
Evidence for IRAP assessment: Receipt log files (JSONL format) + output of idprova receipt verify receipts.jsonl.
ISM-0585 — Identification in Audit Logs
Section titled “ISM-0585 — Identification in Audit Logs”Requirement: Audit logs contain sufficient detail to identify the user or process that performed each action.
IDProva Coverage: ✅ Full
Every Action Receipt contains:
agent.did— the cryptographically verifiable identity of the acting agentdelegation.issuer— the DID of the human or system that authorised the agentdelegation.jti— the specific token ID, traceable back to the full delegation chainagent.trustLevel— the verified trust level of the agent at time of action
This provides complete attribution from action → agent → authorising principal.
ISM-0988 — Logging of Privileged Actions
Section titled “ISM-0988 — Logging of Privileged Actions”Requirement: Privileged actions are logged, including the identity of the user performing the action.
IDProva Coverage: ✅ Full
Privileged actions (those using privileged scopes in DATs) automatically produce Action Receipts. The receipt includes the scope used, the delegation that granted it, and the agent identity. Logging is enforced via the requireReceipt: true constraint in privilege-granting DATs.
ISM-1405 — Centralised Logging
Section titled “ISM-1405 — Centralised Logging”Requirement: Audit logs from multiple sources are collected and correlated in a centralised system.
IDProva Coverage: ✅ Partial
Receipt logs are produced per-agent in JSONL format. Centralised log aggregation (shipping to a SIEM) is the responsibility of the deployment environment. IDProva receipts are structured (JSON) with consistent field names, making aggregation and SIEM correlation straightforward.
Implementation guidance: Ship receipt JSONL files to your SIEM (Splunk, Microsoft Sentinel, etc.) using standard log forwarders. Use agent.did as the correlation key across systems.
ISM-0859 — System Configuration Logging
Section titled “ISM-0859 — System Configuration Logging”Requirement: Changes to system configurations are logged.
IDProva Coverage: ✅ Partial
The configAttestation field in AID Documents stores a hash of the agent’s configuration at deployment time. Changes to the agent’s configuration (system prompt, tool definitions, model version) require a new attestation hash and an AID update, which is logged in the registry.
Vulnerability Management
Section titled “Vulnerability Management”ISM-1698 — Post-Quantum Cryptography Readiness
Section titled “ISM-1698 — Post-Quantum Cryptography Readiness”Requirement: (Emerging) Systems implement or plan to implement post-quantum cryptographic algorithms.
IDProva Coverage: ✅ Roadmap committed
IDProva’s hybrid signature scheme is designed for PQC readiness from day one. The architecture accommodates ML-DSA-65 (FIPS 204) hybrid signatures with Ed25519, with the PQ component activated in v0.2. The pqalg and pqkid JWS header fields are already reserved in the protocol specification.
Summary Table
Section titled “Summary Table”| ISM Control | Chapter | IDProva Feature | Coverage |
|---|---|---|---|
| ISM-0430 | Access Control | did:idprova: unique agent identifiers | ✅ Full |
| ISM-0431 | Access Control | Ed25519 signature authentication | ✅ Full |
| ISM-0432 | Access Control | DAT scope enforcement + scope reduction | ✅ Full |
| ISM-1508 | Access Control | Privileged DAT constraints + receipt audit | ✅ Full |
| ISM-0336 | Cryptography | Ed25519, BLAKE3, SHA-256, ML-DSA-65 (planned) | ✅ Full |
| ISM-0457 | Cryptography | Key generation, rotation, revocation lifecycle | ✅ Partial |
| ISM-0459 | Cryptography | Application-layer integrity + TLS guidance | ✅ Complementary |
| ISM-0580 | Monitoring | Signed, hash-chained Action Receipts | ✅ Full |
| ISM-0585 | Monitoring | Agent DID + delegation chain in every receipt | ✅ Full |
| ISM-0988 | Monitoring | Privileged action receipts via requireReceipt | ✅ Full |
| ISM-1405 | Monitoring | Structured JSONL receipt logs for SIEM ingestion | ✅ Partial |
| ISM-0859 | Monitoring | configAttestation hash in AID Documents | ✅ Partial |
| ISM-1698 | Vulnerability | ML-DSA-65 hybrid PQC roadmap | ✅ Roadmap |
IRAP Assessment Guidance
Section titled “IRAP Assessment Guidance”For IRAP assessors evaluating systems that include AI agents using IDProva, the following evidence artefacts are relevant:
| Assessment Area | Evidence | Source |
|---|---|---|
| Agent identity register | AID Documents for all agents | Registry GET /v1/aid/:id |
| Access authorisation baseline | DAT tokens issued to each agent | idprova dat inspect <token> |
| Audit log integrity | Receipt chain verification report | idprova receipt verify receipts.jsonl |
| Privilege usage | Receipts for privileged-scope actions | Receipt log filtered by action.type |
| Config baseline | configAttestation values for all agents | AID Documents |
| Key management | Key rotation log | Registry AID update history |
| Cryptographic compliance | Algorithm metadata | GET /v1/meta on registry |
Scope boundary note: IDProva addresses identity, delegation, and audit evidence for the AI agent layer. The underlying compute infrastructure, network controls, and data classification controls remain in scope for the broader system assessment.
Related
Section titled “Related”- NIST 800-53 Mapping — US federal control mapping
- SOC 2 Mapping — SOC 2 Trust Services Criteria
- Concepts: Audit — Understanding Action Receipts
- Cryptography Specification — Algorithm details