Designing Permission Schemas for Multi-Agent Pipelines
Take a three-agent pipeline: one agent reads source data, another enriches it, and a third writes the result. For one agent, permission design is relatively direct: list required resources and operations, then enforce them at authorization. Handoffs make the model harder.
The issue is not simply the agent count. Every handoff can become an escalation path. Agent A reads from a source and sends context to Agent B, which processes it and invokes Agent C to write results. Their individual permissions are separate, yet the pipeline's effective permissions combine all three. When Agent B can turn Agent A's data-derived instructions into a call to Agent C, Agent A's effective reach spans the full chain.
Two schema models and flat-schema limits
Most teams begin with a flat schema: a rule set listing each agent's allowed resources and operations. That model is adequate for independent agents. In a pipeline, however, it omits the relationships between agents.
Take a three-agent enrichment pipeline. Agent 1 (intake) reads raw records from an ingest queue and sends them to Agent 2 (enrich). Agent 2 calls a third-party API, then passes results to Agent 3 (write). Agent 3 stores enriched records in the production database. The flat grants look reasonable: Agent 1 gets queue:read, Agent 2 gets api:call:enrichment-service, and Agent 3 gets db:write:enriched-records.
The weakness surfaces if Agent 2 is compromised or behaves incorrectly. If it can send Agent 3 arbitrary instructions rather than enrichment data alone, Agent 3 may be turned into a writer of arbitrary production-database content. Its schema permits table writes, but does not constrain the content or identify who may direct them.
Scoped delegation: a schema pattern for handoffs
Model handoffs as delegation events, with their limits recorded in the schema. When Agent A delegates to Agent B, B's operating scope is the intersection of A's scope and B's declared scope. B cannot receive instructions that add capabilities A did not possess.
This is constrained delegation, a pattern that corresponds directly to permission-token behavior in modern authorization systems. On calling Agent B, Agent A passes a derived token containing A's permissions narrowed to the handoff's required scope. B uses that token for downstream calls, while authorization enforces a strict subset of A's original permissions.
Operationally, three pieces are required: Agent A's credential must support derivation through narrower sub-credentials, downstream authorization must validate the derivation chain, and the schema must state precisely what each agent may delegate.
Hierarchical schema design
For multi-agent pipelines, a hierarchy is often easier to reason about than per-agent flat rules. It follows the pipeline: the orchestrator sits at the top with the broadest scope, though still narrower than necessary, while each worker receives only the slice required for its function.
For the three-agent case, the hierarchy could work this way. The orchestrator may delegate intake, enrich, and write tasks. The intake agent has queue:read:raw-records plus delegation:intake-to-enrich. The enrich agent has api:call:enrichment-service and delegation:enrich-to-write, but may grant the write agent no more than db:write:enriched-records:validated-only. The write agent has db:write:enriched-records:validated-only without delegation.
The :validated-only qualifier must be enforced by authorization, not treated as naming convention. A write to the enriched-records table is allowed only after the record passes enrichment validation, represented by a required record attribute. Attribute-based access control helps here: scope covers not only the table, but also the data state required before writing.
Schema versioning and pipeline evolution
Pipelines change over time: agents are added, data paths shift, and downstream services appear. Each structural adjustment may alter the schema, so those changes require deliberate management.
A frequent mistake is widening one agent's scope without tracing the effect across the pipeline. Suppose Agent B gains access to a new enrichment service and can delegate to Agent C. Does C now receive that service's outputs? If so, was that intended? If not, the schema must explicitly restrict what B may pass from the new service.
Handle schema edits like code: keep versions, review changes, and control releases. Schema drift, where deployed permissions diverge from the design, is harder to find in a pipeline than in a single-agent system because interaction effects remain hidden when each schema is inspected alone.
Where this approach does not fit
We are not saying every pipeline needs hierarchical schemas with constrained delegation, because they add complexity. For independent agents, each reading its own source and writing its own destination without handoffs, flat schemas are correct. We are saying the hierarchical model fits pipelines where agents exchange context and that context shapes downstream behavior.
Constrained delegation also depends on authorization infrastructure that can understand and enforce delegation chains. A layer built as a simple list of API-key endpoints needs a different authorization model to express these limits. The implementation cost is real, so weigh it against the pipeline's actual risk before adopting the added complexity.
Starting from where you are
If an existing multi-agent pipeline uses flat schemas, begin by mapping actual handoff points, not by replacing the schema system. Mark which handoffs carry instructions instead of data. Those are the risk points. Document them, examine what the downstream agent could be told to do, and determine whether that risk warrants more constraints. The resulting inventory prioritizes where hierarchy helps most, without requiring an immediate rewrite of everything.