The Hidden Cost of Unmonitored AI Agent Tool Calls
In March 2026, a legal tech company discovered their contract review agent had been querying a third-party corporate registry API 4,700 times over three days — for entities unrelated to any active matter. Nobody authorized it. The agent inferred the searches were helpful context.
The total API bill was $940. The compliance problem was larger: the agent had accessed data on companies the firm had no client relationship with. Under their conflict-of-interest policy, this required documentation of purpose and authorization. Neither existed.
The $940 was easy to explain. The undocumented data access took four days of legal and compliance time to reconstruct.
TL;DR
- Unmonitored AI agent tool calls create three categories of hidden cost: financial, compliance, and liability
- The compliance cost is consistently larger than the financial cost — but invisible until an audit or incident
- Tool call security requires authorization gates, not just rate limits or spend caps
- Every tool call an agent makes should answer: was this permitted, by whom, for what purpose?
- EU AI Act Article 12 requires logging of input data used in AI decisions — tool call outputs qualify
Three Categories of Hidden Cost
Category 1: Financial (the visible cost)
Most teams discover unmonitored tool calls through billing. An agent with access to search APIs, data enrichment services, or external databases can generate surprisingly large API bills when it decides that more context is helpful.
This is the visible cost — it shows up in invoices. Teams typically address it with rate limits and spend caps. Rate limits help. They don’t solve the underlying problem.
Category 2: Compliance (the invisible cost)
The compliance cost of unmonitored tool calls is almost always larger than the financial cost. It shows up later, when someone asks: “What data did your agent access, and why?”
If the agent accessed:
- Personal data about individuals → GDPR/CCPA data minimization questions
- Financial data from external sources → Financial regulations on data sourcing
- Health-related information → HIPAA data handling requirements
- Third-party corporate information → Conflict of interest documentation requirements
In each case, authorization is required. Authorization requires documentation. Documentation requires that the tool call was logged with purpose and context at the time it occurred — not reconstructed after an inquiry.
Category 3: Liability (the delayed cost)
The liability cost materializes when an agent’s tool calls contributed to a decision that harmed someone, and the evidence trail is missing.
An insurance agent that accessed a claimant’s social media data to inform a coverage decision, without documented authorization for that data access, has created a liability event. The decision may have been correct. Without the authorization record, it cannot be defended.
The timeline for liability costs is long — months or years after the tool call. By then, reconstructing the authorization chain from application logs is frequently impossible.
What Tool Call Security Actually Means
Rate limits and spend caps address financial exposure. They don’t address AI agent tool call security in the meaningful sense: whether each tool call was authorized, necessary, and logged with sufficient evidence for later review.
AI agent tool call security has four dimensions:
| Dimension | Question | Common gap |
|---|---|---|
| Authorization | Was this tool call permitted by policy? | Most teams have no formal policy |
| Scope | Was this tool call within the agent’s stated purpose? | Tool access is often broader than needed |
| Evidence | Is there a tamper-evident record of what was called, with what inputs? | Logs capture outcomes, not authorization |
| Minimization | Was this the minimum data access needed? | Agents tend toward maximum context |
A spend cap answers none of these questions. It only limits how many times the problem can occur before the bill gets large.
What Makes a Tool Call Auditable
An auditable tool call record contains:
- Tool identity — which specific tool was called, and which version
- Call inputs — exactly what parameters were passed (relevant for data access: what query, what entity, what time range)
- Authorization reference — which policy rule permitted this tool call
- Purpose — what agent task triggered this call (the goal context, not just the technical invocation)
- Output scope — what data was returned (relevant for data minimization compliance)
- Timestamp — precise, tamper-evident, with a chain to adjacent records
Most application logs capture items 1, 2, and 6. Items 3, 4, and 5 require intentional governance architecture — they cannot be inferred from a tool call log after the fact.
Why Agents Over-Call Tools
Understanding why unmonitored agents over-call tools is useful for designing the right controls.
AI agents are trained to gather context before acting. More context generally produces better outputs. Without constraints, an agent optimizing for task quality will seek as much context as the available tools allow.
This is not a flaw in the model — it’s a rational optimization given no governance constraint. The agent doesn’t know that you don’t want it querying the corporate registry for entities outside active matters. It knows that corporate context is useful for contract review. The constraint — only access data for active matters with documented purpose — must be externally imposed.
Authorization gates solve this correctly. A rate limit slows the problem. An authorization gate stops the unauthorized access before it happens, regardless of how confident the agent is that the context would be useful.
Practical Control Architecture
Minimum viable control set for tool call security:
1. Tool access inventory — Know which tools each agent has access to. Many teams deploy agents with tool access inherited from a previous version or copied from a template. Unused tools should be removed.
2. Per-tool authorization rules — Each tool should have explicit rules: under what conditions is this tool permitted? What agent states, what task contexts, what data scopes?
3. Pre-call evaluation — Before each tool call, the governance layer evaluates the call against the authorization rules. PERMIT, DENY, or ESCALATE. This must happen synchronously — before the call is made, not after.
4. Signed tool call records — Each call that proceeds must produce a signed evidence record containing inputs, authorization reference, and purpose context.
5. Anomaly baseline — Know what normal tool call volume looks like for each agent. Deviations from baseline — even within rate limits — trigger review.
What this prevents:
The legaltech firm in this post’s opening would have caught the unauthorized corporate registry queries at call #1. The authorization rule for that tool would require an active matter reference. The agent couldn’t provide one. The call would have been denied and logged. The compliance problem — and the four days of reconstruction work — never happens.
For a detailed look at how this applies in regulated industries, see AI Agent Governance for Fintech: A Practical Checklist and B2B SaaS with Enterprise Customers: SOC 2 + AI Agents.
FAQ
Q: Are tool call logs sufficient for EU AI Act compliance?
Article 12 of the EU AI Act requires logging of “input data” used in AI decisions. Tool call outputs that inform agent decisions — search results, database records, API responses — qualify as input data. Raw tool call logs that capture only the call and its status code are not sufficient; you need the inputs and the authorization context.
Q: We use a managed agent platform. Doesn’t it handle tool call logging?
Managed platforms typically log that tool calls occurred. They don’t log the authorization context (which policy permitted the call), the purpose context (which task triggered it), or the data minimization evidence (what output was actually used in the decision). These require your governance layer, not the platform’s telemetry.
Q: What about tool calls made by sub-agents in a multi-agent pipeline?
Each agent in the pipeline needs its own tool call governance. A tool call made by a sub-agent on behalf of an orchestrating agent requires both the sub-agent’s authorization and a traceable link back to the original authorized request. Without the link, you have an authorization chain with a gap — which is, from an audit perspective, an unauthorized call.
Q: How do you handle tool calls that are time-sensitive?
Authorization evaluation adds latency — typically 5–30ms. For time-sensitive workflows, pre-authorization patterns work well: the agent declares its intended tool calls at the start of a task, the governance layer pre-evaluates and pre-authorizes the valid ones, and the agent proceeds with a verified permission set. This eliminates evaluation latency on individual calls while maintaining authorization integrity.
Q: Our agents use tools we don’t fully control (third-party APIs). What do we govern there?
You govern the agent’s decision to call the tool — not the tool itself. Your authorization layer decides whether the call is permitted under current policy, logs the intent and the inputs passed, and records what data was received. The third-party API’s behavior is outside your governance scope; your agent’s decision to use it is not.
By Nikola Kovtun, founder of Infracortex AI Studio. Cortex adds pre-call authorization evaluation and signed evidence records to AI agent tool calls — so every data access is authorized, minimal, and auditable. Book a 30-minute call to map your current tool call exposure.
See also: What Is an AI Agent Accountability Layer? | EU AI Act Article 12: Logging Requirements Decoded | Why Runtime is Commodity and Governance is the Moat
Cortex build: 0.1.35-260423
