How IDProva Maps to NIST 800-53 Controls

The Compliance Gap AI Agents Create

When an AI agent reads a classified document, modifies a database record, or invokes a privileged API, that action needs to appear in an audit trail. Compliance frameworks like NIST SP 800-53 Rev 5 require it. Auditors expect it. Regulations demand it.

But most agent frameworks generate no audit records at all — or at best, application-level logs that lack the structure, integrity protection, and identity attribution that compliance frameworks require. The result is a growing gap between what organisations deploy (autonomous agents performing sensitive actions) and what they can prove to auditors (who did what, when, and under what authority).

This is not an academic problem. Organisations operating under FedRAMP, FISMA, DISP, or similar frameworks already face questions about how AI agents fit into their control environment. The answer, too often, is: they don’t. The agents operate in a compliance blind spot.

IDProva was designed to close this gap — not through a separate compliance layer bolted on after the fact, but through protocol primitives that produce compliance-ready artifacts as a natural byproduct of operation.

The Core Mapping: Action Receipts to NIST Controls

IDProva’s Action Receipts are hash-chained, signed records that carry specific fields designed to satisfy compliance requirements. Here is how those fields map to the NIST 800-53 Rev 5 controls that auditors most commonly evaluate:

AU-2: Audit Events

Requirement: The system must be capable of auditing identified events.

How IDProva satisfies it: Every significant action performed by an IDProva-authenticated agent produces an Action Receipt. The protocol defines which events are auditable — tool calls, resource access, delegation operations, identity lifecycle events. Organisations can configure additional auditable events based on their risk assessment, but the baseline is built into the protocol.

Receipt fields: action.type, action.resource, action.operation

AU-3: Content of Audit Records

Requirement: Audit records must contain sufficient information to establish what type of event occurred, when it occurred, where it occurred, the source of the event, the outcome, and the identity of individuals/subjects associated with the event.

How IDProva satisfies it: This is where Action Receipts are purpose-built for compliance. Each receipt contains:

AU-3 Element	Receipt Field	Example Value
What (event type)	action.type	mcp:tool-call
When (timestamp)	timestamp	2026-02-24T14:30:00Z
Where (resource)	action.resource	filesystem
Source (agent identity)	agent	did:idprova:example.com:kai
Outcome	action.result	success
Authority	delegationRef	dat-2026-02-24-a1b2c3d4

The delegationRef field is particularly significant — it links the action to the specific Delegation Attestation Token that authorised it, enabling auditors to trace authority back to the human principal.

AU-8: Time Stamps

Requirement: Use reliable time sources and record time stamps in audit records.

How IDProva satisfies it: All Action Receipt timestamps use ISO 8601 format with timezone information. The protocol recommends NTP-synchronised clocks. Receipt verification can optionally check timestamp reasonableness — detecting receipts with timestamps significantly in the future or inconsistent with their sequence position.

Receipt field: timestamp (ISO 8601)

AU-9: Protection of Audit Information

Requirement: Protect audit information and audit logging tools from unauthorised access, modification, and deletion.

How IDProva satisfies it: This is where hash chaining becomes a compliance control, not just an engineering pattern. Each Action Receipt includes:

• hash: The BLAKE3 hash of the current receipt
• previousHash: The BLAKE3 hash of the preceding receipt
• signature: The acting agent’s cryptographic signature over the receipt

If any receipt in the chain is modified, inserted, or removed, the hash chain breaks. Verifiers detect tampering by recomputing hashes and checking continuity. The signature prevents forgery — an attacker cannot create a valid receipt without the agent’s private key.

This provides cryptographic tamper evidence, which is a stronger guarantee than filesystem-level access controls on log files.

AU-10: Non-repudiation

Requirement: Protect against an individual falsely denying having performed a particular action.

How IDProva satisfies it: Each Action Receipt is signed by the acting agent’s key (the same key registered in their DID Document). The agent cannot deny performing an action without denying its own identity. Combined with the delegation chain — which traces authority from the agent through intermediary delegations back to the human principal — this provides end-to-end non-repudiation.

Receipt field: signature (Ed25519 or hybrid Ed25519 + ML-DSA-65)

AU-12: Audit Record Generation

Requirement: The system must generate audit records for auditable events.

How IDProva satisfies it: Receipt generation is automated and built into the protocol layer, not left to application code. When an agent performs an action through an IDProva-authenticated channel, the receipt is generated as part of the action lifecycle. This eliminates the common failure mode where developers forget to add logging, or where log generation fails silently.

IA-2: Identification and Authentication

Requirement: Uniquely identify and authenticate organisational users (or processes acting on behalf of users).

How IDProva satisfies it: Every agent has a unique did:idprova: identifier registered in a DID Document that contains its public keys, controller reference, and metadata. Authentication uses cryptographic signature verification — the agent proves it holds the private key corresponding to its DID Document. This is stronger than shared-secret authentication (API keys) and carries richer identity semantics than OAuth client credentials.

Receipt field: agent (DID URI), verified against the agent’s DID Document

AC-6: Least Privilege

Requirement: Employ the principle of least privilege, allowing only authorised access.

How IDProva satisfies it: Delegation Attestation Tokens (DATs) enforce least privilege through scoped, constrainable delegation. Each DAT specifies exactly which actions the agent may perform using a structured scope grammar (namespace:resource:action). Constraints further limit behaviour — rate limits, IP restrictions, maximum action counts.

Critically, scope narrows through delegation chains. If Agent A has mcp:tool:*:* and delegates to Agent B, it can grant at most mcp:tool:*:* and typically grants less (e.g., mcp:tool:filesystem:read). Agent B cannot escalate its own privileges.

Every Action Receipt references its authorising DAT, creating an enforceable, auditable link between the action performed and the permission that authorised it.

Beyond NIST: ISM and SOC 2 Coverage

IDProva’s compliance mapping extends beyond NIST 800-53. The same protocol primitives satisfy controls in other frameworks:

Australian ISM

ISM Control	IDProva Mechanism
ISM-0585 (Process identification)	Agent DID in every receipt
ISM-0988 (Privileged action logging)	Receipts generated for all actions, with scope-based privilege classification
ISM-0580 (Audit log integrity)	Hash chaining with BLAKE3
ISM-1405 (Event log content)	Receipt fields satisfy who/what/when requirements

SOC 2

SOC 2 Criteria	IDProva Mechanism
CC6.1 (Logical access security)	DID-based identity, cryptographic authentication
CC6.2 (Scope of authorised access)	DAT scopes referenced in every receipt
CC6.3 (Audit trail integrity)	Hash-chained, signed receipt chains
CC7.2 (System operations monitoring)	Receipt streams for real-time and retrospective analysis

Compliance by Design, Not Compliance as Afterthought

The traditional approach to agent compliance is reactive: deploy agents, then figure out how to monitor and audit them. This leads to bolt-on logging, incomplete coverage, and the perpetual risk that the compliance layer drifts out of sync with what agents actually do.

IDProva inverts this. Compliance artifacts — identity attestation, scoped delegation, tamper-evident audit trails — are generated as part of normal agent operation. An agent that authenticates with IDProva and operates under a DAT automatically produces AU-2 compliant audit events, AU-3 compliant record content, AU-9 compliant integrity protection, and AU-10 compliant non-repudiation. No additional logging infrastructure required.

This matters for organisations operating under multiple compliance frameworks simultaneously. The same Action Receipt satisfies NIST 800-53 AU-3, ISM-1405, and SOC 2 CC6.3. One protocol primitive, multiple control mappings.

What This Means for Your Next Audit

If you are preparing for a FedRAMP assessment, DISP accreditation, or SOC 2 Type II audit and your environment includes AI agents, the auditor will ask: how do you identify agents, scope their authority, and audit their actions?

With IDProva, the answer is not “we have application logs.” The answer is: “Every agent has a verifiable cryptographic identity. Every delegation is scoped, time-bounded, and revocable. Every action produces a signed, hash-chained receipt that references the delegation that authorised it. Here is the chain — verify it yourself.”

That is a fundamentally different conversation.

Read the full compliance mapping documentation or explore the Action Receipts specification to see the protocol details.