The difference between one agent and fifty agents in production is not linear. The permission model that seemed reasonable for a single document-processing workflow becomes a liability when you stamp the same template across a fleet. This is the pattern we see most often when enterprises come to us six to nine months into a multi-agent deployment: the initial design was sensible, but the boundary logic was never designed to survive replication at scale.
What follows is not a story about reckless engineering. The teams building these systems are careful. The problem is structural, rooted in how permission templates propagate, how orchestration frameworks handle credential inheritance, and how governance reviews fail to keep pace with deployment velocity.
How It Starts: The Reasonable Template
A financial operations team builds an agent to assist with accounts payable reconciliation. The agent needs to read invoice records, match them against GL entries, and flag discrepancies for human review. The engineer provisions it with read access to the AR/AP ledger, access to the document management system, and credentials to the internal data warehouse. Reasonable for the task.
That template gets cloned. Six weeks later, there are five agents using derivatives of it: expense audit, vendor onboarding verification, budget variance analysis, intercompany settlement review, and a newer cash flow forecasting workflow. None of the cloned agents had their permissions narrowed to match the specific task. The expense audit agent has no business touching intercompany settlement data, but it can. The budget variance agent has no reason to read vendor banking details, but the credential scope includes them.
No single person made a bad decision here. The template was copied because it worked, and narrowing permissions for each variant was scheduled for later. Later has not arrived in many deployments we have spoken with.
The Orchestration Layer Makes It Worse
When agents begin calling other agents, which is the natural evolution of multi-agent systems built on frameworks like LangChain, CrewAI, or AutoGen, permission scope propagates in ways that most teams do not track explicitly.
A coordinator agent is provisioned with broad access because it needs to dispatch work to multiple sub-agents and handle their results. In the default behavior of most orchestration frameworks, sub-agents invoked by a coordinator inherit or can access the same credential context as the coordinator. A sub-agent that was scoped narrowly when running standalone can suddenly reach resources it was not designed to touch when running inside a coordinated workflow.
This is not a bug in any particular framework. It is a natural consequence of composing systems that were each designed to work independently. But from a security standpoint, it creates an escalation path that is invisible unless you are explicitly logging what credential each agent session is running under.
We instrumented a test environment with a coordinator agent that had broad data warehouse access. Each of its four sub-agents had been independently tested with narrow scopes. When the sub-agents ran under coordinator orchestration, the effective permission surface of the workflow was the coordinator's surface, not the sub-agents' individual surfaces. None of the individual agent-level logs showed this; only a session-level view made it visible.
Policy Drift Is Not Malicious, It Is Structural
Beyond the template propagation problem, permissions accumulate through incremental changes that each seem justified at the time.
A developer adds a Slack integration to the document processing agent so it can post status notifications. Now the agent can send messages to any Slack channel the credential has access to, which in a default Slack workspace setup is often all of them. Nobody registers this as an access change because it is a feature addition, not a permission change in the traditional IAM sense.
A write permission is added to an agent during a debugging session so the engineer can test end-to-end behavior without deploying a separate test credential. The debugging session ends. The write permission stays because the deployment pipeline does not distinguish between debug-phase and production-phase configurations.
A new tool is added to the agent's manifest to support a one-time data migration task. The migration runs successfully. The tool entry remains in the manifest because removing it requires a deployment cycle and it is not causing any problems.
Each of these changes is small. The cumulative effect is that the agent's actual permission surface diverges steadily from what anyone consciously designed it to have.
The Accountability Gap
Permission boundary failures only become visible when something unexpected happens: a data access pattern that should not exist, an API call to a system the agent was not supposed to reach, a volume of records touched that is inconsistent with the stated task. At that point, you need to trace back.
Standard cloud access logs (AWS CloudTrail, GCP audit logs, Azure Monitor) capture API calls with credentials and timestamps. What they do not capture is the agent context: which session, which workflow, which upstream user request triggered the call. You know a credential read an S3 object at a specific time. You do not know that the read happened inside session 4729 of agent type "doc-processor-v2", triggered by a user who submitted a contract for review 90 seconds earlier.
Without that chain, incident response involves correlating timestamps across four or five different log sources, manually. In practice, this takes hours to days, and the result is rarely definitive. The CISO asks "which agent did this and why did it have access to that data?" and the answer is a qualified guess.
What a Per-Agent Boundary Model Actually Requires
The solution is not to lock everything down and require security reviews for every agent configuration change. That will not survive contact with the deployment velocity of a team building actively. The solution is to design the governance model around explicit decisions rather than implicit defaults.
Concretely, this means four things. First, each agent type gets a named identity, not a shared service account. If "doc-processor-v2" and "contract-reviewer-v1" are different agent types with different purposes, they should have separate credentials even if the initial permission sets look similar. Separation is the precondition for later narrowing.
Second, policy is defined at the agent type level, as a configuration artifact that travels with the agent definition. When the definition is cloned, the policy is cloned but flagged for review before production deployment. The review is lightweight: does this variant's task justify the inherited permissions, or should some be removed?
Third, tool registry additions go through the same lightweight review. Adding a tool to an agent manifest is an access change. It should be treated as one, not as a feature addition that bypasses access management processes.
Fourth, every agent session carries a session ID that links to the agent type, version, and upstream request that triggered it. This is what closes the accountability gap: when you need to trace an access event, the chain from API call back to user request is in the log.
What We Are Not Saying
We are not saying broad permissions are inherently wrong for every agent. A coordinator agent in a complex workflow may legitimately need wide visibility to route work effectively. An orchestration agent that manages other agents needs to know what each of them can do. The question is not whether the permissions are broad but whether that breadth was a deliberate, documented decision.
We are also not saying the right answer is to add security checkpoints that slow deployment to a crawl. The enterprises that are handling agent governance well have lightweight, automated permission review as part of the agent deployment pipeline, not a separate manual process that sits upstream. The overhead is minimal; the traceability it creates is significant.
The Practical Starting Point
If your current fleet has permission boundaries that grew without explicit design, the place to start is not a comprehensive audit of every agent's permission set. That is time-consuming and the results age quickly. The starting point is adding session identity to your agent logging so that every access event is traceable back to a specific agent session and the request that triggered it.
With that in place, you can answer the CISO question. With the answer, you can identify which permission expansions are causing the most exposure. With that prioritized list, you can narrow systematically rather than broadly.
The permissions that accumulated over six months will not shrink in an afternoon. But the traceability that lets you make informed decisions about where to narrow, and confirm that the narrowing worked, can be in place within a week.
Audit your AI agents with Arrakis.
Arrakis gives security and platform teams a complete audit trail of every action your AI agents take, with policy enforcement that stops overreach before it reaches your data.
Request a Demo