Evaluating AI Agent Governance in a SOC 2 Bridge Letter

What a SOC 2 Bridge Letter Actually Attests To

A SOC 2 bridge letter, sometimes called a gap letter, is a representation from a service organization's management stating that no material changes occurred to the controls described in its most recent SOC 2 report between the end of that report's period and a later date. In some cases the letter is countersigned by the independent service auditor, but in many cases it is issued solely by vendor management. Either way, a bridge letter is not an audit. It involves no testing of control operating effectiveness during the gap period and does not extend the auditor's opinion beyond the original report window. AICPA guidance is explicit that bridge letters should not substitute for an updated SOC report and cautions against relying on them for extended periods. For compliance leaders, the operative distinction is that a bridge letter tells you what did not change according to management, not what is currently true according to independent verification.

Why This Matters More for AI Agents Than Static Systems

SOC 2 control descriptions are written against a defined system boundary and typically describe control activities as static, enumerable items: user provisioning workflows, role-based access configurations, change management procedures. These descriptions assume relatively stable permission sets tied to human users or service accounts. AI agents do not fit this model cleanly. Agent identity, permission scoping, and tool-call authorization frequently operate as a runtime enforcement layer that sits outside the system description written before the agent was deployed or before its capabilities expanded. An agent's tool integrations, delegated permissions, or orchestration logic can change materially between audit cycles without triggering a formal update to the system description. When that happens, a bridge letter's representation of "no material change" may be technically accurate with respect to the originally described controls while saying nothing about the actual risk posture of the agent in production.

Where AI Agent Controls Fall Outside Traditional Audit Scope

Several categories of AI agent governance are commonly absent from existing SOC 2 Type II control descriptions. Identity management for agents, including delegated or dynamically scoped credentials, differs from the provisioning controls typically tested for human and static service accounts. Permission scoping and least-privilege enforcement for agents may be configured at runtime rather than through the access control structures an auditor originally reviewed. Tool-call restrictions and function-calling permissions represent a distinct risk category, similar to what industry guidance on large language model applications identifies as excessive agency and insecure tool design, and this category is not typically mapped to conventional access control testing. Audit logging for agents also differs in kind: capturing agent intent, tool invocation sequences, and output provenance is a different logging discipline than the system and application logs SOC 2 auditors usually evaluate. No current AICPA publication defines these as distinct tested control objectives, which means their presence or absence in a given SOC 2 report depends entirely on how the specific engagement scoped the system description.

Evidence to Request From AI Vendors During the Gap Period

Because a bridge letter provides no new testing, compliance teams need to independently gather evidence that agent governance controls remained effective during the gap period. This starts with obtaining the specific control descriptions tested in the underlying Type II report to determine scope. If AI agent controls were not explicitly in scope, the bridge letter offers no coverage for them regardless of what it says about material change. Request documentation of any changes to agent permission scopes, tool integrations, or orchestration configuration during the covered interval, since these changes are exactly what a bridge letter's material-change language is supposed to capture but often does not test for directly. Where available, request agent-specific audit logs showing tool invocations, permission grants, and anomalous action patterns. Frameworks such as NIST's AI Risk Management Framework treat AI governance as a continuous lifecycle function rather than a point-in-time attestation, and while no official crosswalk exists between that model and SOC 2 bridge letter procedures, the structural difference is instructive: continuous monitoring evidence is a reasonable substitute for the testing a bridge letter does not perform.

Compensating Controls and Internal Governance Decisions

When a bridge letter cannot be reasonably extended to cover AI agent risk, the responsibility shifts to the relying organization's internal controls. This typically means implementing or verifying continuous monitoring of agent behavior, independent audit logging that captures tool-call activity and permission changes, and periodic access reviews scoped specifically to agent identities rather than only human users. Runtime policy enforcement, including approval workflows for sensitive tool calls and least-privilege permission scoping, functions as a compensating layer that operates independently of the audit cycle and does not depend on a vendor's bridge letter for assurance. Compliance leaders should treat the absence of AI-specific criteria in current SOC 2 practice as a documented gap requiring internal risk ownership, not as evidence that no risk exists. This is also where runtime governance tooling becomes relevant: maintaining agent identity records, permission scopes, and tool approval logs independently of the vendor's audit cycle gives compliance teams evidence they control directly, rather than evidence dependent on a third party's attestation timeline.