SOC 2 Compliance Export

The Compliance Gap

SOC 2 Type II audits require evidence that access controls are operating effectively over time. For Kubernetes infrastructure, this means demonstrating: who accessed what, when, and whether appropriate controls were in place.

Most teams cobble this together from kubectl audit logs, RBAC role bindings, and manual documentation. When AI agents enter the picture — issuing thousands of commands autonomously — the manual approach breaks down entirely.

Iddio’s audit log already captures every command with agent identity, tier classification, and policy decision. The compliance export maps these events directly to SOC 2 Trust Services Criteria.

Mapped Criteria

Iddio generates evidence for four SOC 2 criteria:

Criterion	Title	What Iddio Provides
CC6.1	Logical access security	Agent identity (mTLS/token), per-agent policy rules, namespace scoping
CC6.2	System credential management	JIT credential issuance, certificate lifecycle, token rotation records
CC6.3	Access authorization and modification	Policy change audit trail, tier-based access model, approval workflows
CC7.2	System monitoring	Hash-chained audit log, session recordings, real-time classification

Evidence Generation

The iddio compliance export command generates a structured evidence package:

iddio compliance export \
  --format json \
  --from 2026-01-01 \
  --to 2026-03-31 \
  --output /tmp/soc2-q1-2026/

This produces:

/tmp/soc2-q1-2026/
├── cc6.1-access-controls.json
├── cc6.2-credential-lifecycle.json
├── cc6.3-authorization-changes.json
├── cc7.2-monitoring-evidence.json
├── summary.json
└── audit-log-integrity.json

Each file contains structured evidence that maps directly to the criterion. Auditors can review the JSON directly or import it into their GRC platform.

CC6.1: Logical Access Security

The CC6.1 export includes:

• Agent inventory — every agent identity that accessed the system during the period
• Policy snapshot — the active policy at the start and end of the period, plus every change
• Access summary per agent — total commands, breakdown by tier, namespace coverage
• Denied access attempts — all requests that were blocked by policy

{
  "criterion": "CC6.1",
  "period": { "from": "2026-01-01", "to": "2026-03-31" },
  "agents": [
    {
      "name": "claude-code",
      "identity_type": "mtls",
      "first_seen": "2026-01-15T10:00:00Z",
      "last_seen": "2026-03-30T18:45:00Z",
      "total_requests": 14892,
      "by_tier": { "0": 14441, "1": 312, "2": 75, "3": 54, "4": 10 },
      "by_decision": { "allow": 14753, "escalate": 75, "deny": 64 },
      "namespaces": ["payments", "api-gateway", "monitoring"]
    }
  ]
}

CC7.2: System Monitoring

The CC7.2 export proves that monitoring was continuous and tamper-evident:

{
  "criterion": "CC7.2",
  "audit_log": {
    "total_events": 48231,
    "hash_chain_verified": true,
    "first_event": "2026-01-01T00:00:12Z",
    "last_event": "2026-03-31T23:59:48Z",
    "gaps_detected": 0
  },
  "session_recordings": {
    "exec_sessions": 127,
    "api_sessions": 4891,
    "total_bytes_recorded": 284729344
  }
}

The hash_chain_verified: true field is the key evidence: it proves the audit log has not been tampered with since the first event.

CSV Export

For auditors who prefer spreadsheets:

iddio compliance export --format csv --from 2026-01-01 --to 2026-03-31

This produces the same data in CSV format, with one row per agent per criterion. Most GRC platforms can import CSV directly.

Continuous Compliance

For enterprise deployments, the compliance export can run on a schedule:

# Server config
compliance:
  auto_export:
    enabled: true
    schedule: "0 0 1 * *" # First of each month
    format: json
    retention: 24 # months
    storage: s3://compliance-evidence/iddio/

This generates monthly evidence packages automatically, stored in your compliance evidence bucket. Auditors get a continuous stream of evidence without anyone remembering to run a command.