Orphaned AI Agents and the Tool-Call Audit Gap
Orphaned Agents, and the Audit Gap Beneath Them
Most regulated firms cannot say which AI agent touched a customer record last week, or whether that action was allowed.
That sounds dramatic until you try to answer it inside a real organisation.
AI adoption has moved quickly. Teams have built research assistants, reconciliation helpers, ticketing agents and workflow automations. Each one may be useful in isolation, but many were created faster than the surrounding controls.
Human access governance has not always been extended to cover agents.
The current conversation is about orphaned agents, and rightly so. But orphaned agents are only the visible edge of a larger problem.
The Orphaned Agent Problem
An orphaned agent is one that keeps running after the person who created it has left.
The employee account may be deprovisioned, but the agent can still be:
- Calling tools
- Reading databases
- Triggering workflows
- Accessing internal systems
- Operating with no clear owner
Inventory helps. Ownership mapping helps. You need to know which agents exist and who is responsible for them.
But inventory does not tell you what the agent actually did.
Inventory Is Not Audit
A register can tell you an agent exists.
It cannot tell you:
- Which tool the agent called at 3am
- What data it passed as arguments
- Whether the call was inside policy
- Whether sensitive data leaked into the log store
- Why a request was allowed or denied
That evidence lives somewhere else.
It lives at the tool-call layer.
The Tool Call Is the Unit of Evidence
Every meaningful action an agent takes against a backend system is a tool call.
It might:
- Query a database
- Read a customer record
- Post a journal entry
- Update a ticket
- Trigger a workflow
- Call an internal API
That call is the unit of behaviour, so it has to become the unit of audit.
For a regulated firm, the questions are straightforward:
- Which agent made the call?
- How was its identity verified?
- What policy allowed or denied it?
- Were card numbers, National Insurance numbers, emails or other sensitive fields masked before anything reached the logs?
- Can compliance query the record without asking engineering to reconstruct it afterwards?
Most firms cannot answer those questions cleanly yet.
Why MCP Servers Leave This Gap
MCP servers are becoming the standard way to connect AI agents to backend systems.
Their job is to expose tools. That is useful, but most MCP servers do not provide the controls regulated firms need by default:
- No consistent audit trail
- No policy enforcement
- No redaction before logging
- No structured deny reason
- No single control surface across tools
That is not a criticism of the protocol. Logging, authorisation and masking are cross-cutting controls.
The control surface has to sit somewhere.
Today, for many firms, it sits nowhere.
The agent calls the server. The server runs the tool. The only evidence is whatever happens to land in application logs that were never designed for attributable, policy-gated, redacted records of automated actions against regulated data.
What Auditors Will Ask
This gap maps onto controls firms already recognise:
- Attributable access
- Approved policy
- Deny-by-default posture
- Sensitive data masking
- Rate and time controls
- Structured audit trails
- Evidence compliance can query directly
Agent audit is not a new expectation. It is an existing control problem applied to a new kind of actor.
Inventory and Tool-Call Audit Are Different Controls
Agent inventory answers one question:
Who owns the agent?
Tool-call audit answers another:
What did the agent do, and was it allowed?
A mature AI governance programme needs both.
Confusing the two leaves a firm thinking it has coverage when it does not.
What I Am Building
The MCP Audit & Compliance Gateway sits in front of MCP servers.
Agents point at the gateway instead of the server. There is no change to agent code, and the backend system does not need to know the gateway exists.
Every tool call is:
- Identity-verified
- Checked against policy
- Evaluated by identity, arguments, rate and time of day
- Redacted for sensitive data
- Written as a structured audit row
- Sent to the firm’s existing log sink
It runs inside the firm’s own environment, so data stays inside the perimeter.
It is available as:
- An Azure Managed Application
- A generic Docker image
The Question to Ask Internally
Set the product aside and the question still stands:
Who owns AI agent tool-call audit at your firm, separate from whoever owns the agent inventory?
If the honest answer is “nobody”, that is the gap.
You cannot evidence what you never recorded.