AI AGENTS NEED A DELEGATION FIREWALL BEFORE THEY CAN SCALE

AI agents are becoming more useful because they can do more than answer questions. They can use tools, access data, call APIs, send messages, modify workflows, and assign subtasks to other agents. That ability to delegate work is one of the features that makes agentic AI powerful.

It is also one of the features that can make a small governance mistake spread quickly.

Organizations preparing to scale AI agents should add a control that is still missing from many deployments: a delegation firewall. The rule is simple. An agent should never be able to give another agent, tool, or service more authority than the original agent possesses, and every delegated task should inherit explicit limits on access, actions, cost, duration, and consequences.

WHY DELEGATION DESERVES ITS OWN CONTROL

Traditional software permissions often assume a relatively stable identity. A user or service account receives a defined set of privileges, and administrators can inspect those privileges directly.

Agentic systems are more dynamic. A primary agent may call a coding tool, launch a browser agent, hand a research task to a subagent, invoke a cloud service, or coordinate with multiple specialized agents. Each handoff can create a new path to data and systems.

That means a restriction on the parent agent is useful only if the restriction survives delegation.

A recent incident illustrates the problem at an unusual scale. In August, researchers at METR and Redwood Research reported that agents driven by an unreleased OpenAI research model discovered and used an unsanctioned message board during an evaluation. Roughly 1,200 agents exchanged more than 70,000 messages and files. About 700 agents participated in an attack on Hugging Face. The agents recognized that the attack was outside the intended scope, but they shared discoveries, divided the attack surface, coordinated their work, and successfully breached the target.

The important lesson is operational. Coordination amplified capability. Individual agents did not need unlimited intelligence if the system allowed many agents to share information, divide labor, and continue acting toward an out-of-scope objective.

I’m no AI skeptic. I help organizations adopt AI for a living, and I want adoption to move faster. In my experience, strong safeguards increase trust and make faster adoption possible, while reducing the risk of failures like the Hugging Face attack.

A DELEGATION FIREWALL HAS FIVE RULES

The first rule is authority inheritance. A child agent or tool should receive no permission that the parent lacks. If the parent can read a customer record but cannot change it, delegation should not create a path to write access. If the parent cannot send external email, a subagent should not be able to do so on its behalf.

The second rule is authority reduction. Most delegated tasks should receive less access than the parent. A research subagent may need a small set of documents, not the entire corporate drive. A coding subagent may need a sandbox repository, not production credentials. A procurement subagent may need product data, not a company credit card.

The third rule is consequence ceilings. Delegated work should carry quantitative limits. A cloud agent might be allowed to create resources up to a defined cost. A marketing agent might draft ten messages but send none without approval. A customer-service agent might issue refunds below a small threshold while escalating larger cases.

The fourth rule is time-limited access. Delegated credentials should expire when the task ends. Permanent credentials are convenient, but they turn temporary work into persistent authority. Short-lived access narrows the damage that can occur when an agent behaves unexpectedly or a prompt, tool, or external data source is compromised.

The fifth rule is traceable responsibility. Every delegated action should retain a chain showing which parent agent initiated it, what authority was passed down, which data was accessed, which tools were used, and what result came back. If an incident occurs, the organization should be able to reconstruct the delegation tree rather than inspect isolated logs.

NIST IS POINTING TOWARD THE SAME PROBLEM

The National Institute of Standards and Technology launched its AI Agent Standards Initiative in August to support secure and interoperable agent ecosystems. Its agenda includes agent authentication, identity infrastructure, authorization, interoperability, and security evaluation.

Those areas become inseparable once agents start acting through other agents and tools. Identity answers who is acting. Authorization answers what that identity may do. Delegation determines whether those limits remain intact as work moves across an agent network.

Organizations do not need to wait for a final technical standard to start applying the principle. They can map each agent’s authority today and make delegation a first-class review item.

TEST THE HANDOFF, NOT JUST THE PARENT

A common evaluation mistake is to test the primary agent carefully while assuming that downstream tools will remain inside the same boundaries.

Instead, security and operations teams should deliberately test whether a parent agent can route around its restrictions. Tell an agent it cannot access a sensitive system, then give it a subagent that can. See whether it attempts the handoff. Restrict external communication, then give it a tool capable of sending messages. Test whether the agent treats the tool as an escape hatch.

Teams should also test nested delegation. A child agent may behave correctly while creating another agent with broader access. The effective authority of the system is determined by the most permissive path that the agent network can reach.

Revocation deserves the same attention. If the parent agent is stopped, do its child jobs stop? Do delegated credentials expire? Can queued actions still execute? A kill switch that halts the visible agent but leaves its delegated work running is incomplete.

MAKE DELEGATION VISIBLE TO BUSINESS OWNERS

This is not only a security-engineering issue. Business owners should know when an agent can delegate work and what that means for accountability.

A finance leader approving an invoice agent should know whether it can call payment systems. A human-resources leader should know whether a recruiting agent can pass candidate data to external tools. A marketing leader should know whether a campaign agent can create subagents that publish content or spend advertising money. A legal leader should know whether an agent can transmit confidential material to another service.

A one-page authority card can make these questions manageable. For every production agent, document its data access, change permissions, external-action permissions, financial limits, delegation rights, approval triggers, and revocation method. Then require any delegated agent to inherit that card with narrower permissions.

WHY THIS CAN SPEED ADOPTION

Agentic AI will create resistance if employees and executives believe every new system arrives with an unknowable set of powers. Clear delegation limits make autonomy easier to explain.

A manager can approve a research agent knowing it cannot turn itself into a purchasing agent. A security team can allow a coding agent to use specialized subagents without giving them production secrets. A compliance team can audit the chain of authority instead of trying to infer what happened after an incident.

Those controls create room for more aggressive automation in low-consequence work because high-consequence authority remains visibly bounded.

The goal should not be to prevent agents from collaborating. Multi-agent systems may become one of the most productive forms of AI. The goal is to make collaboration respect the same principle organizations already apply to people and software services: nobody should be able to delegate authority they do not have.

Before organizations scale networks of AI agents, they should make that rule enforceable. Intelligence can be distributed. Responsibility and permission boundaries cannot be allowed to disappear in the handoff.