Resources · Evidence guide
Questions your auditor will ask about AI agents
When operational resilience reviewers, PRA examiners, or internal audit look at AI in the business, the questions are predictable. What follows is the list - what answering each one takes, across the people who use AI chat and the agents that call your tools, and where I help.
“Which AI agent touched which record, and when?”
The question most MCP deployments cannot answer today. The control that answers it is a structured audit row for every agent tool call, written at the boundary between the agent and your systems: agent identity, tool name, masked arguments, policy decision, latency, and upstream response status. Stream those events to a queryable sink (Log Analytics, an OTLP collector) and the answer becomes a query rather than an archaeology project.
AI Governance & Security consulting →“How do you keep cardholder and personal data out of logs and prompts?”
Treat enforcement and evidence masking as separate controls. Deny-patterns can block a tool call before it reaches the downstream system; detectors for common sensitive values (card numbers, credentials, identifiers) can mask the audit copies; and response DLP can rewrite what comes back to the agent. Masking an audit copy does not rewrite the live request - reviewers will check that you know the difference, and none of it by itself certifies PCI DSS compliance.
AI Governance & Security consulting →“Who authorised this agent to call that tool?”
Authorisation has to be evaluated before the call is made: identity rules per route and tool, required scopes and roles from the token, time windows, rate limits and argument patterns. Many deployments run such policy in audit-only mode first - logging a would-block decision while still forwarding the call - so reviewers should check both the policy and its enforcement mode.
AI Governance & Security consulting →“What are your people pasting into AI chat?”
The half of the question most AI governance misses. The workable pattern is a control at the point of use - in the browser, before Send - that checks drafts against policy locally and emits metadata-only events: which detector fired, on which site, at what time, never the message text. That gives the audit trail evidence of policy working without creating a new store of sensitive content.
AI Governance & Security consulting →“Where does the evidence live, and who can see it?”
Sink ownership is the control. Evidence should be written to infrastructure the organisation controls - your subscription, your log workspace, your retention policy - not a vendor’s. Where a vendor backend is unavoidable, metadata-only storage keeps message and record content out of scope entirely. Either way, the answer an auditor wants is a named system, a named owner, and an access list.
How I approach security →“Which regulatory frames does this evidence support?”
For UK teams, common mappings include UK GDPR and Data Protection Act safeguards, FCA / PRA operational-resilience evidence, and PCI DSS controls where payment-card data is in scope. Controls and evidence support these frames; your organisation and its advisers decide applicability, scope and whether the wider control environment meets a requirement.
AI Governance & Security consulting →Facing one of these questions right now?
Tell me the shape of your deployment and the regulatory frame you answer to, and I will come back with a concrete next step - usually the specific evidence the reviewer is looking for.