Because the same runtime behavior that consumes more tokens also expands authority across tools and downstream actions. When identity, intent, and execution are not bound together, teams lose visibility into who acted, what they were allowed to do, and how much the chain cost. That is a governance failure, not just a budgeting issue.
Why This Matters for Security Teams
Agentic systems turn a single request into a chain of model calls, tool invocations, data retrieval, and external actions. That means the same design choice that drives up token usage also broadens the blast radius of a mistake. Security teams are not just paying for inference; they are underwriting runtime authority. When an agent can browse, query, write, approve, or execute, cost and compromise move together.
This is why guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework matters here: neither treats spend as a separate concern from governance. In practice, over-permissioned agents are expensive because they can do too much, and insecure agents are expensive because every extra action creates another place for abuse, error, or hidden failure. NHIMG has documented the same pattern across agent-facing incidents, including the CoPhish OAuth Token Theft via Copilot Studio and the Replit AI Tool Database Deletion cases. In practice, many security teams notice the financial drain only after an agent has already made an unsafe chain of tool calls.
How It Works in Practice
The operational problem is that agent cost is not linear. A single user prompt can trigger retries, retrieval, code execution, API calls, and downstream automations. Each step adds token consumption and expands the opportunity for the agent to reach sensitive systems. That is why current guidance suggests binding identity, intent, and execution together at runtime instead of treating the agent as a static user with a fixed role.
Practitioners usually reduce this risk by combining workload identity, short-lived credentials, and policy evaluation on every action. The goal is to issue permission only for the exact task, then revoke it when the task ends. That reduces the chance that a compromised or misdirected agent can keep spending money or moving laterally after the original request is complete.
- Use workload identity as the primitive, not a shared service account or long-lived API key.
- Issue just-in-time credentials with narrow TTLs tied to one task or session.
- Evaluate authorization at request time with policy-as-code, not only at provisioning time.
- Log the full chain of model call, tool use, and external action so cost and control can be correlated.
This approach is reinforced by the CSA MAESTRO agentic AI threat modeling framework and the Analysis of Claude Code Security, both of which reflect the same operational reality: the agent’s permissions should shrink to the smallest possible action surface. These controls tend to break down when agents are allowed to chain tools across teams or environments, because shared permissions and opaque routing make it hard to see which step caused the extra spend.
Common Variations and Edge Cases
Tighter agent control often increases orchestration overhead, requiring organisations to balance lower risk against slower execution and more policy maintenance. That tradeoff becomes sharper in systems that run many short tasks, because aggressive revocation and fine-grained policy checks can create friction if the workflow was built for speed rather than control.
There is no universal standard for this yet, but best practice is evolving toward context-aware authorization for high-impact actions and looser controls for low-impact retrieval tasks. Some teams separate “read” agents from “act” agents so the cheapest possible model handles lookup work while a more restricted path handles writes, approvals, or external API calls. Others cap spend per task, per session, or per workflow branch so cost overruns become visible before they become incidents.
Where this breaks down most often is in multi-agent pipelines that share state, credentials, or memory. In those environments, one agent’s bad decision can amplify another agent’s cost and authority, especially if tool access is inherited rather than re-evaluated. That is why NHIMG’s coverage of the OWASP Agentic Applications Top 10 and the Moltbook AI agent keys breach is especially relevant: shared secrets and unbounded tool use turn a budgeting problem into a security incident very quickly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 | Agentic tool chaining and overreach create both cost and security exposure. |
| CSA MAESTRO | TRM | Threat modeling should include spend amplification and unsafe autonomous actions. |
| NIST AI RMF | GOV | Governance is needed because runtime agent behavior affects both risk and spend. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Shared or long-lived secrets let agents spend and act beyond intended scope. |
| NIST Zero Trust (SP 800-207) | SC-4 | Zero trust supports per-request authorization for autonomous agent actions. |
Constrain tool use per action and re-check permissions at each agent step.
Related resources from NHI Mgmt Group
- When does just-in-time access reduce risk for agentic AI, and when does it fall short?
- How should security teams limit the risk from AI agents that have access to production systems?
- Why do agentic AI systems create more security risk than standard chatbots?
- Why do AI-enabled marketing systems increase privacy and security risk at the same time?
