A number has been making the rounds in security circles: 78% of organizations run AI agents against sensitive data with no meaningful compliance steps behind them. We tried to trace it to a primary source and came up empty, so treat it as directional, not settled. What is settled is the premise underneath it. Microsoft's Cloud Adoption Framework and the smaller governance vendors all start from the same observation: enterprises are shipping agents that act with delegated authority across business systems faster than they are building any control plane around them.
When the auditor shows up, they will not ask whether your agents are safe. They will ask the questions auditors always ask. Who can access what. Show me the logs. Prove you can delete a customer's data. Agents make those old questions much harder to answer, and this piece is the shortest defensible response I know: six controls, each mapped to the question it answers and the document it produces.
Why agents break controls that worked fine for chatbots
Microsoft defines an AI agent as software that can access data, make decisions, and take actions across business systems, operating with delegated authority and able to affect multiple systems at once. That is a different risk profile from a traditional application running fixed code paths, and a different animal from a chatbot.
A single agent run can touch customer records, internal documents, retrieved chunks, tool outputs, prompts, traces, and the final message back to the user. One invocation fans out across half your data estate. Then there is memory. Agents persist things, and whatever persists can feed future prompts, which means a prompt injection that lands today can be stored and re-triggered next month.
Three failure modes show up repeatedly in the field, and Composio's taxonomy is the cleanest version of them:
- Identity flattening. The agent acts under one system-admin key instead of the end user's permissions, so every user effectively borrows the most powerful account in the building.
- Intent blindness. Your API gateway manages requests, not intent. It cannot tell "read this invoice to summarize it" from "read every invoice to exfiltrate them."
- Governance vacuum. No central kill switch. Revoking a misbehaving agent's access requires a code deployment, which is a strange definition of "emergency stop."
Auditors reuse old questions. Agents give worse answers.
Most SOC 2 auditors do not have an "AI agent" worksheet yet. They have logical access criteria, monitoring criteria, data lifecycle criteria. ISO 42001 layers an AI management system on top, and the EU AI Act adds teeth (penalties at the ceiling reach €35M or 7% of global revenue, per VDF AI's framing of the regulation). The questions underneath are familiar. The problem is that a default agent deployment answers them badly: access runs through one shared key, logs are scattered across a vendor console and a vector database, and nobody has ever tried to delete an embedding.
So build the answers before the questions arrive.
The six-control checklist
Each control lists the auditor question it answers and the artifact it should produce. If a control generates no document, assume the auditor treats it as absent.
1. Register every agent, or admit you have shadow ones
Microsoft's line is blunt: "You can't govern agents you don't know exist." Their guidance calls for a single organizational inventory tracking ownership, purpose, platform, and access scope, with every agent meeting minimum requirements before it operates.
The artifact is a registry. A YAML file in a repo is fine to start:
- agent: invoice-chaser
owner: j.okafor@example.com # a named human, not a team
purpose: draft payment reminders in the ERP
model: approved-catalog-id-114 # must come from the approved-model catalog
data_sources: [erp.invoices:read, crm.contacts:read]
tools: [erp.read_invoice, email.draft]
access_scope: tenant finance-eu only
approval_date: 2026-05-14
last_review: 2026-08-01Auditor question answered: "List every AI system in production, its owner, and what it can reach." Review the registry quarterly and record the date in the file itself.
2. Classify data before the agent sees it
You cannot scope access until you know what the data is. The agentsecurityaudit.com checklist uses seven classes worth stealing: public documentation, internal non-sensitive content, customer confidential data, personal data, secrets and credentials, regulated or contract-restricted data, and cross-tenant or cross-customer data.
The output is a matrix: agent, data source, class, allowed or denied. My recommendation is a hard default-deny on secrets and regulated classes unless a named exception with an expiry date exists. That flips the internal conversation from "why did you block the agent" to "why did you approve the exception," which is where it belongs.
Auditor question: "What classes of data can each agent reach?" Evidence: the matrix plus the dated exception list.
3. Enforce authorization in code, not in the prompt
The most important sentence in that checklist: "Prompt instructions can remind an agent about policy, but they should not be the policy enforcement mechanism. Deterministic authorization must happen outside the model."
Concretely: check the end user's identity and role before retrieval, not after generation. Enforce tenant, project, and record-level boundaries in the retrieval layer. Scope tools so read-only and write actions are separate permissions. Filter retrieval sources server-side. And kill identity flattening by having the agent act on behalf of the requesting user, inheriting that user's permissions, instead of holding a god-mode service key. If your vendor's architecture requires a single admin token, that is the finding your auditor eventually writes.
A policy sketch, in whatever engine you run:
deny if record.tenant != request.user.tenant
deny if source.class in {secrets, regulated} and agent.id not in exceptions
deny if tool.scope == write and action not in approved_planAuditor question: "Prove the agent cannot reach anything the requesting user could not reach directly." Evidence: the policy file plus test logs showing denied attempts.
4. Treat inference, logging, evaluation, and training as four separate data uses
A vendor that says "we don't train on your data" may still retain detailed traces and tool outputs. Evaluate each use separately: inference, logging and traces, evaluation datasets and analytics, training and fine-tuning. Each gets its own opt-out decision and its own retention window.
Produce a one-page data use register per vendor: which uses are active, which are opted out, how long traces live, where they are stored. It takes an afternoon to write and answers the two questions that stall most customer security reviews: "is our data used for training?" and "where do prompts and traces go?"
5. Trace every run and gate the actions that matter
VDF AI's control set calls for execution traces capturing prompts, retrieval events, tool calls, approvals, and outputs. That granularity is right. When something goes wrong, "the model decided to" is not an incident timeline.
Two additions make traces defensible. First, human approval for high-impact steps: anything that moves money, mutates records customers can see, or sends external communication should pause for a named approver. The pause has to be a native suspend and resume, not a killed process, or people will route around it. Second, a kill switch that revokes access without a code deployment. If revocation requires a deploy, you have a change request, not an emergency stop.
Auditor questions: "Reconstruct what the agent did on this date" and "who approved this refund?" Evidence: a sample trace export and approval records with timestamps.
6. Prove deletion works, including the weird stores
Deletion is where agent programs quietly fail. Customer data no longer lives in one table. It lives in embeddings, vector indexes, agent memory, logs, traces, approval records, evaluation datasets, and backups. The checklist's standard is blunt: "If a team cannot explain how to delete or export agent-related data, the system is not production-ready."
Write the runbook, then run it. Pick a test customer, execute deletion across every store on the list, record start and end timestamps, and verify nothing resurfaces in retrieval afterward. Quarterly is a defensible cadence. The artifact doubles as your answer to data subject requests.
If you are buying a platform, ask the rude questions
Composio's vendor evaluation list includes three questions I now reuse verbatim:
- Can you intercept a specific tool call based on intent and confidence, even when the agent has technical permission to make it?
- Can you pause an agent mid-loop for human approval without breaking its state?
- How do you handle OAuth token refresh at scale while acting on behalf of each end user?
And listen for one red flag: "we rely on your prompt engineering for that." That sentence means enforcement lives inside the model, which contradicts control 3. The answer you want is a policy engine, OPA or a secondary model, scoring intent before the request reaches the API.
The pushback: "This is paperwork, and we are not a bank"
Fair. Nobody at a 40-person company is certifying against ISO 42001 this quarter. But look at the actual cost: a YAML file, a classification matrix, a policy file you needed anyway, a one-page register, logging you should already have, and one deletion drill. Every item produces evidence as a side effect of doing the work. That is the design. The expensive version of this story is not the paperwork. It is the incident review where nobody can reconstruct what the agent did, or the enterprise deal that dies in security review because "is our data used for training?" took three weeks to answer.
Note what is deliberately missing: no platform purchase, no governance hire, no committee. If your deployment grows past a handful of agents, Microsoft's four-layer reference architecture (data governance and compliance, observability, security, development) is a reasonable map of what to formalize next, and it maps to services like Purview and Sentinel that you may already pay for.
The checklist on one page
| Control | Auditor question it answers | Evidence it produces | Framework anchor |
|---|---|---|---|
| Agent registry | Which agents exist, who owns them | Registry export with review dates | SOC 2 change management; ISO 42001 system inventory |
| Data classification | What data each agent can reach | Agent-source-class matrix | SOC 2 confidentiality; ISO 42001 data controls |
| Authorization outside the model | Agent access mirrors user access | Policy file, denial test logs | SOC 2 logical access |
| Split data uses | Training use? Trace retention? | Data use register per vendor | SOC 2 confidentiality; EU AI Act data governance |
| Traces, approvals, kill switch | Reconstruct a run; who approved | Trace exports, approval records | SOC 2 monitoring; EU AI Act record-keeping |
| Testable deletion | Delete this customer's data | Runbook, dated drill results | SOC 2 data lifecycle; erasure obligations |
Key takeaways
- The 78% figure is unverified, but the governance gap it describes is confirmed by every serious framework published on the topic. Do not wait for a better statistic.
- Start with the registry. Untracked shadow agents are the one finding an auditor can write without testing anything at all.
- Enforcement belongs in application logic. A prompt that says "do not access payroll" is a wish, not a control.
- Every control must produce a document. If it generates no evidence, auditors treat it as nonexistent.
- Test deletion quarterly across embeddings, memory, traces, and backups. It is the control most likely to fail in practice and the easiest to verify before someone else asks.
