SOC 2 and Agent Skills: What Auditors Will Ask

Why AI Agents Break Your SOC 2 Assumptions

SOC 2 was built for static systems, deterministic behavior, and human-mediated decisions — and AI agents violate all three at once. Auditors are catching up fast, and the questions they now ask are not theoretical.

Three core assumptions break first. Controls were designed to be evaluated at a point in time, not at the frequency AI operates. Systems were expected to produce the same output for the same input. And privileged actions were expected to trace back to a person, not to an autonomous agent or generic service account. Security practitioners note that "no human request" now reads to auditors as a major accountability gap.

The controls auditors probe hardest follow directly from those breaks:

• CC8.1 change management — who approved the AI-assisted commit? The answer auditors want is the named human who hit accept, not the prompt author and not an auto-approval bot.
• CC6.1 logical access — an agent wired to a production read replica through an MCP server is a service account with engineering-level access and no MFA.
• CC3.2 data classification — did confidential data enter a third-party model? Regex PII filtering at a proxy layer catches roughly 80% of accidents, but only if you route traffic through one.
• CC7.1 and CC9.1 via shadow AI — undeclared tool trials and consumer-tier signups bypass vendor review and change control entirely.

MCP servers deserve special attention because they are the delivery mechanism for agent skills. Compliance engineers treat them as third-party vendors requiring an approved allowlist with named approvers and dates — and warn that the MCP threat model remains underbaked. A local settings file a developer can edit is a suggestion; a managed policy plus a log is a control.

The cost of guessing wrong is concrete. A single unanswered question — where does a pasted stack trace go? — added six weeks to a Series C fintech's audit. Teams have lost two weeks of prep to undeclared tool trials alone.

Banning AI tools makes this worse, not better: engineers fall back to consumer tiers on personal devices, the least governable surface in your environment. The workable answer is an inventory, an allowlist, and provenance for every instruction package your agents load. That is the gap SkillzBench is building to close — version-pinned, security-scanned, license-checked agent skills with per-agent loadouts so each agent only sees the tools you chose.

ctaText: Browse free agent skills with provenance you can show an auditor socialProofText: SkillzBench is building commit-SHA pinning, security scans, and sandboxed benchmarks for every agent skill in its free directory — join the waitlist to get notified at launch.

The Five Questions Auditors Will Actually Ask

Walk into a SOC 2 audit with an AI coding agent in your stack and no documentation, and the audit gets expensive fast. One fintech team watched a single unanswered question — where does a pasted stack trace go? — add six weeks to their audit, according to one compliance practitioner's account. Across auditor blogs and practitioner reports, five questions keep surfacing. Here they are, and what evidence actually satisfies each.

1. "Show me your AI tool inventory." Auditors want a list of every AI tool, agent, and MCP server, with vendor, contract type, and attestation date. MCP servers are treated as third-party vendors, requiring an approved allowlist with named approvers and dates, per Claude Code audit guidance. Undeclared tool trials have cost teams two weeks of audit prep alone. Agent skills — the SKILL.md instruction packages flowing into Claude Code, Cursor, and Codex — fall squarely in this category, which is why provenance documentation (version pinning, security scanning) is becoming table stakes; it's the problem SkillzBench is being built to solve.

2. "Who hit accept?" Attribution is the central demand. SOC 2 expects privileged actions to be attributable to an accountable individual, not an autonomous agent or generic system account — auditors treat "no human request" as a major accountability gap, as Teleport's analysis notes. The answer auditors want is the named human who approved the change, not the prompt author. Auto-approval bots are explicitly out.

3. "Did confidential data enter a third-party model?" This is the killer egress question. Without prompt and completion logging, you cannot prove the negative — and one anonymized biotech incident, where "deidentified" clinical data that was still PHI went into a model, ended in six-figure remediation and a delayed funding round. Regex-based PII filtering at a proxy layer catches roughly 80% of accidents, but only if the proxy exists.

4. "Prove your settings are enforced." A repo-level config file a developer can edit locally is a suggestion, not a control. The distinction, as one former CISO puts it: a setting becomes a control when the developer can't override it and it produces evidence an auditor can sample. Managed policies plus logs — Claude Code's OpenTelemetry tool_decision events, for example — turn authorization questions into data lookups instead of interviews.

5. "Where are your samples of AI-assisted commits?" For change management (CC8.1), auditors request tagged AI-assisted commits with mandatory human PR review, backed by branch protection and a reviewer who isn't the prompter. Prepare these before fieldwork starts:

• A complete inventory of AI tools, agents, and MCP servers with named approvers
• Tagged, human-reviewed samples of AI-assisted commits
• Prompt and completion logs routed through an internal proxy
• Enforced, non-overridable settings with evidence they work

The bar for AI governance evidence is currently low — clearing it, as practitioners note, is mostly a matter of writing things down.

Govern, Don't Ban: The Playbook That Passes Audit

The fastest way to fail a SOC 2 audit isn't using AI tools — it's pretending your team doesn't. Ban Claude, Copilot, or Cursor outright, and your engineers won't stop working with them; they'll shift to consumer tiers on personal devices, which practitioners describe as the worst possible outcome for compliance. SOC 2 doesn't prohibit AI coding assistants — it requires you to manage them properly.

The evidence-based playbook is less dramatic than most teams expect. Compliance engineers who have run multiple audits with AI tooling in scope converge on the same core moves:

• Standardize on enterprise tiers — consumer tiers retain code for training, lack SSO, and skip DPAs, while enterprise contracts bring zero-retention options and audit logs.
• Route prompts through a logging proxy — regex PII filtering catches roughly 80% of accidental data leaks before they reach a third-party model.
• Tag AI-assisted commits and require a named human reviewer who isn't the prompter — the answer auditors want is "the human who hit accept."
• Disclose scope gaps in writing — undisclosed unmanaged surfaces become findings; disclosed and bounded ones become scoped controls.

The proxy piece matters more than teams realize. Without telemetry, you cannot prove the killer auditor question: that confidential customer data never entered a third-party model during the audit window. As compliance lead Daniella Mitchell puts it, "you cannot prove a negative without telemetry" — and most teams simply don't have it.

Here's the reassuring part: the current evidence bar is low. Mitchell, who has prepared multiple SOC 2 Type II audits with AI tooling in scope, says clearing it is "mostly a matter of writing things down." Her mantra — "boring is what passes audit" — reframes the whole exercise. You don't need novel security architecture; you need an inventory, a policy, and logs an auditor can sample.

That applies to agent skills too. If your agents load SKILL.md instruction packages via MCP, auditors will treat those servers as third-party vendors — so version-pin every skill, record where it came from, and document who approved it. That's the same provenance discipline SkillzBench is building into its free skills directory, where every skill gets security-scanned and pinned to a commit SHA.

A setting only becomes a control when it's enforced and produces evidence. A repo-level config a developer can edit locally is a suggestion; a managed policy plus a log showing it worked is what passes. Boring, documented, enforced — that's the whole playbook.

Agent Skills Are Third-Party Code: Prepare Your Supply Chain Evidence

An AI agent wired to an MCP server is, in SOC 2 terms, a service account with engineering-level access and no MFA. That framing — laid out plainly by a compliance engineering lead who has walked fourteen Type II audits — is exactly how auditors will treat the agent skills delivered through those servers.

Skills are not configuration. They are third-party code, fetched at runtime, often unsigned, and frequently edited by anyone with repository access. Treat them like vendors.

Inventory every skill and MCP server before the auditor does. Undeclared tool trials have already cost real teams two weeks of audit prep. The inventory needs more than a list of names: vendor, contract type, attestation date, named approver, and the date the allowlist entry was reviewed. MCP servers specifically should sit on an approved allowlist with documented owners — the same evidence pack you would build for any SaaS dependency.

Require version pinning and provenance documentation. A skill pinned to a commit SHA is auditable. A skill pulled by tag, or by "latest," is not. Pinning turns "what is running in production right now?" from an interview question into a database lookup, which is the difference between a clean sample and a six-week delay.

Enforce per-agent tool scoping so agents only see approved capabilities. A repo-level configuration file that a developer can edit locally is a suggestion, not a control. A managed policy the developer cannot override, paired with a log proving it works, is a control. Claude Code's OpenTelemetry tool_decision events, for instance, turn authorization queries into data lookups rather than interviews, per a detailed mapping of Claude Code controls to SOC 2 criteria.

Use managed settings that produce logs, not locally editable ones. Auditors sample evidence. If the evidence does not exist, the control does not exist.

The practical checklist for treating skills as supply chain:

• Inventory every skill and MCP server with vendor, version, approver, and review date
• Pin each skill to a specific commit SHA and document provenance
• Scope tools per agent so each agent only sees vetted capabilities
• Run security scans and license checks on every skill before approval
• Enforce managed (non-overridable) settings that emit tamper-evident logs

This is the evidence pack auditors will ask for, and most teams do not have it. SkillzBench is building toward exactly this: commit-SHA pinning, security scanning, license validation, sandboxed benchmarking, and free per-agent loadouts through an MCP connector that lets each agent see only the skills you choose. Browse the directory and join the waitlist at skillzbench.com to be notified when it goes live.