When we talk with platform teams who have been through a SOC 2 audit with AI agents in scope, the feedback is consistent: auditors do not care about your prompt engineering. They care about the same questions they ask about any system that touches customer data: who accessed what, when, and what did they do with it? The AI wrapper on top of those actions does not change the question. It complicates the answer.
This post works through what audit trail completeness means specifically for AI agent workloads in a SOC 2 context, maps the canonical SOC 2 Trust Services Criteria questions to specific log fields, and describes what a runtime that generates a complete, verifiable record needs to capture.
The SOC 2 Framing: What CC6 and CC7 Actually Ask
SOC 2 Type II examinations under the Common Criteria (CC) category include CC6 (Logical and Physical Access Controls) and CC7 (System Operations), both of which are relevant to AI agent deployments. The specific points within those criteria that apply most directly:
- CC6.1 asks whether the organization identifies and authenticates users prior to granting them access to systems. For AI agents: is each agent run associated with an authenticated principal? Is there a run identifier that ties back to an initiating user or service identity?
- CC6.3 addresses authorization and whether access is restricted to authorized users. For AI agents: what resources could this agent access, and is there a record of what it actually accessed?
- CC7.1 addresses detection of security events. For AI agents: are anomalous patterns detectable from the log? A policy violation attempt is a security event that should appear in the record.
- CC7.2 asks about the evaluation of security events and incident response. For AI agents: when an incident occurs, can you reconstruct the sequence of agent actions from the audit trail?
These criteria do not say "you must produce JSON logs from your agent runtime." They say you must be able to demonstrate, with evidence, that access controls are working and that security events are detectable and reconstructable. The audit trail is the evidence. What it must contain flows from those questions.
The Minimum Viable Audit Record for an Agent Run
For any individual agent run, a complete audit record needs to answer six questions:
1. Identity: What entity initiated this run? This ties to CC6.1. For a human-initiated run, it is the authenticated user identity. For an automated trigger, it is the service identity or job identifier. The run record must include an unambiguous initiating identity, not just a generic "system" label.
2. Scope at authorization time: What was this agent permitted to do when the run started? The policy active at run start must be recorded verbatim, including which tools were available, what egress destinations were allowed, and what resource quotas applied. If the policy is stored by reference, the record must capture the policy version or hash so that the effective policy can be reconstructed even after future policy changes.
3. Sequence of actions: What did the agent actually do, in order? Each tool call, LLM invocation, and policy enforcement decision must appear as a timestamped record. The sequence must be complete: a log that omits tool calls because they were considered low-risk does not satisfy completeness.
4. Outcome of each action: Did each action succeed, fail, or get blocked by policy? A blocked egress call is a security-relevant event. An API call that returned an error is useful for incident reconstruction. Recording only successful actions produces a record that looks clean and tells you nothing about what the agent tried but could not do.
5. Data access breadcrumbs: What data was read or written as part of the run? For data-intensive agents, this may be a reference to the identifiers or paths accessed rather than the data itself. For customer data access in a SOC 2 scope, the record must be sufficient to answer "was customer record X accessed during run Y?"
6. Termination state and integrity proof: How did the run end, and is the record tamper-evident? A run that terminated normally, one that was terminated by quota enforcement, and one that was terminated due to a policy violation are three different termination states that a security reviewer needs to distinguish. And the record as a whole must include a mechanism for demonstrating that it has not been modified after the fact.
// annotated run log excerpt { "run_id": "b7f3a1c", // unique run identifier "initiated_by": "user:jsmith@co", // CC6.1: initiating identity "policy_hash": "sha256:a9c4...", // scope at authorization time "started_at": "2025-11-21T14:02:33Z", "events": [ { "seq": 1, "type": "tool_call", "tool": "fetch_record", "args": { "record_id": "cust:8821" }, "result": "ok" }, { "seq": 2, "type": "egress_check", "dest": "api.partner.com", "decision": "ALLOW" }, { "seq": 3, "type": "egress_check", "dest": "exfil.example.com", "decision": "DENY", "reason": "not in allowlist" } // CC7.1: security event ], "ended_at": "2025-11-21T14:02:41Z", "termination": "policy_block", // termination state "record_hash": "sha256:d7e1..." // integrity proof }
Where Typical Agent Logging Falls Short
Most agent frameworks produce some logging by default. The gap between what they produce and what a SOC 2 audit needs is usually in three areas:
LLM call content vs. metadata: Many frameworks log that an LLM call occurred and what model was used, but not the full input context or the reasoning chain. For audit completeness, you do not necessarily need the full prompt text in the log. What you need is enough to reconstruct what the agent was reasoning about at each decision point. A summary or a hash of the input that can be correlated to the agent's task inputs may be sufficient. What is not sufficient is a bare timestamp with a model name.
Policy enforcement decisions as first-class events: An agent framework that does not have policy enforcement built in will not produce policy enforcement events at all. A DENY decision on an egress call will appear in a network-level log if one exists, not in the agent's application log. Correlating network layer logs with agent application logs is possible, but it requires work and produces a composite picture that is harder to validate than a single unified record per run.
Record integrity proofs: Application logs are typically mutable. The default storage in most cloud environments allows deletion and modification. A SOC 2 auditor asking whether logs could have been tampered with after an incident gets an unsatisfying answer if the response is "the logs are in CloudWatch and we trust our IAM configuration." Append-only storage with tamper evidence at the record level produces a demonstrably stronger answer.
Log Retention and the SOC 2 Examination Period
SOC 2 Type II examinations cover a defined period, typically 6 to 12 months. All log records relevant to the examination period must be retrievable and verifiable. For AI agents, this creates a specific requirement: the log retention period must cover the full examination window, not just recent activity.
The practical implication is that you cannot retire log records for agent runs that occurred within your examination window, even if those runs are long complete. A 90-day retention configuration works for a 90-day examination period. A 12-month examination window requires longer retention, or a policy that explicitly archives and preserves examination-period records separately from operational logs.
It is worth being precise about what "retention" means here. Keeping the raw log files is necessary but not sufficient if the system for verifying their integrity is not also available. A hash-chained log is only verifiable if you retained the chain state at the time of the examination period. Archiving the log file without archiving the chain anchors means you have the content but not the proof of integrity.
The Escalation Path When an Agent Audit Trail is Incomplete
In our conversations with platform teams who have gone through a SOC 2 audit with agent workloads in scope, the most difficult situation is discovering an incomplete audit trail during the audit itself. If a run occurred during the examination period and the record is missing fields, the auditor's options are to accept the record as incomplete or to flag a gap.
The right response to an incomplete trail is not to reconstruct or fill in what is missing. Reconstructed records are not primary evidence. The right response is to document the gap, identify the root cause (framework limitation, logging configuration, storage failure), and provide a remediation plan. Auditors are more interested in whether your process for identifying and addressing gaps is sound than in whether every historical record is perfect. But you need to be able to identify the gap precisely, which requires knowing what a complete record looks like in the first place.
This is why the completeness specification matters before you deploy agents, not after. If you define upfront what fields every run record must contain, you can validate that definition against your logging infrastructure before agents are running in your examination scope. A gap discovered in testing is a configuration problem. A gap discovered during an audit is an audit finding.
Runta's audit log design applies this specification to every run: every tool call, every egress decision, every quota check, every termination state appears as a structured event in a hash-chained record. The policy hash at run start captures the authorization scope as it existed at dispatch time. The run identifier ties every event to the initiating identity. That structure is exactly what the six completeness questions above require, and it is what a SOC 2 auditor asking about an agent in scope needs to see.