Auditing agent tool calls in Claude Code
A backend service goes down at 2am. The on-call engineer pages. The cause: a migration ran against production without going through the staging path. The change was committed by an AI agent — Claude Code, invoked by a senior engineer earlier that day.
The post-mortem question is the one every engineering leader will hit this year. Which tool call did this, why, and based on what?
The git history shows the engineer's name. The platform logs show the model. But the chain in between — what prompt produced the tool call, what skill was active, what context the agent had, who approved that skill, whether the engineer reviewed the action before letting it run — that chain doesn't exist anywhere.
You can audit code. You can audit commits. You can't audit agent reasoning, because the artefact disappears the moment the agent finishes generating it.
The thinking trajectory
A meaningful audit record isn't “the agent called the bash tool with these arguments.” That's the surface. The audit record is the thinking trajectory — the full causal chain that produced the call. The industry is settling on the term. It's the right one.
The full record needs:
- The user identity and the engineer's intent — what they asked for
- The agent identity and the model version that processed it
- The active context — which prompt, which conversation, which skills were loaded
- The skill that produced the tool call — which one, what version, who authored it, who approved it, when it was approved
- The tool that was invoked and the arguments passed
- The result returned and any error
- The approval state — did a human approve this action, or did the agent execute autonomously
- The timestamp and the duration
This is more than logging. It's reconstruction. When something goes wrong six months later, you want to answer who was responsible for the rule the AI followed, and whether that rule was reviewed.
Most teams capture one or two of these. Almost none capture the full thinking trajectory.
Where tool calls happen, and where you can intercept them
There are four layers where you can audit agent tool calls. Each has trade-offs.
Application layer. Wrap the tool functions in your own code with logging. Works if you control the application, but every team has to wrap every tool, and external tools you don't control are invisible.
MCP server layer. If your agents use MCP servers, the MCP layer is a natural choke point. Log every request and response that flows through. Works well for centralized tools — CRM access, deployment APIs, internal services. Badly for anything local — shell, file system, ad-hoc scripts.
Harness layer. Claude Code, Cursor, and other harnesses expose hooks for tool-use events. This is the closest you'll get to a complete record, because the harness sees every tool call regardless of source. The catch: the hook fires per-event, not per-agent-session, so you stitch causality back together yourself.
Network layer. Proxy outbound calls and log them. Catches anything that crosses the wire. Misses anything local — file writes, shell commands that don't make external calls, in-process actions.
In practice, platform teams that take this seriously end up with a combination. Harness hooks for completeness. MCP layer for the tools that matter most. Application-level logging for privileged operations. The expensive part isn't any single layer. It's getting them to produce records that join.
What a complete thinking trajectory contains
Not all logs are audit records. A log line is data. A thinking trajectory is a contract.
A complete trajectory for an agent tool call carries, at minimum:
- An invocation ID that joins all events in this agent's turn
- A session ID that joins all turns in this agent's run
- The user ID and the user prompt that initiated the chain
- The model name and version
- Which skills were loaded and at which versions
- The specific skill that produced this tool call, or the prompt-only path if no skill was involved
- The tool name and a structured representation of the arguments
- The return value or error, captured with the same structure
- The approval state — auto, human-approved, denied
- The wall-clock timestamp and the duration
This is the minimum. If you log less, you can identify that something happened. You can't always identify why.
The hardest part: linking tool calls to skill provenance
This is where most teams stop solving and start hoping.
Your agent ran a tool call. Why? Three possible chains:
- The user typed the request directly into the agent. No skill involved.
- The user typed a high-level request, a skill matched, and the skill produced the tool call.
- The user typed a request, one skill matched, then a second skill chained off the first and produced the call.
These three chains look identical at the tool-call layer. They are very different from a governance perspective. In case one, the user owns the action. In case two, the skill's owner does. In case three, responsibility has a graph of owners.
For audit and accountability to work, every skill invocation has to leave a structured trail with skill identity, version, scope, and approver chain. The tool call has to inherit that trail. The thinking trajectory has to include skill provenance, or it's incomplete. When the auditor asks why the agent did this, the answer has to be a graph, not a guess.
This is the layer that's not solved by logging. It requires skills themselves to be first-class objects with identity and metadata — and the system loading them into the agent's context to carry that metadata into the audit record.
What Invoked adds to the thinking trajectory
Invoked treats skills as first-class audit objects. Every skill has an owner, a version, an evaluation result, a scope, and an approver chain — captured at publish time, not reconstructed after the incident.
When an agent loads a skill from the Invoked-managed Enterprise layer, the load is logged with full skill metadata. When that skill produces a tool call, the call carries the skill's identity forward into the audit record.
When you reconstruct an incident, you don't get “the agent ran tool X with arguments Y.” You get: this user prompted this agent, the agent loaded these skills, this specific skill at this specific version produced this specific tool call, the skill was authored by this person and approved by this person on this date, the scope permitted this action against this resource.
That's the thinking trajectory. That's what a complete audit record looks like.
The harness logs are still useful. The MCP logs are still useful. Invoked doesn't replace them. It adds the missing layer underneath — the provenance of the rule the AI followed.
Where to start
If your platform or security team is running Claude Code, Cursor, or an internal copilot across engineering, this is the audit gap you'll be asked about by the time the first incident reaches the executive review.
A free Invoked exposure scan reads the skill paths your AI agents already discover from — read-only, no source code, no installation — and produces a map: every skill in use, who built it, whether it's been reviewed, and what the audit picture currently looks like.
→ Invoked for Platform Teams — the broader case for governing the skills your engineers' AI runs.
→ Invoked for Security Teams — inventory, approval, and fleet-wide revocation for agent skills.
→ Your AI hasn't read the onboarding doc — why training engineers isn't enough anymore.