An AI agent that can call tools, read records, and take actions on a user's behalf is a bigger audit surface than a traditional web application, and SOC 2 auditors are increasingly asking pointed questions about exactly that surface. This is a plain-language explainer on what SOC 2 actually is, why enterprise buyers keep asking for it, and what "logging and access control" concretely means once an AI agent, not just a human user, is the thing taking actions in your system.

What SOC 2 actually is

SOC 2 is not a law. It is an attestation standard maintained by the AICPA (American Institute of CPAs), a professional body for accountants. A SOC 2 report is produced by a licensed CPA firm that audits a company's controls against a defined set of criteria and reports on whether those controls meet the standard. It is fundamentally different from something like HIPAA or the CCPA, which are legal requirements enforced by a government agency; SOC 2 is a voluntary attestation that a company commissions because its customers want proof, not a rule a regulator imposes.

SOC 2 is built around five Trust Services Criteria. Security is always required and covers protection against unauthorized access, roughly 33 criteria with associated points of focus on its own. The other four are optional and chosen based on what the service actually does: Availability (the system is operational and usable as committed), Processing Integrity (system processing is complete, accurate, and authorized, meaning the system does what it claims to do to the data it handles), Confidentiality (information designated as confidential is protected), and Privacy (personal information is collected, used, and disposed of in line with the company's stated commitments). All five together span 61 criteria and nearly 300 points of focus, so a full SOC 2 report covering all five categories is a substantially larger undertaking than a Security-only report.

There are two report types. Type I attests that controls are designed correctly at a single point in time, essentially a snapshot. Type II attests that those controls actually operated effectively over an observed period, typically three to twelve months. Type II is what most enterprise buyers actually ask for in a vendor security review, because it shows the controls held up under real operation, not just that they looked right on the day of the audit.

Why it exists, and why a company pursues it

SOC 2 exists because enterprise buyers need a standardized, independently verified way to evaluate a vendor's security posture without auditing every vendor themselves. Before frameworks like this, every enterprise customer asked its own version of a security questionnaire, and every vendor answered it differently, with no independent check on the answers. SOC 2 gives both sides a common, audited reference point.

A company pursues SOC 2 for market reasons more than legal ones: enterprise deals, especially with regulated buyers, routinely stall or die without a current SOC 2 Type II report on file. It has become a practical precondition for selling into mid-market and enterprise accounts, not an obligation imposed by a regulator. That said, the underlying discipline it forces (real access control, real logging, real incident response) is worth having regardless of whether a report ever gets requested.

What logging and access control concretely mean for an AI agent

Logging that captures more than the final answer

Traditional application logging usually records a request and a response. For an AI agent, that is not enough to satisfy what a SOC 2 auditor, or a real incident investigation, needs to see. Logging needs to capture what the agent did, which tool it called and with what parameters, what data it retrieved or touched in the process, and ideally the reasoning path that led to the action, not just the output shown to the user. If a support agent issued a refund, the log needs to show which order it looked up, what policy check it ran, and why it decided the refund was warranted, not just that a refund happened.

Access control enforced at the system level, not the prompt level

This is the point worth being blunt about: a system prompt telling an agent "only access orders belonging to the authenticated user" is an instruction, not a security boundary. A system prompt can be bypassed through injection, misinterpreted, or simply not followed reliably by a model under unusual input. Real access control means defining exactly which tools, data sources, and actions an agent is authorized for, and enforcing that with scoped API credentials, database-level permissions, or a dedicated authorization layer that checks every tool call against the calling context, independent of what the model decides to do. If the agent's database credential literally cannot read another user's orders, the model never gets the chance to be tricked into fetching them.

Which Trust Services Criteria actually apply

Security is non-negotiable for any AI agent handling real data or taking real actions. Processing Integrity is often directly relevant for an agent, because it speaks to whether the system's processing is complete, accurate, and authorized, which is exactly the question an agent that summarizes, transforms, or acts on data raises. Confidentiality matters if the agent touches information the company has committed to protect beyond personal data, like proprietary business data. Availability and Privacy depend on the specific product. Deciding which criteria actually apply, rather than defaulting to all five, is itself part of scoping the audit correctly.

A concrete example
Picture a support-agent product that can look up orders, issue refunds up to a set limit, and escalate to a human for anything larger. A SOC 2-ready version of this needs the refund tool itself to enforce the dollar limit at the code level, not rely on the agent choosing to respect it; needs the agent's database access scoped so it can only query orders tied to the authenticated session, not the whole orders table; and needs every tool call logged with enough detail that an auditor, or an internal investigator after an incident, can reconstruct exactly what the agent did and why, without having to guess from the final chat transcript alone.

What GreyScript AI does, and does not, do here

GreyScript AI builds AI agents with logging and access control structured to support a SOC 2 audit: tool-call logging that captures the reasoning path and data touched, and access control enforced at the system level rather than through prompt instructions alone. We do not issue SOC 2 reports. Only a licensed CPA firm running an actual audit can do that. Our role is building the system so that audit, run by whichever CPA firm the client engages, has real controls to examine and can succeed. See our AI governance and security service for how this fits into a build.

Access control for an AI agent is closely tied to identity: our piece on AI agent identity and access management goes deeper into why traditional IAM patterns do not transfer directly to agents and what proper permission scoping looks like.