Your AI Agents Are One Audit Question Away From a Finding

There's a number going around security circles: 78% of organizations run AI agents against sensitive data with no meaningful compliance steps behind them. I tried to trace it to a primary source and came up empty, so treat it as directional. The premise underneath is solid though. Teams are shipping agents that act with delegated authority across business systems much faster than they're building any control plane around them.

When the auditor shows up, they won't ask whether your agents are safe. They'll ask what auditors always ask. Who can access what. Show me the logs. Prove you can delete a customer's data. A default agent deployment answers all three badly. Access runs through one shared admin key, so every user effectively borrows the most powerful account in the building. Logs are split between a vendor console and a vector database. And nobody has ever tried to delete an embedding.

So build the answers before the questions arrive. Six controls, each mapped to the question it answers and the artifact it produces. If a control generates no document, assume the auditor treats it as absent.

The checklist

1. Register every agent. Microsoft's line is blunt: you can't govern agents you don't know exist. A YAML file in a repo is fine to start.

- agent: invoice-chaser
  owner: [e-mail]      # a named human, not a team
  purpose: draft payment reminders in the ERP
  model: approved-catalog-id-114
  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-01

Answers: "List every AI system in production, its owner, and what it can reach."

2. Classify data before the agent sees it. The output is a matrix: agent, data source, class, allowed or denied. 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.

3. Enforce authorization in code, not in the prompt. Prompt instructions can remind an agent about policy, but they should never be the enforcement mechanism. Check the end user's identity and role before retrieval. Enforce tenant and record boundaries in the retrieval layer. Have the agent act on behalf of the requesting user 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.

4. Treat inference, logging, evaluation, and training as four separate data uses. A vendor saying "we don't train on your data" may still retain detailed traces. One page per vendor: which uses are active, which are opted out, how long traces live. It takes an afternoon and answers the two questions that stall every security review.

5. Trace every run and gate the actions that matter. Anything that moves money, mutates customer-visible records, or sends external communication should pause for a named approver. And get a kill switch that revokes access without a code deployment. If revocation requires a deploy, you have a change request, not an emergency stop.

6. Prove deletion works, including the weird stores. Customer data lives in embeddings, vector indexes, agent memory, logs, traces, backups. Write the runbook, then run it: pick a test customer, delete across every store, verify nothing resurfaces in retrieval. Quarterly is a defensible cadence.

"This is paperwork, and we're not a bank"

Fair. But look at the actual cost: a YAML file, a matrix, a policy file you needed anyway, one page per vendor, logging you should already have, one deletion drill. Every item produces evidence as a side effect of doing the work. That's the design. The expensive version of this story is the incident review where nobody can reconstruct what the agent did, or the enterprise deal that dies in security review.

One vendor red flag tells you most of what you need: "we rely on your prompt engineering for that." That means enforcement lives inside the model, which contradicts control 3. The answer you want is a policy engine scoring intent before the request hits the API.

Stuff you can do this week:

• Create the agent registry, one named human owner per agent, review date recorded in the file itself
• Flip secrets and regulated data classes to default-deny with expiring, named exceptions
• Move one authorization check out of a system prompt and into your retrieval layer
• Run a deletion drill on a test customer, embeddings included, and record the timestamps

Which of the six would be hardest in your stack? My money is on deletion, but I'd love to hear from anyone who's actually run that drill against their vector store.

Longer writeup with the full argument and vendor evaluation questions: https://axeploit.com/blog/your-ai-agents-are-one-audit-question-away-from-a-finding