They often treat a typed tool call as if it were already approved. In practice, a tool call is only a request with structured arguments. The security boundary sits after the call is formed, where identity, policy, and audit determine whether the action may proceed.
Why This Matters for Security Teams
tool calling changes the risk profile of AI systems because it turns a model response into a potential action path. The important question is not whether the call was syntactically valid, but whether the requested action fits policy, identity context, and business intent. Security teams often miss that distinction and end up reviewing the model output instead of governing the action boundary. That gap is exactly where misuse, overreach, and weak auditability appear.
Current guidance from the NIST Cybersecurity Framework 2.0 supports treating identity, authorization, logging, and response as connected controls, not isolated checks. For AI systems, that means a tool invocation should be evaluated like a privileged request, especially when it can read data, modify records, trigger workflows, or call other services. The same discipline matters when agentic systems are layered into production APIs, because the model may be prompting the organisation to trust the wrong signal.
Teams also underestimate how quickly harmless-looking tools become high-impact when chained together. A calendar update, database query, or ticket creation action may seem low risk on its own, but the operational effect can become sensitive once the model can repeat, combine, or sequence those actions. In practice, many security teams encounter tool-calling abuse only after an unintended action has already been executed, rather than through intentional pre-production policy testing.
How It Works in Practice
Secure tool calling starts with a clear separation between request and authorization. The model may generate a tool name and arguments, but that output should pass through an enforcement layer that checks who or what is acting, what data is involved, whether the action is allowed, and whether the call is appropriate in the current context. This is where identity and policy become operational, not theoretical. If the tool can affect secrets, customer data, financial records, or infrastructure, the request needs the same kind of scrutiny applied to other privileged actions.
A practical control set usually includes:
- Schema validation so the call only accepts expected parameters and types.
- Policy evaluation so the request is checked against role, context, and purpose.
- Human approval for sensitive or irreversible actions where automation is not justified.
- Strong logging so the model prompt, tool request, decision, and result can be traced.
- Post-action monitoring so anomalous sequences can be detected and contained.
This approach aligns with the model-risk and abuse patterns described in MITRE ATLAS and the governance focus of the NIST AI Risk Management Framework. It also reflects current best practice for agentic systems: assume the model may be manipulated through prompt injection, tool output poisoning, or indirect instruction contamination, and therefore treat every tool request as untrusted until verified. Where organisations expose tools to external users or untrusted content, a robust design also checks that retrieved data cannot silently alter tool intent.
In deployment, the safest pattern is to bind each tool to a narrowly scoped service identity, limit the callable surface, and separate read-only from write-capable operations. That is especially important when the tool can reach downstream systems such as ticketing, cloud control planes, or content publishing workflows. These controls tend to break down when teams expose broad-purpose tools to loosely governed agents because the policy layer cannot reliably distinguish legitimate task completion from model-driven overreach.
Common Variations and Edge Cases
Tighter tool authorization often increases latency and implementation overhead, requiring organisations to balance automation speed against control assurance. That tradeoff becomes more visible in high-volume environments where teams want the model to act quickly, but the blast radius of a bad call is large.
One common edge case is read-only tool access. Read-only actions still matter because data exposure can be as damaging as direct modification, especially when the tool returns secrets, personal data, or proprietary context that the model can reuse in later steps. Another is delegated access, where the user is permitted to ask the agent to act on their behalf. Best practice is evolving here, and there is no universal standard for how much user intent must be preserved across multi-step tool chains.
Agentic systems also create ambiguity around chained approval. A single low-risk call may be fine, but several sequential calls can create a meaningful business action that no single step would trigger on its own. Teams should define escalation thresholds for cumulative effect, not just per-call sensitivity. Where systems use retrieval or external plugins, the risk grows further because the tool prompt may be influenced by untrusted text that looks operational but is actually malicious instruction.
For governance and assurance work, practitioners should map tool-calling controls to OWASP guidance for LLM applications and to the organisation’s broader control baseline. The practical rule is simple: if a tool can change state, disclose sensitive information, or trigger another system, the call needs a real security decision, not just a syntactic check.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATLAS and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF, NIST AI 600-1 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | Tool calling needs governance, measurement, and accountability for AI risk decisions. | |
| MITRE ATLAS | ATLAS captures prompt injection and abuse patterns that can steer tool requests. | |
| OWASP Agentic AI Top 10 | Agentic AI risks include unsafe tool use, authorization gaps, and action chaining. | |
| NIST AI 600-1 | GenAI profiles emphasise secure deployment, validation, and misuse-resistant operation. | |
| NIST CSF 2.0 | PR.AC-4 | Tool calls should be authorized with least privilege before execution. |
Apply AI RMF governance to define ownership, review thresholds, and monitoring for tool actions.
