Our agents hold production credentials. How do we scope them down without breaking them?

To give AI agents access to internal tools without over-permissioning them, make the unit of access the task rather than the system. Each agent gets a narrow credential scoped to the smallest resource that will do the job, expiring when the job ends, with irreversible actions gated separately from reads. Teams end up over-permissioned because the easy path is one broad grant per tool, and nothing in the default setup ever narrows it afterward.

Why most AI agents end up over-permissioned

The grant is issued once, at connection time, for the widest set of things the agent might ever need. Nobody comes back later to trim it, because trimming has an immediate cost (something breaks) and a deferred benefit (a smaller blast radius on a day that may never come). Obsidian Security’s 2025 analysis found 90 percent of deployed agents over-permissioned relative to their assigned task scope, and Entro Security put 97 percent of non-human identities at excessive privilege in the same period.

The governance numbers are worse than the intent. A January 2026 Cloud Security Alliance survey of 383 security professionals found 92 percent were not confident their identity tooling could manage AI and non-human identity risk, and 78 percent had no documented policy for creating or removing an agent identity. A February 2026 follow-up covering 285 professionals found 79 percent had no real-time inventory of active agents. You cannot scope what you have not enumerated.

This is structurally worse for agents than for the service accounts that came before them. A traditional integration does one thing, so its scope is legible. An agent’s job is defined at runtime, so whoever grants access cannot predict the scope and reasonably grants the maximum. The Model Context Protocol ecosystem is working through the same failure: a server advertises a tool surface, the agent connects with one credential, and that credential covers the whole surface rather than the tool in use. OWASP’s Top 10 for Agentic Applications, published in December 2025, files this as ASI03 Identity and Privilege Abuse and pairs it with ASI02 Tool Misuse. The longer version of the argument is in why agents end up with all-or-nothing access.

What happens when an agent drifts from the policy you set

Nothing visible, which is exactly the problem. Drift shows up as a widening gap between the access you approved and the access in effect, and neither side emits an alert. The common paths: a tool server adding capabilities after the agent already trusts it, a credential outliving the workflow it was minted for, and tool descriptions changing between the version you reviewed and the version loaded at runtime. That last one has a name, tool poisoning, and it works because the description is part of the prompt rather than metadata outside it.

Two 2026 advisories show the shape. CVE-2026-33032, patched in March 2026, was a missing authentication check on an nginx-ui management endpoint, CVSS 9.8, across more than 2,600 exposed instances. CVE-2026-44895, published in May 2026, scored 9.2 for missing authentication middleware plus a wildcard CORS policy in a third-party GitLab tool server, letting any cross-origin browser context drive reads and writes under the operator’s identity. In both, the policy on paper was intact and the perimeter in effect was not, which is the recurring theme in why so many tool-server CVEs share one root cause.

Detection is the practical answer, because prevention here is incomplete by construction. Log what the agent reached rather than what it was permitted to reach, diff the tool surface against the version you approved at install, and give credentials an expiry so drift has a bounded lifetime. The Cloud Security Alliance survey found 84 percent doubted they could pass an audit focused on agent access, which is a fair read of a stack whose only record is the grant itself.

Your options

Per-tool scoped service accounts are the cheapest real improvement on the broad grant you almost certainly have now. Give each agent its own identity in each tool, narrow the scopes by hand, and drop write access wherever the work does not require it. That is a weekend of work for a small stack and removes most of the disclosure surface. It degrades quietly: scopes get set once, the job changes, nobody revisits, and static keys have no expiry, so a leaked one stays live until someone notices.

Short-lived task-scoped credentials are what OWASP recommends, and the strongest option when they fit. A token minted for one task against one resource, expiring when the task ends, bounds both the leak window and the misuse window. The catch is fit: conversational and long-running agents have no clean task boundary to hang expiry on, and running an issuance service is an operational commitment rather than a config change.

A gateway in front of every tool call moves credentials out of the agent entirely. The proxy holds the secrets, applies policy per call, filters responses, and produces one audit log across everything. This is right once you have enough agents and tools that hand-maintained scopes drift faster than anyone reviews them. It is also a new bottleneck and a place where policy has to encode the semantics of every downstream tool, which is more work than it sounds.

Human approval on write actions is the one most teams reach for first and the one that decays most predictably. It works when action volume is low and consequences are high. As volume rises, reviewers stop evaluating and start clicking, and the gate keeps producing approval records for decisions nobody made. Reserve it for actions that are genuinely irreversible rather than every write.

A scoped container in place of source access changes what the agent has credentials for. Rather than credentials to the CRM, the wiki, and the ticket tracker, the agent gets one permissioned container holding the context it needs, with its own endpoint and grants. The honest limit matters: this scopes what the agent reads and writes inside the container and does nothing about its access to your other systems. If your coding agent holds a production database credential today, it still holds it tomorrow. It removes a reason to grant broad access; it does not revoke access already granted.

How to decide

What can this agent do that you cannot undo? Make that list first. It is usually much shorter than the full permission set, and it is the only part that justifies approval gates or a gateway. Everything else is a scoping problem, not an oversight problem.

How often does the set of things it needs change? Stable scope favors per-tool service accounts: a static grant reviewed twice a year is fine. Weekly-changing scope favors short-lived credentials or a gateway, because hand-maintained scopes drift faster than any review cadence.

Can you answer what the agent touched last Tuesday, without shipping code? If not, start there rather than with policy. Enforcement you cannot observe is indistinguishable from no enforcement, and the observation work usually surfaces two or three grants you can delete immediately.

What to do next

Start with an inventory: every agent, every credential it holds, and the last time each was exercised. Unused grants are free to remove, and on most stacks that alone takes a meaningful share off the write surface. Do it before evaluating a gateway: the inventory tells you whether you have a tooling problem or an untended one.

Then decide whether each agent needs the source system or only what is in it. Where it needs only the knowledge, narrowing the surface it reasons over is both a permission decision and a retrieval one, which is the argument in token scope as a retrieval boundary, and it pairs with keeping each tool narrow enough to reason about, covered in one job per tool.

Wire is our version of the scoped container: a permissioned place an agent reads and writes under its own grants, so the credential it carries covers the context rather than every system the context came from, which is the shape described on agent products. It fits the agents whose job is to reason over knowledge, and it sits alongside the scoping work rather than replacing it, because the agents that genuinely operate your source systems still need short-lived credentials and a record of what they reached.

Sources: OWASP Top 10 for Agentic Applications 2026 · CSA research note on the AI agent IAM gap · CSA non-human identity governance whitepaper · CVE-2026-44895 · CSA MCP security crisis research note