Tool misuse in agentic apps exposes a missing policy layer

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: Trusted agentic apps can exfiltrate data or trigger unsafe actions by combining individually valid tool calls into harmful sequences.

Why it matters: It matters because IAM and authorisation alone do not govern how AI agents use tools at runtime, so practitioners need policy controls that inspect arguments, call order, and risk.

Context

Agentic tool misuse is a governance gap in which a trusted AI agent can call approved tools in an unsafe order or with unsafe arguments. The problem is not that the tools are unauthorised in isolation, but that the overall action chain can create data loss, unwanted disclosure, or destructive changes.

For IAM, PAM, and NHI teams, this shifts the control question from who can call a tool to how a tool call behaves inside a session. In agentic environments, the policy boundary has to move closer to execution time because static permission checks do not evaluate sequence, context, or intent.

WorkOS frames this as ASI02 in the OWASP Top 10 for Agentic Applications: tool misuse and exploitation. That framing is useful because it separates tool trust from invocation trust, which is now a distinct security problem for AI agent governance.

Key questions

Q: What breaks when agentic tools are authorised but invocation policy is missing?

A: Authorisation still allows the agent to use legitimate tools, but it does not prevent harmful combinations of calls. Without invocation policy, a database read, file write, and email send can become exfiltration even though each individual step passed identity checks. The failure is at the chain level, where context and sequence matter more than a single permission decision.

Q: Why do tool calls need context-aware policy in agentic apps?

A: Because a safe tool in isolation can become unsafe in a specific sequence or with unsafe arguments. Context-aware policy evaluates what was called before, what arguments are being passed, and whether the overall pattern matches the task. That is the only way to distinguish a legitimate workflow from prompt-injected or scope-drifting behaviour.

Q: How should security teams decide when to block or approve an agent tool chain?

A: Start by blocking clearly dangerous patterns such as data exfiltration or destructive actions. Use approval for ambiguous sequences that might be legitimate in context, and keep logging patterns you are still learning about. The decision should be based on chain risk, reversibility, and how much damage the sequence can cause before human review.

Q: What is the difference between tool authorization and invocation policy for AI agents?

A: Tool authorization asks whether the agent may call a tool at all and on which resource. Invocation policy asks whether the specific call, arguments, and sequence are acceptable in the current context. The first is an identity question, while the second is a runtime safety question about how the agent is using its approved access.

Technical breakdown

Why authorization does not catch unsafe tool chains

Authorization answers a narrow question: is the actor allowed to use this tool on this resource? In agentic systems, that is necessary but incomplete. A database query, a file write, and an email send can each pass RBAC or FGA checks while the combined sequence becomes exfiltration. The failure is not at the tool boundary alone, but at the lack of context-aware policy enforcement across the session. Invocation policy has to inspect arguments, prior calls, and the purpose of the chain before execution proceeds. That is a different control plane from identity authentication or resource-level authorization.

Practical implication: Treat tool-level authorization as the floor and add invocation policy that evaluates call context before a chain can continue.

How argument validation limits tool misuse

Argument validation constrains what a permitted tool call can actually do. A query tool that accepts arbitrary SQL, a file writer that accepts arbitrary paths, or an HTTP tool that accepts arbitrary URLs creates a broad misuse surface even when the agent is authenticated and authorised. Validation at the invocation boundary reduces the tool from a generic executor to a bounded action. In practice, this means defining allowable parameters, denying unspecified tools by default, and rejecting calls whose arguments expand scope beyond the intended task. The key point is that safe identity does not rescue unsafe parameters.

Practical implication: Validate every high-risk tool argument before the MCP server executes the call.

What chain and context analysis adds to agent governance

Chain analysis looks at the sequence of calls rather than a single action. A read, then write, then send pattern may be normal, but it may also be a data exfiltration route. Context analysis goes one level further by checking why the agent is taking the path it is taking, including whether prompt injection or task drift is steering the sequence. These controls are essential because the harmful outcome often appears only when individually legitimate actions are composed together. Risk-based response matters too: some patterns should block, others should pause for approval, and some should only be logged until they are proven dangerous.

Practical implication: Track tool sequences per session and escalate only the patterns that indicate real chain risk.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Invocation policy is the missing governance layer for agentic apps: Identity and authorization tell you who may act, but they do not tell you whether the action path is safe. When trusted tools can be combined into harmful sequences, the control failure sits between permission and execution. Practitioners should treat that gap as a distinct policy domain, not a tuning issue in existing IAM.

Least agency, not least capability, is the right operating model for agentic systems: The article shows that an agent can be fully authorised yet still unsafe if it can choose arguments and tool order without boundary checks. That makes runtime invocation constraints more important than expanding generic access rights. The field needs to govern how much agency each workflow receives, not just how much capability it can theoretically reach.

Tool-chain misuse validates the need for stepwise control inheritance: A database tool, file writer, and email sender may each be trusted, but trust does not automatically compose across the chain. Each step introduces a new opportunity for scope drift, prompt injection, or accidental exfiltration. The implication is that governance must be evaluated at the chain level, where the real security decision is made.

Tool misuse is an ASI02 problem, not just an IAM problem: The OWASP agentic security framing is useful because it separates safe identity from safe execution. In this model, IAM proves the agent can act, while policy enforcement determines whether it should continue. Practitioners should map agent workflows to ASI02-style misuse patterns and make invocation policy a first-class control.

Named concept: invocation trust debt: The article describes a recurring pattern where teams validate the agent, validate the tools, and still leave unsafe call composition ungoverned. That leftover exposure is invocation trust debt, the accumulation of risk created when runtime decisions are not bounded at the tool-chain level. Practitioners need to recognise that debt as a separate control gap.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 40 percent of financial and software companies have already deployed agentic AI systems, and deployments are expected to double by 2028.
• Read next: AI Agent Authorisation Guide

What this signals

Invocation trust debt: Agentic programmes accumulate risk when teams stop at authentication and role checks, because the unsafe part often emerges only when calls are chained. Policy has to move from static permissioning to runtime evaluation of tool arguments and session context.

Control design for agentic systems should assume that a trusted tool can still become unsafe in combination with other trusted tools. That changes the practitioner focus from whether the agent may act to whether its next action remains inside an approved execution pattern.

For practitioners

• Implement argument validation at the tool boundary Define allowed parameters for each high-risk tool, reject unspecified inputs by default, and block calls that expand scope beyond the task.
• Add session-level chain analysis Track the order of tool calls within a session so database-to-file-to-email or similar patterns can be flagged before completion.
• Classify tool risk by reversibility Treat read actions as low risk, reversible writes as medium risk, and destructive actions such as deletes or external sends as high risk requiring approval.
• Run policies in audit mode before enforcement Log denied and permitted calls, review false positives and true positives, and only then turn on blocking for the highest-risk tools.
• Require plan validation for multi-step tasks Ask the orchestrator to compare the declared plan with the original request and stop workflows that introduce tools outside the expected set.

Key takeaways

• Agentic tool misuse is a runtime control problem, not simply an identity problem, because valid permissions can still produce harmful outcomes.
• The critical evidence is the call chain itself, where individually safe database, file, and email actions can combine into exfiltration.
• Invocation policy, argument validation, and session-level chain analysis are the controls that reduce this specific agentic risk.

Key terms

• Invocation Policy: Invocation policy is the control layer that evaluates each tool call an agent tries to make. It checks whether the action, arguments, sequence, and destination fit the approved rules, helping prevent injected intent from becoming unbounded execution.
• Tool chain: A tool chain is the ordered sequence of calls an agent makes to complete a task. In agentic systems, the chain can be the real attack surface because a set of individually valid actions may produce exfiltration, misuse, or destructive outcomes when combined.
• Chain Analysis: Chain analysis is the process of stitching related events into a sequence that shows how an activity unfolded over time. In practice, it helps analysts move from alert triage to evidence-based investigation by linking what happened before, during, and after an anomaly.
• Action classification: Action classification groups tool calls by their operational impact, such as read, reversible write, or destructive action. It helps practitioners decide when a task needs approval, when circuit breakers should trip, and which calls deserve tighter runtime controls.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.