Why Authority Only Shrinks: The Case for Monotonic Narrowing in Agent Delegation

There is a principle at the core of CapiscIO's architecture that we state in three words: authority only shrinks. It sounds obvious. It is surprisingly rare in deployed agent systems. And understanding why it is the correct invariant — and what it costs to maintain it — explains most of the architectural decisions we have made.

What Monotonic Narrowing Means

Monotonic narrowing is a formal property of delegation chains. In a delegation chain with monotonic narrowing, each participant can delegate to the next participant only a subset of the authority they hold. They can delegate equal authority. They cannot delegate broader authority. They cannot grant rights they do not have. The authority available at any point in the chain is always less than or equal to the authority available at the previous point.

The word monotonic is borrowed from mathematics. A monotonically decreasing function never increases. Applied to authority, it means the delegation chain never widens. What a human authorizes at the start of a workflow is the ceiling for every agent that participates in that workflow.

This is not a novel idea. Bell-LaPadula defined mandatory access control with similar properties in 1973. The object-capability security literature from the 1970s onward is built on the same invariant. The capability attenuation principle — that a capability can be delegated but only in narrowed form — is a foundational result in formal security theory. SPKI/SDSI, a 1996 Internet standard for simple public key infrastructure, included a reduction algorithm for computing effective authority through a certificate chain that formalizes exactly this property.

The insight is old. The application to multi-agent AI systems is new.

Why Most Agent Systems Violate It

Most deployed agent systems do not enforce monotonic narrowing. They cannot, because they lack the infrastructure to track authority through a delegation chain at all.

The typical architecture looks like this: an agent is provisioned with credentials — an API key, an OAuth token, a service account with IAM roles. Those credentials represent the agent's authority ceiling. When the agent delegates to another agent, it either passes its credentials directly, issues a new set of credentials scoped to what it thinks the downstream agent needs, or the downstream agent uses its own independently provisioned credentials.

None of these approaches enforce monotonic narrowing. Passing credentials directly shares the full authority ceiling with no narrowing. Issuing new credentials relies on the delegating agent correctly scoping them — there is no enforcement that the new credentials are narrower than the delegating agent's own. Using independent credentials entirely disconnects the downstream agent's authority from the delegation chain, so the originating principal's authority ceiling has no effect on what the downstream agent can do.

In all three cases, authority can expand at delegation boundaries. An agent provisioned with narrow credentials can delegate to a downstream agent with broader credentials. An agent that incorrectly scopes its delegated credentials can accidentally grant broader access than it intended. An agent using independent credentials operates entirely outside the chain.

The result is a system where the authority actually exercised in a workflow has no guaranteed relationship to the authority the human authorized at the start.

What It Takes to Actually Enforce the Invariant

Enforcing monotonic narrowing in a multi-agent system requires several things that do not come for free.

Cryptographically bound delegation artifacts. Each delegation must be a signed artifact that includes the authority being delegated and a reference to the parent authorization from which it is derived. The signature must cover both, so that neither can be altered after issuance. Without cryptographic binding, there is no way for a downstream participant to verify that the authority being exercised was legitimately derived from the chain.

Envelope derivation rules that PEPs can verify. The rules for what constitutes a valid narrowing must be formally defined and verifiable by any participant in the chain without a round trip to a central authority. If a downstream PEP can verify the derivation rules locally, the enforcement does not depend on a central coordinator being available and honest. Decentralized verifiability is what makes the system robust at scale.

A formal capability class vocabulary. Monotonic narrowing requires a partial order on authority levels. You cannot verify that B is narrower than A unless you have a formal definition of what "narrower" means for the relevant authority dimensions. This is non-trivial. For financial permissions, "narrower" might mean a smaller monetary ceiling. For data access, it might mean a more restrictive data classification tier or a smaller set of allowed operations. The vocabulary has to be defined and agreed upon before narrowing can be enforced.

Delegation depth tracking. An agent that can delegate to unlimited depth can effectively create an unlimited number of deputies, each potentially expanding the attack surface. Monotonic narrowing on authority scope does not prevent an explosion of delegation depth. Explicit depth limits, tracked in the delegation artifact and decremented at each hop, are a separate requirement.

The Edge Cases That Break Simple Implementations

Three situations create complexity in monotonic narrowing implementations that are worth naming explicitly.

Capability union. An agent might hold two separate capabilities — read access to invoices and write access to reports — and want to delegate both to a single downstream agent. The narrowing check must handle the delegation of multiple capabilities simultaneously. The correct behavior is that each capability narrows independently: the downstream agent can receive a subset of the invoice read access, a subset of the report write access, or both, but cannot receive capabilities that the parent does not hold.

Constraint narrowing. Authority is not just a capability class — it often includes constraints, such as maximum record counts, allowed resource identifiers, or time windows. Narrowing must apply to constraints as well as capability classes. A parent delegation with a maximum of one thousand records cannot produce a child delegation with no maximum. The child's constraints must be equal to or stricter than the parent's at every dimension.

Delegation pass-through. In a multi-agent workflow, an orchestrator might receive a capability and want to pass it unchanged to a specialist agent. Passing authority at 1:1 parity is legitimate and necessary for functional workflows. Monotonic narrowing permits equal delegation — it prohibits expansion, not equality. This must be explicit in the specification or implementations will incorrectly block valid pass-through delegations.

Why Cross-Organizational Deployment Makes This Harder

Monotonic narrowing is straightforward to enforce within a single organization with a central authority. The authority hierarchy is defined in one place, the delegation rules are applied by one enforcement system, and every participant trusts the central authority.

Cross-organizational deployment removes the central authority assumption. When Acme Corp's agent delegates to TaxCo's agent, there is no single authority that both organizations trust to enforce the narrowing. TaxCo's PEP cannot simply call Acme's authorization server and ask whether this delegation is valid — that would create a tight operational coupling between organizations that is neither feasible nor desirable in practice.

The solution is to make the enforcement artifact self-contained. The delegation chain must carry enough information for any downstream PEP to verify the full chain without contacting any upstream party. This means the chain must include the complete lineage of delegations, each delegation must be signed by the key of the issuing party, and the PEP must have a way to verify those keys without a round trip to a centralized authority.

DIDs — decentralized identifiers — solve part of this. A DID is an identifier whose verification method is published in a DID document at a well-known location controlled by the identity holder. A PEP can verify a signature against a DID-bound key by resolving the DID document without contacting a centralized identity provider. This makes cross-organizational chain verification possible without requiring prior trust establishment between the organizations.

The CapiscIO Implementation

In CapiscIO's RFC-008 Authority Envelope specification, monotonic narrowing is the central invariant. We call it the Golden Rule: no agent can take an action that exceeds the authority of the human or system identity that triggered the workflow.

The implementation has four specific narrowing checks applied at every derived envelope issuance.

Capability class narrowing: the child envelope's capability class must be within the scope of the parent's. A child cannot claim a broader class than the parent holds.

Temporal narrowing: the child envelope's expiry must be equal to or earlier than the parent's. A delegation cannot outlive the authority it was derived from.

Depth decrement: the child envelope's delegation depth must be strictly less than the parent's. When depth reaches zero, the holding agent cannot delegate further.

Constraint subset: the child envelope's constraints must be equal to or stricter than the parent's at every dimension. Constraints cannot be relaxed at delegation.

All four checks are enforced by the PEP at derived envelope creation time. An envelope that fails any check is rejected. An agent that attempts to issue a derived envelope broader than its parent receives an error. The failure mode is denial, not pass-through.

The PEP at the receiving end also verifies the full chain. It does not trust that the sending agent produced a valid chain. It verifies the chain itself, checking signatures and narrowing semantics end to end before authorizing any action. This means the invariant is enforced at both issuance and consumption, with no gap between them.

What This Buys You

The practical benefit of enforcing this invariant is auditability with provenance. When an action is taken in a multi-agent workflow, you can answer a question that most agent systems cannot answer: what human authority was this action ultimately derived from, and is the action within the scope of that authority?

This matters for compliance. Regulators asking about autonomous agent decisions want to know that the decisions were bounded by human authorization. A cryptographic delegation chain with monotonic narrowing is the artifact that proves it. "The agent was within its authorized scope" is a verifiable claim when the chain exists; it is an assertion that cannot be audited when the chain does not.

It also matters for incident response. When an agent does something unexpected, the first question is whether it was authorized to. With a delegation chain, you can answer that question deterministically. Without one, you are reconstructing authorization from logs and configuration that was never designed to answer that question.

Authority that only shrinks is not a limitation on what agent systems can do. It is the property that makes them auditable, governable, and safe to deploy in contexts where the consequences of unauthorized actions are real.