SOC 2 Mapping

SOC 2 Trust Services Criteria (TSC) provide a widely recognised framework for evaluating the security, availability, processing integrity, confidentiality, and privacy of service organisations. IDProva’s protocol primitives directly support multiple TSC, particularly in logical access, system monitoring, and change management.

This mapping is aimed at organisations that deploy AI agents and want to demonstrate that their agent infrastructure satisfies SOC 2 controls as part of their own SOC 2 Type II audit. It addresses the Security (CC) criteria — the mandatory baseline applicable to all SOC 2 reports.

Auditor Note

This mapping is intended as implementation guidance, not a substitute for an independent SOC 2 assessment. Work with your licensed CPA firm to determine how IDProva evidence is incorporated into your specific audit scope.

---

CC1 — Control Environment

CC1.2 — Board and Management Oversight of Security

TSC Requirement: Management demonstrates commitment to integrity, ethical values, and competence.

IDProva Relevance: Supporting

IDProva’s open-source, standards-based approach (W3C DIDs, JWS, FIPS algorithms) and published NIST submission (NIST-2025-0035) demonstrate a commitment to security standards. The STRIDE threat model and formal protocol specification support a documented, principled approach to agent security.

---

CC2 — Communication and Information

CC2.2 — Internal Communication of Security Information

TSC Requirement: Information about security responsibilities is communicated internally.

IDProva Relevance: Supporting

The IDProva protocol provides a common vocabulary and artefact set (AIDs, DATs, receipts) that security teams can use to communicate agent access policies and audit findings across the organisation.

---

CC6 — Logical and Physical Access Controls

This is the most directly addressed criterion family. CC6 maps tightly to IDProva’s identity and delegation capabilities.

CC6.1 — Logical Access Security Measures

TSC Requirement: Logical access security software, infrastructure, and architectures have been implemented to protect against threats from sources outside the boundaries of the system.

IDProva Coverage: ✅ Full

CC6.1 Sub-requirement	IDProva Mechanism
Unique user/process identification	did:idprova: — globally unique, cryptographic agent ID
Authentication before access	Ed25519 signature verification on every DAT
Access restricted to authorised individuals	DAT scope enforcement at MCP/HTTP/A2A layer
Access credentials protected	Private keys held in Rust memory, never exposed

Every agent that interacts with a system protected by IDProva must present a valid, non-expired DAT signed by an authorised issuer. Unsigned requests or requests with invalid signatures are rejected.

---

CC6.2 — Prior to Issuing Credentials

TSC Requirement: New internal and external users are registered and granted access only as appropriate.

IDProva Coverage: ✅ Full

Agent identity lifecycle maps directly to CC6.2:

CC6.2 Requirement	IDProva Mechanism
Registration of new entities	idprova aid create + PUT /v1/aid/:id
Granting access	DAT issuance by authorised controller
Access reflects job responsibilities	DAT scope limited to required actions
Access removed when no longer needed	AID deactivation invalidates all associated DATs

Evidence for auditors: AID Document for each agent, timestamped DAT issuance records, AID deactivation log.

---

CC6.3 — Removal of Access

TSC Requirement: Access is removed in a timely manner when no longer required.

IDProva Coverage: ✅ Full

Two mechanisms enforce access removal:

1. Expiry — Every DAT has a mandatory exp claim. When a DAT expires, the agent’s access automatically terminates without any manual action.
2. Deactivation — Calling DELETE /v1/aid/:id soft-deletes the agent’s AID. All verifiers resolving this DID receive a deactivation notice and reject associated DATs.

Implementation guidance: Use short-lived DATs (24 hours for standard agents, 1–4 hours for privileged agents). Integrate agent decommissioning into your offboarding or deployment teardown process.

---

CC6.6 — Logical Access Security Over Protected Information Assets

TSC Requirement: Logical access security measures protect against threats from individuals and software acting in unauthorised manners.

IDProva Coverage: ✅ Full

The scope grammar (namespace:resource:action) with wildcard support allows fine-grained access policies. The scope reduction rule prevents any sub-agent from acquiring permissions not explicitly granted by its parent delegation. Constraints (rate limits, IP ranges, max actions) further narrow the blast radius of any single compromised agent.

Example policy: An agent granted ["mcp:tool:filesystem:read"] cannot access mcp:tool:filesystem:write or any other resource, even if it attempts to present a forged or modified DAT — the signature will fail verification.

---

CC6.7 — Restriction of Transmission, Movement, and Removal of Information

TSC Requirement: Transmission of information is restricted to authorised users.

IDProva Coverage: ✅ Partial

The allowedResources and allowedGeoRegions constraints in DATs can restrict which data sources an agent may access. Application-layer data movement controls (preventing exfiltration) remain the responsibility of the tool/service implementations that consume IDProva tokens.

---

CC7 — System Operations

CC7.1 — Detection and Monitoring Procedures

TSC Requirement: Detect and monitor for security vulnerabilities, configuration changes, and incidents.

IDProva Coverage: ✅ Full

Hash-chained Action Receipts provide the primary monitoring artefact:

• Every agent action produces a signed receipt, enabling behavioural monitoring
• Anomalous patterns (unusual scope usage, unexpected action frequency, off-hours activity) are detectable by analysing receipt logs
• The configAttestation field in AIDs enables detection of agent configuration drift

Implementation guidance: Aggregate receipt logs into your SIEM. Alert on: unexpected action types for an agent’s role, high action.result.status failure rates, activity outside normal operating hours.

---

CC7.2 — Monitoring of System Operations

TSC Requirement: Processes are in place to monitor the effectiveness of security controls over time.

IDProva Coverage: ✅ Full

Monitoring Concern	IDProva Evidence
Agent inventory	Registry — all active AIDs
Active delegations	DAT audit log — all issued tokens
Action audit trail	Receipt JSONL logs per agent
Chain integrity	idprova receipt verify — detects tampering
Expired access	DAT exp claims — auto-expiry

---

CC7.3 — Evaluation of Security Events

TSC Requirement: Detected security events are evaluated to determine whether they represent security incidents.

IDProva Coverage: ✅ Supporting

When a security event is detected in an agent system, IDProva receipts provide the forensic foundation for determining:

• Which agent was involved (agent DID)
• What actions were taken (action type, target)
• Under whose authority (delegation chain, issuer DID)
• Whether the scope was exceeded (compare receipt scope against DAT)
• Whether the receipt chain has been tampered with (hash chain verification)

---

CC8 — Change Management

CC8.1 — Changes Are Authorised

TSC Requirement: Changes to infrastructure, data, software, and procedures are authorised.

IDProva Coverage: ✅ Supporting

Changes to agent identity (key rotation, metadata updates) require a signed AID update. Changes to agent permissions require a new DAT issued by an authorised controller. Both operations produce audit records in the registry and can be tied to change management workflows.

---

CC9 — Risk Mitigation

CC9.2 — Risk Mitigation Activities for Vendor and Business Partner Management

TSC Requirement: Risks from vendors and business partners are identified, assessed, and managed.

IDProva Coverage: ✅ Supporting

When agents operate on behalf of third parties or access third-party services, the delegation chain in every Action Receipt provides a complete record of authority flow, enabling post-hoc audit of third-party agent activity.

---

Summary Table

Criterion	IDProva Feature	Coverage
CC6.1	did:idprova: identity + DAT authentication	✅ Full
CC6.2	Agent registration, DAT issuance, lifecycle management	✅ Full
CC6.3	DAT expiry + AID deactivation	✅ Full
CC6.6	Scope enforcement, reduction rule, DAT constraints	✅ Full
CC6.7	allowedResources / allowedGeoRegions constraints	✅ Partial
CC7.1	Hash-chained receipts, configAttestation monitoring	✅ Full
CC7.2	Registry inventory + receipt log audit trail	✅ Full
CC7.3	Receipt forensics — agent, action, delegation, scope	✅ Full
CC8.1	Signed AID updates + new DAT for permission changes	✅ Supporting
CC9.2	Delegation chain in receipts for third-party audit	✅ Supporting

---

Evidence Package for SOC 2 Auditors

When preparing for a SOC 2 Type II audit that includes AI agent systems, the following IDProva artefacts are directly relevant:

TSC Criterion	Evidence Artefact	How to Produce
CC6.1 / CC6.2	Agent identity register	Registry dump: all active AID Documents
CC6.2	DAT issuance log	Registry audit log of all PUT /v1/aid/:id events
CC6.3	Deactivation log	Registry log of all DELETE /v1/aid/:id events
CC6.6	DAT scope inventory	idprova dat inspect for each issued token
CC7.1 / CC7.2	Action Receipt logs	JSONL receipt files per agent
CC7.2	Chain integrity report	idprova receipt verify receipts.jsonl output
CC7.3	Incident forensic receipts	Filtered receipt logs for incident timeframe
CC8.1	AID change history	Registry update log for all AID modifications

Audit period coverage: Because DATs have mandatory expiry and receipts are immutable once signed, the receipt log provides continuous evidence of agent behaviour throughout the audit period without requiring any additional logging infrastructure.

---

Related

• NIST 800-53 Mapping — US federal control mapping
• Australian ISM Mapping — ASD ISM control mapping
• Action Receipts Specification — Full receipt format and hash chain
• Concepts: Audit — Understanding the audit trail design