A tool can look small from the agent’s side and be large from the identity side.
The interface says lookup_order. The agent sees a narrow verb: retrieve the order, summarize the status, maybe explain why a shipment is late. Underneath that verb, a service account authenticates to the CRM. It can read orders, update customer records, issue refunds, change shipping addresses, and export account history because those scopes made the first integration easy to ship.
Nothing in the prompt has to invent a new capability. The capability is already there. The agent only has to find the part of the tool path where a narrow task meets a broad identity.
The first article in this series looked at stale identities: authority that remains after its original purpose disappears. This one looks at a neighboring failure. The identity may still be needed, but it can do too much.
This is where least privilege meets least agency. Least privilege asks whether the non-human identity has only the permissions it needs. Least agency asks whether the agent can only express the actions it should be allowed to choose. Either side can fail alone. In practice, they often fail together.
The OWASP Non-Human Identities Top 10 for 2025 names this identity-side failure as NHI5:2025 Overprivileged NHI. The OWASP Top 10 for Agentic Applications 2026 gives the agent-side vocabulary: ASI02 Tool Misuse and Exploitation and ASI03 Identity and Privilege Abuse. The overlap is direct. Overprivileged identities make tool misuse matter because the unsafe action may actually succeed.
A Review Model
The following CRM example is not presented as a specific incident. It is a review model: a way to inspect the gap between what an agent is meant to do and what its backing identity can do.
Imagine a support agent attached to a CRM. Its product purpose is modest: help support staff answer questions about orders. Its tool list is modest too:
| Agent | Tool exposed to the agent | Backing NHI | Intended action | Inherited action | Remediation |
|---|---|---|---|---|---|
| Support assistant | lookup_order | crm-support-service | Read order status and shipment events | Export full customer history | Split read-only order status into a narrower service identity |
| Support assistant | summarize_customer | crm-support-service | Summarize recent support context | Read payment notes and internal risk flags | Create a redacted customer-summary endpoint |
| Support assistant | update_ticket | crm-support-service | Add a support note | Change ticket owner and priority queues | Use a ticket-only NHI with field-level limits |
| Support assistant | refund_status | crm-support-service | Check whether a refund exists | Issue or cancel refunds | Separate refund read and refund write identities |
| Support assistant | send_customer_message | crm-support-service | Send approved message templates | Send arbitrary account email | Require template IDs and per-action approval |
From the agent layer, this looks like five ordinary tools. From the identity layer, it is one broad credential with many more actions than the agent needs. The tool names are smaller than the authority behind them.
That mismatch is the incident waiting inside the design.
How Misuse Becomes Permission
Prompt injection is one way to trigger the problem, but it is not the only one. A bad plan, ambiguous tool description, poisoned retrieval snippet, malformed tool result, or mistaken human instruction can all push the agent toward an unsafe call. The decisive question is what happens next.
If the tool is backed by a narrow identity, the unsafe path ends quickly. The call fails because the credential cannot do the thing. If the tool is backed by an over-scoped identity, the unsafe path may succeed and leave behind a confusing audit trail: the agent called an approved tool, the tool used a valid credential, and the downstream system accepted the action.
The visible failure looks like agent behavior. The deeper failure is that authorization was placed too far below the action being reviewed.
This is why “read-only” is often a promise made at the wrong layer. A tool can be described as read-only while its backing identity can write. A function can appear harmless while it reaches an API whose methods include mutation. A retrieval connector can be presented as context access while its token can enumerate documents beyond the current task. The agent does not need to break the boundary if the boundary was never enforced where the call becomes real.
Least Agency
Least agency is the agent-facing counterpart to least privilege.
It means the agent should not receive a broad tool and then be trusted to use only the safe parts. It should receive actions shaped around the work it is meant to perform. The tool boundary should be closer to the business action: read order status, add ticket note, list approved templates, check refund state. Not “CRM access.” Not “customer operations.” Not a general client with hidden write paths.
This distinction matters because agents do not merely hold permissions. They choose among possible next steps. If the next-step menu is broad, the agent can be steered into actions that no reviewer imagined when the integration was approved. If the backing identity is broad too, the system has two amplifiers: a flexible planner above and excessive authority below.
Least privilege removes unnecessary permission. Least agency removes unnecessary choice.
What to Measure
For NHI5 in an agentic system, the useful review is not “does this service account work?” It is “what can this agent cause through this identity?”
Start with the join between agent, tool, and NHI. For every exposed tool, record the backing identity, the API methods it can reach, the resources it can touch, and the actions the product actually needs. The gap between intended action and inherited action is the inherited risk.
Then test the gap. If a support assistant is supposed to read refund status, attempt a refund creation call through the same identity. If a retrieval tool is supposed to access one collection, attempt access to neighboring collections. If an agent can ask another agent to perform work, test whether privilege moves through that delegation path.
The important result is not only pass or fail. The important result is whether the failure is enforced by the underlying identity or merely discouraged by prompt text, tool description, or convention.
What Has to Be True
Each agent tool should have a named purpose, a backing NHI, an allowed action set, and a denied action set. Review should happen at that join. A tool without identity lineage is not reviewable enough for production use.
High-impact actions should be split from low-impact reads. A status lookup and a refund write are different acts, even if they live in the same product area. They should not quietly share the same credential simply because the first integration did.
Tool schemas should expose constrained verbs rather than general clients. It is safer to give an agent get_order_status(order_id) than a generic CRM wrapper whose capabilities depend on hidden scopes. The schema should make dangerous actions hard to express, and the identity should make them impossible to complete without the right path.
Delegation needs the same treatment. If one agent can call another, the receiving agent should not become a privilege elevator. The caller’s task, the callee’s tool, and the backing NHI all need to appear in the trace. Otherwise the system can explain that a valid identity acted, while losing the reason it acted.
Short-lived elevation is the right pattern for exceptional authority. If an agent needs to perform a rare high-impact action, the system should mint a narrow, time-limited permission for that action rather than rely on ambient scope. The more consequential the action, the more important it is that authority is fresh, explicit, and visible.
Least privilege remains the foundation. Least agency is the adjustment agentic systems force on it. A permission that is merely excessive in a conventional integration can become operationally reachable once an agent can plan across tools. The work is not to make the agent promise restraint. The work is to remove the actions the agent should never have been able to complete.
Next in the series: leaked and long-lived secrets, and how credentials move from logs and prompts into memory, retrieval, and tool execution.