AI Audit Trails for SOC 2

Your auditor asks: “How do you track what your AI agents are doing?” If you can’t answer that question with evidence, you have a gap.

ACP logs every tool call with full identity attribution — who did it, what they did, when, and whether it was allowed. This guide maps ACP’s audit capabilities to SOC 2 trust service criteria so you can show your auditor exactly how AI actions are governed.

The problem

AI agents call tools — querying databases, creating records, posting messages, reading files. Traditional SOC 2 evidence covers human actions (login logs, access reviews, change management). But when an AI agent acts on behalf of a user, the audit trail disappears into a shared API key or service account.

Your auditor sees:

• service-account-bot queried the CRM 47,000 times last month
• No way to attribute actions to individual users
• No scope enforcement evidence
• No content inspection evidence

What ACP logs

Every tool call through ACP produces an immutable audit record:

{
  "timestamp": "2026-03-15T14:23:07.142Z",
  "sub": "auth0|8f3a2b1c9d4e5f6a",
  "email": "alice@acme.com",
  "tool": "salesforce.query",
  "input": { "query": "SELECT Name FROM Opportunity WHERE CloseDate = THIS_MONTH" },
  "scopes": ["salesforce:read", "salesforce:write"],
  "scopeRequired": ["salesforce:read"],
  "scopeResult": "pass",
  "contentScan": {
    "piiDetected": false,
    "riskScore": 0.02
  },
  "result": "success",
  "latencyMs": 142,
  "tenantId": "org_acme_corp",
  "clientType": "claude-desktop",
  "delegationChain": null
}

Every field is populated from the verified JWT — not from self-reported client data.

Mapping to SOC 2 Trust Service Criteria

CC6.1 — Logical access security

Requirement: The entity implements logical access security over information assets.

ACP evidence:

• Every tool call requires a valid JWT from your configured identity provider
• JWTs are verified via RS256 signature against the IdP’s JWKS endpoint
• Expired, malformed, or unsigned tokens are rejected
• Audit log shows every accepted and rejected authentication attempt

What to show your auditor: Export the audit log filtered by result: "auth_failed" to demonstrate that unauthenticated access is blocked.

CC6.2 — User authentication

Requirement: The entity authenticates users before granting access.

ACP evidence:

• ACP integrates with your existing IdP (Auth0, Okta, Entra ID)
• User identity is carried through the entire tool call chain
• Multi-factor authentication is enforced at the IdP level
• The sub claim in every audit record ties back to a specific human

What to show your auditor: Audit log entries showing distinct sub values with corresponding email addresses, demonstrating per-user authentication.

CC6.3 — Authorization and access controls

Requirement: The entity authorizes, modifies, and removes access based on job function.

ACP evidence:

• Scope-based access control: each tool requires specific scopes
• Scopes are assigned via IdP roles/groups — managed in your existing identity provider
• The audit log records both the scopes the user had and the scopes the tool required
• Users without required scopes are blocked with 403 Insufficient scope

What to show your auditor: Audit log entries showing scopeRequired vs scopes fields, including entries where access was denied due to missing scopes.

CC7.2 — Monitoring for anomalies

Requirement: The entity monitors system components for anomalies.

ACP evidence:

• Per-user rate limiting prevents abnormal usage patterns
• Content scanning detects PII in tool inputs and outputs
• Immutable platform rules block SSN, credit card, and SSRF patterns
• Audit logs include contentScan.riskScore for anomaly detection

What to show your auditor: Rate limit configuration, content scanning rules, and sample audit entries showing blocked PII.

CC8.1 — Change management

Requirement: The entity authorizes, designs, develops, configures, documents, tests, approves, and implements changes.

ACP evidence:

• Tool configurations are versioned in the ACP dashboard
• Scope-to-tool mappings are explicit and reviewable
• Policy changes are logged
• Governance rules (immutable rules) cannot be overridden by tenant configuration

What to show your auditor: Current tool scope configuration, governance policy settings, and the immutable rules documentation.

Exporting audit data

Dashboard export

Go to Logs in the dashboard. Filter by date range, user, tool, or result. Export as CSV or JSON.

API export

curl -H "Authorization: Bearer gsk_your-api-key" \
  "https://api.agenticcontrolplane.com/your-slug/api/v1/audit?from=2026-03-01&to=2026-03-31"

There’s no push/webhook delivery to a SIEM today — poll this endpoint on a schedule (or CSV-export from the dashboard) and feed the result into your SIEM’s own ingestion pipeline.

Evidence collection checklist

For your SOC 2 audit, collect:

• Identity provider configuration (issuer, audience, JWKS discovery)
• Tool scope mappings (which tools require which permissions)
• Sample audit log entries (authenticated access, denied access, PII detection)
• Rate limit configuration (per-user limits)
• Content scanning rules (PII patterns, risk thresholds)
• Immutable rules documentation (platform-enforced SSN/CC/SSRF blocking)
• User access review (which users have which roles/scopes in your IdP)
• Audit export path documented (CSV export or Logs API polling into your SIEM)

What makes this different from regular API logging

Regular API logging records that an API was called. ACP audit logging records:

• Who — the specific human, verified by JWT, not a shared service account
• What they were allowed to do — the scopes they held at the time
• What was required — the scopes the tool needed
• Whether content was safe — PII scan results on every call
• The full delegation chain — if an agent called another agent, the chain of identity is preserved

Back to guides · PII detection → · Set up Auth0 →

curl -sf https://agenticcontrolplane.com/install.sh | bash

irm https://agenticcontrolplane.com/install.ps1 | iex