# AI Audit Trails for SOC 2

Map ACP's audit logs to SOC 2 trust service criteria. Identity attribution, access controls, and evidence collection for AI agent actions.

# 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:

```json
{
  "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

```bash
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

This is the difference between "someone called the CRM API" and "Alice Chen (auth0|8f3a2b1c) queried opportunities using Claude Desktop, had salesforce:read scope, no PII detected, 142ms response time."

---

[Back to guides](/guides/) · [PII detection →](/guides/pii-detection/) · [Set up Auth0 →](/guides/auth0/)