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

Webhook export

Configure a webhook in Settings → Webhooks to stream audit events to your SIEM in real-time:

{
  "url": "https://your-siem.example.com/api/events",
  "events": ["tool.call", "tool.denied", "auth.failed"],
  "format": "json"
}

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.makeagents.run/your-slug/api/v1/audit?from=2026-03-01&to=2026-03-31"

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)
• Webhook configuration (SIEM integration for real-time monitoring)

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 →