Tool misuse in agentic apps exposes a missing policy layer

At a glance

What this is: This is an analysis of tool misuse in agentic applications, showing that valid tool calls can still create harm when arguments, sequence, and context are not controlled.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern not just access entitlement but runtime behaviour across AI agents, service identities, and human-approved workflows.

👉 Read WorkOS's article on securing agentic apps against tool misuse

Context

Agentic application security breaks down when a trusted identity can chain individually valid tool calls into an outcome nobody intended. In this case, the primary keyword is tool misuse in agentic applications, and the gap is that traditional authorization answers who may call a tool, not whether the call sequence is safe.

For identity and access teams, the problem sits between NHI authorization, tool trust, and runtime governance. An AI agent can hold scoped credentials, pass every schema check, and still exfiltrate data if the policy model does not evaluate arguments, call order, and task context together.

Key questions

Q: How should security teams implement tool misuse controls for AI agents?

A: Start by separating entitlement from invocation policy. Let authorization answer whether the agent may call the tool, then add policy that inspects arguments, call sequence, task context, and risk level before execution. Begin with high-impact tools such as data writers, external email, and permission-changing actions, then expand once audit logs show what normal behaviour looks like.

Q: Why do valid tool calls still create risk in agentic applications?

A: Because agentic harm often comes from composition, not from any single call. A database query, file write, and email send may all be permitted individually, yet together they can move sensitive data outside the intended boundary. Security teams need controls that evaluate the workflow as a whole, not just the isolated permission check.

Q: What do security teams get wrong about agent authorization?

A: They often treat role checks as sufficient because every call appears schema-valid and authorised. That misses the operational question of whether the call was appropriate in context. The common failure is assuming that trusted tools and trusted identities automatically produce trusted outcomes, which is not true in multi-step agent workflows.

Q: Who should approve high-risk agent actions in production?

A: High-risk actions such as destructive writes, deployment changes, and external data transfer should require explicit human approval before the chain completes. The approval should be tied to the task, the plan, and the current session context, not just to the identity of the agent. That preserves accountability when the workflow itself becomes the risk.

Technical breakdown

Why authorization is not enough for agent tool calls

Authorization checks whether an agent may call a tool on a resource. Tool misuse appears when that binary decision is treated as the whole control. A query, file write, or email send can be individually permitted while still being harmful because the arguments are too broad, the destination is unsafe, or the call is being made for the wrong reason. In agentic systems, the security boundary must move from the permission check to the invocation context, where policy can inspect parameters, prior actions, and the task the agent is trying to complete.

Practical implication: evaluate argument validation as a first-class control, not a logging afterthought.

Dangerous tool chains emerge from legitimate steps

Tool-chain misuse is a sequence problem. A database read, followed by file creation, followed by external email may look harmless in isolation, but together it forms a data-exfiltration path. The technical challenge is not only detecting single bad calls, but modelling risky combinations across a session. That is why middleware needs stateful visibility into recent actions, not just per-call authorization. The useful boundary is the chain itself, because the harm often appears only when multiple authorised invocations are combined into one workflow.

Practical implication: classify dangerous call sequences and block or approve them before the chain completes.

Plan validation and circuit breakers for multi-step agent behaviour

Emergent misuse happens when an agent interprets a task in a way that remains technically valid but operationally unsafe. If a model decides that 'clean up' means delete, or that cost reduction means terminate production instances, static permission checks will not catch it. Plan validation adds a pre-execution checkpoint so the orchestrator can compare the intended steps with the original task. Circuit breakers add hard limits on call volume, high-risk operations, and repetition. Together they constrain the agent’s runtime behaviour without assuming the model will infer the correct business boundary on its own.

Practical implication: require pre-execution planning for destructive tasks and enforce session-level circuit breakers.

Threat narrative

Attacker objective: The attacker wants to turn authorised agent behaviour into silent data exfiltration without triggering a traditional access-control failure.

1. Entry occurs when a crafted prompt or hidden instruction is accepted inside a normal support or task workflow and the agent begins a legitimate session.
2. Credential access is not stolen here, but valid tool authority is abused as the agent invokes database, file, and email tools within its granted role.
3. Impact occurs when the chained actions exfiltrate sensitive records through a fully authorised sequence that no single control flagged as malicious.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tool misuse in agentic systems is a governance failure, not an authorization failure. The vendor’s article is correct that role checks can all pass while the resulting workflow is unsafe. That means the control model has to move from entitlement to invocation policy, where argument shape, call order, and task context are inspected together. Practitioners should treat this as a new runtime governance layer, not a refinement of RBAC alone.

Invocation policy is the right named concept for this gap. It describes the control layer that evaluates what the agent is doing with a permitted tool, not just whether it may touch the tool. The article’s sequence, argument, and context examples show why this matters for NHI governance, because the same identity can be legitimate and still unsafe in motion. Practitioners need to design policy around behaviour, not just access.

Least capability is not enough when the harmful outcome comes from combination effects. A database query, a file write, and an email send are ordinary capabilities until they are chained into an exfiltration path. That is exactly where traditional identity assumptions break down: the risk is not over-privilege in isolation, but privilege composition across a session. Practitioners should assume the dangerous unit is the workflow, not the tool.

Agentic control design now has to look more like session governance than static entitlement management. The article shows why audit mode, plan review, and circuit breakers matter together: one catches patterns, one constrains intent, and one limits blast radius. That aligns with OWASP agentic application guidance and zero-trust thinking for runtime decisions. Practitioners should expect identity controls to extend into orchestration logic.

Cross-domain identity governance is now unavoidable. Human users, service accounts, and AI agents can all trigger the same outcome when policy only checks access and not behaviour. The practical consequence is that IAM, PAM, and NHI teams need a shared vocabulary for runtime misuse, because the failure mode is no longer confined to one actor type. Practitioners should build governance that follows the action, not the label.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• That same report finds 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• For a deeper framework view, see OWASP Agentic AI Top 10 for the control patterns that map directly to tool misuse and chain-risk.

What this signals

Invocation policy is becoming the practical boundary between safe agent use and silent data movement. As agent portfolios expand, the security programme has to monitor not just what identities can access, but how those identities behave under pressure, prompt injection, and multi-step tasks. The organisations that keep this in audit-only mode for too long will accumulate behaviour they cannot reliably classify.

With 98% of companies planning to deploy even more AI agents within the next 12 months, according to AI Agents: The New Attack Surface report, the governance problem is scaling faster than policy maturity. That means policy design, exception handling, and approval workflows need to be operationalised before the next wave of agent adoption lands.

Least capability becomes a runtime discipline, not a provisioning rule. The next stage of NHI governance is less about assigning narrower roles and more about preventing harmful compositions inside a session. For readers, that means building review paths for plan validation, not just access reviews for entitlements.

For practitioners

• Implement argument validation at the tool boundary Validate every high-risk parameter before a request reaches the MCP server. Use default-deny for unknown tools, restrict write paths, and reject broad queries, unsafe URLs, and external destinations that exceed the approved task scope.
• Map dangerous tool chains and enforce session controls Track sequences such as database read, file write, and external send within a session. Flag combinations that match exfiltration, require approval for ambiguous chains, and set hard limits on call counts and risky operations.
• Add plan review for multi-step agent tasks Require the agent to declare its intended steps before execution when the task can lead to destructive or high-impact actions. Compare the plan to the approved objective and block plans that introduce unapproved tools or outcomes.
• Run invocation policy in audit mode before enforcement Log denied and permitted calls with full context, then review the patterns weekly before turning on blocking for high-risk tools. Start with data writes, external communications, and permission changes where the blast radius is easiest to define.

Key takeaways

• Agentic tool misuse happens when individually valid actions combine into an unsafe workflow, so entitlement checks alone are not enough.
• Industry evidence shows the problem is already real at scale, with AI agents exceeding intended scope in most organisations surveyed.
• The control response is runtime invocation policy, backed by argument validation, chain analysis, and approval gates for high-risk actions.

Key terms

• Invocation policy: Invocation policy is the control layer that evaluates how a permitted identity uses a tool. It checks arguments, sequencing, task context, and risk before execution, so security teams can stop harmful behaviour even when authentication and authorization are correct.
• 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.
• 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.
• Circuit breaker: A circuit breaker is a hard stop that halts execution when an agent exceeds limits on call rate, call count, or high-risk actions. It is a containment control for runtime behaviour, especially when the model’s intent or plan can drift during a session.

Deepen your knowledge

Tool misuse in agentic applications is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building runtime governance for AI agents or other non-human identities, it is worth exploring.

This post draws on content published by WorkOS: Securing agentic apps, how to stop your AI agents from misusing their own tools. Read the original.