NIST 800-53 Mapping
IDProva’s three protocol primitives — Agent Identity Documents (AIDs), Delegation Attestation Tokens (DATs), and Action Receipts — map directly to NIST SP 800-53 Rev 5 controls. This mapping was developed in conjunction with Tech Blaze’s submission to the NIST Collaborative AI Security Initiative (NIST-2025-0035).
Audit and Accountability (AU)
Section titled “Audit and Accountability (AU)”Action Receipts are designed from the ground up to satisfy AU requirements — tamper-evident, attributable, time-stamped records of every agent action.
AU-2 — Event Logging
Section titled “AU-2 — Event Logging”Requirement: Identify the types of events the system is capable of logging in support of the audit function.
IDProva Coverage: ✅ Full
Every agent action that produces an Action Receipt constitutes a loggable event. The action.type field uses a structured taxonomy (mcp:tool:call, mcp:resource:read, http:request, etc.) that maps to an enumerated event catalogue.
| Protocol Field | Evidence Provided |
|---|---|
action.type | Event type taxonomy |
action.target | Resource or endpoint acted upon |
action.result.status | Success/failure outcome |
agent.did | Identity of the acting agent |
Implementation guidance: Define your agent event taxonomy before deployment. Map each tool call, resource access, and API interaction to an action.type value. Maintain this taxonomy as a configuration artefact for assessors.
AU-3 — Content of Audit Records
Section titled “AU-3 — Content of Audit Records”Requirement: Ensure audit records contain sufficient information to establish what events occurred, the sources of the events, and the outcomes.
IDProva Coverage: ✅ Full
Each receipt answers: who (agent DID, delegation chain), what (action type, target, parameters), when (ISO 8601 timestamp), where (environment, session ID), and outcome (result status).
| AU-3 Sub-requirement | Receipt Field |
|---|---|
| Date and time | timestamp (ISO 8601, millisecond precision, UTC) |
| Type of event | action.type |
| Subject identity | agent.did, agent.trustLevel |
| Outcome | action.result.status, action.result.summary |
| Source identity | delegation.issuer, delegation.jti |
| Object identity | action.target |
AU-8 — Time Stamps
Section titled “AU-8 — Time Stamps”Requirement: Use internal system clocks to generate time stamps for audit records that can be mapped to UTC.
IDProva Coverage: ✅ Full
The timestamp field uses ISO 8601 with millisecond precision in UTC. The timestamp is included in the signed payload — tampering is cryptographically detectable.
Implementation guidance: Configure NTP synchronisation on all agent runtime environments. For high-assurance deployments, use a stratum-1 time source.
AU-9 — Protection of Audit Information
Section titled “AU-9 — Protection of Audit Information”Requirement: Protect audit information and tools from unauthorised access, modification, and deletion.
IDProva Coverage: ✅ Full — via cryptographic means
The hash-chained receipt log provides tamper evidence without requiring access controls on log storage alone. Each receipt contains:
chain.previousHash— cryptographic link to prior receiptsignature— Ed25519 signature over the entire receipt payloadchain.sequenceNumber— detects insertions and deletions
Tampering with any receipt breaks the hash chain, detectable via idprova receipt verify.
Implementation guidance: Store receipt logs in append-only storage (S3 Object Lock, WORM storage). The hash chain detects tampering even on mutable storage, but immutable storage provides defence in depth.
AU-10 — Non-repudiation
Section titled “AU-10 — Non-repudiation”Requirement: Provide irrefutable evidence that an individual (or process) took a specific action.
IDProva Coverage: ✅ Full
Each Action Receipt is signed by the agent’s private Ed25519 key. The corresponding public key is published in the agent’s AID Document. A valid signature proves the agent holding that private key authored the action. The delegation chain (delegation.issuer, delegation.jti) establishes which human or organisation authorised the action.
Implementation guidance: Preserve the agent’s AID Document as of the time of each action. Treat key rotation events as audit events themselves.
AU-12 — Audit Record Generation
Section titled “AU-12 — Audit Record Generation”Requirement: Provide audit record generation capability for AU-2 events; allow selection of which events are logged.
IDProva Coverage: ✅ Full
Receipt generation is built into the protocol at the binding layer — automatic on every MCP tool call. The requireReceipt constraint in DATs enforces receipt generation as a condition of delegation.
Implementation guidance: Set requireReceipt: true in DATs for agents operating on sensitive resources. For lower-risk agents, receipt generation can be selective by action type.
Identification and Authentication (IA)
Section titled “Identification and Authentication (IA)”IA-2 — Identification and Authentication (Organisational Users / Non-Human Accounts)
Section titled “IA-2 — Identification and Authentication (Organisational Users / Non-Human Accounts)”Requirement: Uniquely identify and authenticate organisational users, including non-human accounts.
IDProva Coverage: ✅ Full — specifically designed for non-human (agent) identity
The did:idprova: DID method provides globally unique, cryptographically verifiable identifiers for AI agents. Unlike service accounts or API keys, agent DIDs carry:
| IA Requirement | IDProva Mechanism |
|---|---|
| Unique identifier | did:idprova:domain:agent-name |
| Authentication | Ed25519 signature verification |
| Credential binding | AID Document with public key |
| Non-repudiation | Signed action receipts |
| Metadata | Model, runtime, config attestation, trust level |
Implementation guidance: Create a unique DID for every agent deployment — do not share DIDs between agents or environments. Register DIDs in your registry at deployment and deactivate immediately at decommission.
IA-5 — Authenticator Management
Section titled “IA-5 — Authenticator Management”Requirement: Manage system authenticators including initial content, changing, refreshing, revoking, and protecting authenticators.
IDProva Coverage: ✅ Partial (key escrow/recovery planned for v0.2)
| Lifecycle Phase | IDProva Support |
|---|---|
| Generation | idprova keygen — CSPRNG Ed25519 keypair |
| Distribution | AID Document published to registry |
| Rotation | AID update with new verification method |
| Revocation | AID deactivation via DELETE /v1/aid/:id |
| Escrow / Recovery | Planned for v0.2 |
Access Control (AC)
Section titled “Access Control (AC)”AC-2 — Account Management
Section titled “AC-2 — Account Management”Requirement: Manage system accounts including establishing, activating, modifying, reviewing, disabling, and removing accounts.
IDProva Coverage: ✅ Full
| AC-2 Phase | IDProva Operation |
|---|---|
| Establish | idprova aid create + PUT /v1/aid/:id |
| Activate | AID registered, first DAT issued |
| Modify | AID update (new metadata or keys) |
| Review | idprova aid verify + receipt log audit |
| Disable | DELETE /v1/aid/:id (soft deactivation) |
| Remove | Deactivation — all issued DATs become invalid |
AC-3 — Access Enforcement
Section titled “AC-3 — Access Enforcement”Requirement: Enforce approved authorisations for logical access in accordance with access control policies.
IDProva Coverage: ✅ Full
DAT scope enforcement provides cryptographically binding access control. The scope grammar (namespace:resource:action) allows fine-grained, resource-level enforcement. MCP servers validate scope before executing any tool call.
AC-6 — Least Privilege
Section titled “AC-6 — Least Privilege”Requirement: Employ least privilege, allowing only authorised accesses necessary to accomplish assigned tasks.
IDProva Coverage: ✅ Full
The scope reduction rule in DATs enforces least privilege structurally — child delegations must be subsets of parent delegations. Constraints further enforce least privilege:
| Constraint | Least Privilege Enforcement |
|---|---|
maxActions | Caps total actions an agent may take |
allowedResources | Restricts which resources may be accessed |
rateLimit | Prevents bulk data access via frequency limits |
expiresInSeconds | Time-bounds authority |
AC-17 — Remote Access
Section titled “AC-17 — Remote Access”Requirement: Establish usage restrictions and implementation guidance for remote access.
IDProva Coverage: ✅ Partial
DAT constraints support allowedIpRanges and allowedGeoRegions, enabling network-level restrictions embedded in delegation tokens and enforced at validation time.
System and Communications Protection (SC)
Section titled “System and Communications Protection (SC)”SC-8 — Transmission Confidentiality and Integrity
Section titled “SC-8 — Transmission Confidentiality and Integrity”Requirement: Implement cryptographic mechanisms to protect confidentiality and integrity of transmitted information.
IDProva Coverage: ✅ Integrity (confidentiality is transport-layer)
All DATs and Action Receipts carry Ed25519 signatures protecting integrity in transit. A tampered DAT or receipt fails signature verification. Confidentiality is provided by the underlying transport (TLS).
SC-12 — Cryptographic Key Establishment and Management
Section titled “SC-12 — Cryptographic Key Establishment and Management”Requirement: Establish and manage cryptographic keys in accordance with applicable standards.
IDProva Coverage: ✅ Partial
- Ed25519 as specified in FIPS 186-5
- ML-DSA-65 (FIPS 204) — planned for v0.2 hybrid mode
- Key generation uses OS CSPRNG
- HSM support for high-assurance deployments recommended in TRD
Configuration Management (CM)
Section titled “Configuration Management (CM)”CM-6 — Configuration Settings
Section titled “CM-6 — Configuration Settings”Requirement: Establish and document configuration settings for IT products within the system.
IDProva Coverage: ✅ Partial
The configAttestation field in AID Documents stores a hash of the agent’s configuration (system prompt, tool definitions, model identifier, runtime parameters) at deployment time — providing a verifiable baseline for drift detection.
Summary Table
Section titled “Summary Table”| Control | Family | IDProva Feature | Coverage |
|---|---|---|---|
| AU-2 | Audit | Receipt action.type taxonomy | ✅ Full |
| AU-3 | Audit | Receipt — who, what, when, where, outcome | ✅ Full |
| AU-8 | Audit | ISO 8601 UTC timestamps in signed receipts | ✅ Full |
| AU-9 | Audit | Hash-chained receipts + Ed25519 signatures | ✅ Full |
| AU-10 | Audit | Per-receipt Ed25519 signatures + delegation chain | ✅ Full |
| AU-12 | Audit | Protocol-native receipt generation, requireReceipt | ✅ Full |
| IA-2 | Identity | did:idprova: — unique, cryptographic agent identity | ✅ Full |
| IA-5 | Identity | idprova keygen, AID rotation, AID deactivation | ✅ Partial |
| AC-2 | Access | Full agent lifecycle via CLI and registry API | ✅ Full |
| AC-3 | Access | DAT scope enforcement at tool/resource level | ✅ Full |
| AC-6 | Access | Scope reduction rule, DAT constraints | ✅ Full |
| AC-17 | Access | allowedIpRanges / allowedGeoRegions in DATs | ✅ Partial |
| SC-8 | Comms | Signature integrity on all protocol messages | ✅ Integrity |
| SC-12 | Crypto | FIPS 186-5 Ed25519, FIPS 204 ML-DSA-65 (planned) | ✅ Partial |
| CM-6 | Config | configAttestation hash in AID Documents | ✅ Partial |
Evidence Artefacts for Assessors
Section titled “Evidence Artefacts for Assessors”| Control | Evidence Artefact | How to Collect |
|---|---|---|
| AU-2 through AU-12 | Action Receipt logs (JSONL) | idprova receipt verify receipts.jsonl |
| AU-9 / AU-10 | Hash chain integrity report | Output of idprova receipt verify |
| IA-2 | AID Document for each agent | Registry GET /v1/aid/:id |
| AC-6 | DAT scope and constraints | idprova dat inspect <token> |
| AC-2 | Agent creation/deactivation log | Registry audit log |
| CM-6 | Config attestation baseline | configAttestation field in AID |
Related
Section titled “Related”- Australian ISM Mapping — ISM control mapping
- SOC 2 Mapping — SOC 2 Trust Services Criteria
- Concepts: Audit — Understanding Action Receipts
- Action Receipts Specification — Full receipt protocol reference
- NIST submission: NIST-2025-0035 (Collaborative AI Security Initiative)