Economy of Mechanism

Economy of mechanism is an architectural discipline, not a placed control: keep the design as simple and small as possible, because every component you add is another failure mode to audit, another interaction you may not have predicted, and another surface an attacker can probe. Saltzer and Schroeder applied it to the trusted computing base: the smaller the TCB, the more credible the claim that it is correct. The principle translates directly to agents, with the added complication that agentic stacks have a near-irresistible tendency to grow.

Attack Surface Minimization is the tool-level expression of the same concern: fewer tools mean a smaller mechanism, not just a smaller surface.

That growth has a particular shape. An orchestrator is added to coordinate the first two agents. A RAG retrieval layer is added because the model’s knowledge is insufficient. A planning module is added to break long tasks into steps. Memory is added to maintain state across sessions. Sub-agents are added for parallelism. A second level of orchestration appears because the first is overloaded. Each addition is individually justified. The cumulative result is a five-layer, twenty-component pipeline with emergent behaviour that no single component author can predict, where accountability for any given action is genuinely unclear. Economy of mechanism is the discipline that asks whether each addition is necessary before it is made, not after.

The agentic case is harder than the TCB case because complexity hides in the interaction, not the component. Each sub-agent may be simple and well-understood; the chain they form may not be. A three-agent delegation chain where each agent is authorised only for its declared task can still produce a combined capability that no one explicitly authorised, the agent-chaining equivalent of confused-deputy. This is why flat, auditable pipelines are preferable to deep delegation hierarchies for security-sensitive work, even when the deep hierarchy looks cleaner from a software-engineering perspective. The software-engineering concern and the security concern genuinely pull in opposite directions here.

Every tool in an agent’s namespace is also part of the mechanism, not merely a capability bolt-on. An agent with fifty tools has fifty injection vectors, fifty schemas to validate, fifty distinct code paths that could be chained by an adversary. Five tools needed for the task is a radically smaller mechanism than fifty tools for potential future use.

Scenario: the emergent chain

A security-review team audits a five-layer delegation chain. The outermost orchestrator handles user requests and delegates to a task-planning agent. The planner delegates to a tool-selection agent. The tool-selection agent delegates to a data-retrieval agent. The retrieval agent delegates to a database-query agent. No single developer is responsible for the whole chain; each layer’s author understood their component in isolation. During the audit, the team discovers that the tool-selection layer’s prompt, which no individual owns, can be manipulated to redirect retrieval queries to an unintended data source. Because the chain is five layers deep with no central chokepoint, fixing it requires coordinated changes across four teams. A two-agent pipeline (orchestrator + executor) would have been auditable in an afternoon.

Scenario: the over-tooled agent

A general-purpose assistant is provisioned with a curated tool set for the specific use-case it was built for (calendar management) plus thirty additional tools “for later.” A prompt injection in a calendar invite chains together the file-read tool, the code-execution tool, and the email-send tool to exfiltrate a sensitive document. None of those three tools were needed for calendar management. The attack required exactly three tools that should not have been in the mechanism at all. A tool-necessity review before deployment would have removed them; the injection would then have had nothing useful to chain.

How it fails

• Agents are provisioned with large tool sets “for flexibility,” turning every unused tool into a dormant injection chain.
• Deep sub-agent delegation hierarchies make the full capability set non-obvious; no one author can say what the combined chain can do.
• Emergent multi-agent behaviour is invisible at the component level; incidents are impossible to attribute or reproduce cleanly.
• Complexity accumulates incrementally; no single addition seems risky, but the aggregate is auditable only in theory.

Why the mapped controls work

Curated tool registries instantiate economy of mechanism at the capability level: each tool requires an explicit justification tied to a declared task, and tools without a current justification are removed. This makes the mechanism’s scope auditable and keeps the injection surface proportional to what the agent actually does. A maximum delegation-hop count enforced at the orchestrator is the architectural limit on chain depth. It prevents the five-layer accumulation by making the complexity limit explicit and machine-enforceable, not a design guideline that grows stale. Consequence graphs before deployment enumerate the combined capability of the full pipeline, the interactions between components, rather than auditing each component in isolation, which is where economy-of-mechanism violations hide.

First steps

1. Set a hard maximum delegation-hop count in your orchestration layer (two or three is a sensible ceiling for most production pipelines) and configure it to reject or pause any delegation chain that would exceed it, logging the attempt for review.
2. Build a consequence graph for your current pipeline before the next release: for each pair of agents that can communicate, write down the combined actions they could execute together that neither could take alone, and flag any combination that was never explicitly reviewed.
3. Require a written justification tied to a specific task for every tool in your agent’s registry, and schedule a quarterly review where tools whose task has lapsed or changed are removed; treat removal as the default and re-addition as the exception that requires justification.