Transitive Constraint Preservation Governance requires that every constraint, limit, or restriction imposed on a delegating agent is faithfully propagated to all downstream agents in a delegation chain — and that no downstream agent can operate with permissions exceeding those of its delegator. When Agent A delegates to Agent B, and Agent B delegates to Agent C, Agent C must operate within the intersection of all constraints from A and B, not merely the constraints B chose to forward. This dimension addresses the risk of constraint erosion across multi-agent chains, where each delegation step silently drops, weakens, or reinterprets governance boundaries, ultimately producing an agent at the chain's tail that operates with more latitude than any human principal ever authorised. Without structural enforcement of transitive constraint preservation, the delegation depth becomes a mechanism for privilege escalation.
Scenario A — Constraint Erosion Through Serial Delegation: A financial services organisation deploys an orchestrator agent (Agent A) with a mandate ceiling of GBP 50,000 per transaction, restricted to pre-approved counterparties, and limited to standard payment instruments. Agent A delegates a batch reconciliation task to Agent B, passing through the GBP 50,000 limit but omitting the counterparty restriction because Agent A's delegation protocol treats counterparty constraints as "context metadata" rather than "hard constraints." Agent B further delegates individual payment corrections to Agent C, passing through the payment instrument restriction but not the GBP 50,000 limit because Agent B's delegation schema has no field for value ceilings — it was designed for reconciliation, not payments. Agent C executes 14 payment corrections totalling GBP 230,000 to 3 counterparties not on the approved list, using a non-standard payment rail. Every individual delegation was technically valid under the delegating agent's own schema, but the original principal's constraints were entirely lost by the third hop.
What went wrong: Each agent forwarded only the constraints its delegation schema could represent. No structural mechanism verified that downstream constraints were at least as restrictive as upstream constraints. The constraint set degraded at each hop, and by the third delegation, no original constraint survived intact. Consequence: GBP 230,000 in unauthorised payments to unapproved counterparties, regulatory investigation under FCA SYSC 6.1.1R, mandatory remediation of the entire delegation architecture.
Scenario B — Constraint Reinterpretation Across Domain Boundaries: A healthcare orchestrator agent operates under HIPAA minimum-necessary constraints: it may access only the specific patient fields required for the current task. The orchestrator delegates a lab result summarisation task to a specialist analytics agent, passing the constraint as "access limited to lab results for patient #4471." The analytics agent interprets "lab results" broadly, accessing not only the specific blood panel ordered but also historical lab results, genetic screening results, and pathology reports — 847 records across 6 years of history. The original constraint intended access to 3 specific lab values from the current visit.
What went wrong: The constraint was transmitted as natural language rather than as a structured, machine-enforceable specification. The receiving agent applied its own interpretation rather than the delegator's intent. No constraint verification mechanism confirmed that the downstream agent's access scope matched the upstream specification. Consequence: HIPAA breach notification required for 844 excess record accesses, OCR investigation, estimated remediation and notification cost of USD 340,000.
Scenario C — Privilege Escalation Through Constraint Omission in Cyclic Delegation: An enterprise workflow system permits agents to sub-delegate tasks. Agent A (constrained to read-only database access) delegates an analysis task to Agent B. Agent B's delegation receipt does not include access-type constraints, so Agent B operates with its own default permissions, which include write access. Agent B delegates a data cleanup sub-task back to a new instance of Agent A's class, but this time the delegation carries Agent B's write permission rather than the original read-only constraint. The new Agent A instance modifies 12,000 production records, believing it has write authority because the delegation chain granted it.
What went wrong: The delegation chain created a privilege escalation path. The original read-only constraint was lost when Agent B — which did not receive or enforce that constraint — re-delegated with its own permission set. No mechanism verified that the constraint set at each hop was monotonically non-increasing. Consequence: 12,000 production records corrupted, 6-hour production outage, data restoration from backup required, estimated business impact of GBP 180,000.
Scope: This dimension applies to all multi-agent systems where one agent can delegate tasks, authority, or execution to another agent, and where delegation chains can extend beyond a single hop. Any system in which Agent A can delegate to Agent B, and Agent B can further delegate to Agent C (or any deeper chain), is within scope. The scope includes explicit delegation (Agent A sends a structured delegation request to Agent B) and implicit delegation (Agent A places a task on a queue that Agent B picks up and further distributes). The scope extends to constraint types including but not limited to: value ceilings, permitted action types, data access boundaries, counterparty restrictions, temporal windows, geographic restrictions, and classification levels. Single-agent systems and systems where delegation is architecturally limited to exactly one hop with no further sub-delegation are excluded. The test is whether any execution path exists in which a constraint imposed at delegation step N could fail to reach delegation step N+2 or beyond.
4.1. A conforming system MUST propagate all governance constraints from a delegating agent to every downstream agent in the delegation chain, such that no downstream agent operates with permissions exceeding those of its delegator.
4.2. A conforming system MUST represent constraints in a structured, machine-enforceable format that is preserved across delegation boundaries without lossy transformation or natural-language reinterpretation.
4.3. A conforming system MUST verify, at each delegation step, that the constraint set carried forward is at least as restrictive as the constraint set received from the upstream delegator, rejecting any delegation that would weaken constraints.
4.4. A conforming system MUST block delegation when the receiving agent's delegation schema cannot represent one or more constraints from the delegating agent, rather than silently dropping unrepresentable constraints.
4.5. A conforming system MUST maintain an immutable record of the full constraint chain for each delegation, enabling post-hoc verification that every constraint imposed at the chain origin was enforced at every downstream hop.
4.6. A conforming system SHOULD implement constraint intersection enforcement — where a downstream agent receives constraints from multiple upstream paths, the effective constraint set is the intersection (most restrictive combination) of all upstream constraint sets.
4.7. A conforming system SHOULD enforce a maximum delegation depth beyond which further sub-delegation is blocked, with the default maximum set to no more than 5 hops unless explicitly configured otherwise.
4.8. A conforming system SHOULD detect and block cyclic delegation paths where constraint escalation could occur through re-delegation loops.
4.9. A conforming system MAY implement constraint visualisation tooling that renders the full constraint propagation tree for audit and debugging purposes.
Multi-agent orchestration creates delegation chains where governance constraints must survive intact across every hop. The fundamental risk is constraint erosion: each delegation step provides an opportunity for constraints to be dropped, weakened, reinterpreted, or lost through schema incompatibility. In a single-agent system governed by AG-001, the mandate is enforced at the infrastructure layer and cannot be bypassed. In a multi-agent system, the mandate must travel with the delegation, and every intermediate agent becomes a potential point of constraint loss.
The problem is analogous to permission inheritance in distributed systems, where the principle of least privilege requires that delegated authority never exceeds the delegator's own authority. In computer security, this is enforced through structural mechanisms — capability tokens, signed permission chains, or cryptographic delegation certificates. AG-083 requires the equivalent for AI agent governance: a structural mechanism that ensures constraint monotonicity across delegation chains.
Without transitive constraint preservation, the delegation depth itself becomes an attack surface. An adversary — or a misconfigured agent — can exploit multi-hop delegation to launder constraint violations through intermediate agents. Each hop appears individually compliant, but the cumulative effect is a downstream agent operating far outside the original principal's intent. This is particularly dangerous because it is difficult to detect through monitoring of individual agents: each agent in the chain appears to be operating within its own constraints, but the chain as a whole has escalated privileges.
The constraint representation problem is equally critical. If constraints are transmitted as natural language, each receiving agent applies its own interpretation. "Access limited to relevant patient data" means one thing to the delegating agent and potentially something very different to the receiving agent. Structural constraint representation — using typed, machine-enforceable constraint objects — eliminates interpretive ambiguity and enables automated verification at each delegation step.
AG-083 builds directly on AG-001 (Operational Boundary Enforcement) by extending mandate enforcement from single-agent boundaries to multi-agent delegation chains, and on AG-009 (Delegated Authority Governance) by requiring that delegated authority carries its constraints intact through every subsequent delegation.
The core implementation requirement is a constraint propagation framework that intercepts every delegation event, verifies constraint preservation, and blocks delegations that would weaken the constraint chain. The constraint set must be represented as a structured, versioned object that travels with the delegation and is immutable by the receiving agent.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. Constraint preservation must cover value ceilings, counterparty lists, instrument restrictions, and jurisdictional boundaries. In a multi-agent trading system, a portfolio manager agent delegating to an execution agent delegating to a market-access agent must ensure that the market-access agent cannot exceed the portfolio manager's risk limits. MiFID II best execution obligations and FCA conduct rules apply at every hop in the chain.
Healthcare. HIPAA minimum-necessary constraints must be propagated structurally. A care coordination agent delegating to a specialist consultation agent must transmit the exact field-level access permissions, not a natural-language summary. The receiving agent's access must be verifiably bounded by the delegating agent's access scope.
Critical Infrastructure. Safety constraints in delegation chains are life-critical. An ICS orchestrator delegating to a process control agent must ensure that safety interlocks (temperature limits, pressure ceilings, actuator ranges) propagate without attenuation. IEC 61508 SIL requirements apply to the constraint propagation mechanism itself, not merely to the end agents.
Basic Implementation — The organisation has documented that constraints should be forwarded in delegation chains and has implemented constraint fields in delegation request schemas. Constraint forwarding is implemented in application logic within each agent. Verification is performed by periodic audit of delegation logs rather than real-time enforcement. Delegation depth is not limited. This level meets minimum requirements but relies on each agent correctly implementing constraint forwarding, creating single-point-of-failure risks at every hop.
Intermediate Implementation — Constraints are represented as structured, typed objects in a standardised schema shared across all agents. Constraint verification is performed at each delegation step by an infrastructure-layer gateway that computes the constraint intersection and blocks weakening delegations. Delegation depth is limited by configuration. The full constraint chain is recorded in an immutable log. Constraint schema coverage is verified — delegations are blocked when the receiving agent's schema cannot represent all upstream constraints.
Advanced Implementation — All intermediate capabilities plus: constraints are carried in cryptographically signed envelopes verified at each hop. Formal verification tools confirm that no delegation path in the system can produce constraint escalation. Cyclic delegation detection blocks re-delegation loops. Constraint propagation is tested through adversarial scenarios including schema manipulation, signature forgery, and concurrent multi-path delegation attacks. Real-time dashboards visualise constraint propagation across the full agent network. Independent penetration testing has confirmed that no known attack vector can weaken constraints through delegation chains.
Required artefacts:
Retention requirements:
Access requirements:
Testing AG-083 compliance requires verification that constraints survive intact across delegation chains of varying depth and complexity.
Test 8.1: Single-Hop Constraint Preservation
Test 8.2: Multi-Hop Constraint Preservation
Test 8.3: Constraint Schema Incompatibility Blocking
Test 8.4: Constraint Weakening Rejection
Test 8.5: Cyclic Delegation Privilege Escalation
Test 8.6: Concurrent Multi-Path Constraint Resolution
Test 8.7: Delegation Depth Limit Enforcement
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Direct requirement |
| EU AI Act | Article 14 (Human Oversight) | Supports compliance |
| FCA SYSC | 6.1.1R (Systems and Controls) | Direct requirement |
| NIST AI RMF | GOVERN 1.1, MANAGE 2.2 | Supports compliance |
| ISO 42001 | Clause 6.1 (Actions to Address Risks), Clause 8.2 (AI Risk Assessment) | Supports compliance |
| DORA | Article 9 (ICT Risk Management Framework) | Supports compliance |
| MiFID II | Article 16 (Organisational Requirements) | Supports compliance |
Article 9 requires that risk management measures address foreseeable risks arising from the AI system's operation. In multi-agent deployments, the foreseeable risk of constraint erosion across delegation chains is a system-level risk that AG-083 directly mitigates. The regulation's requirement that risk mitigation be "as far as technically feasible" means that relying on natural-language constraint forwarding when structural, machine-enforceable propagation is feasible would not meet the standard.
Human principals set governance constraints with the expectation that those constraints bind all agents acting on their behalf, regardless of delegation depth. AG-083 ensures that human oversight decisions — expressed as constraints — are not diluted through agent-to-agent delegation. Without transitive preservation, human oversight is effectively limited to the first agent in the chain.
For financial services firms deploying multi-agent systems, SYSC 6.1.1R requires adequate systems and controls. A multi-agent system where risk limits can erode through delegation chains does not meet this standard. The FCA expects firms to demonstrate that risk controls apply end-to-end across all execution paths, including delegation chains. Under the Senior Managers Regime, personal accountability extends to ensuring that delegated authority does not exceed approved limits at any point in the chain.
GOVERN 1.1 requires governance structures for AI systems including multi-agent architectures. MANAGE 2.2 requires enforceable controls for managing AI risks. Transitive constraint preservation is the enforceable control that ensures governance structures survive delegation chains.
Risk assessment under Clause 8.2 must consider the risk of constraint erosion in multi-agent systems. Clause 6.1 requires actions to address identified risks. AG-083 provides the risk treatment for delegation-chain constraint loss within the AI management system.
For financial entities using multi-agent ICT systems, Article 9 requires risk management covering the full technology stack. Constraint propagation across agent delegation chains is an ICT risk management control that must be included in the framework.
Article 16 requires investment firms to maintain organisational arrangements sufficient to ensure compliance. In multi-agent trading or advisory systems, transitive constraint preservation ensures that regulatory limits (position limits, best execution parameters, client suitability constraints) propagate through every delegation hop to the executing agent.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Multi-agent system boundary — all agents in a delegation chain and all systems they interact with |
Consequence chain: Failure of transitive constraint preservation means that the effective governance boundary of a multi-agent system is determined by the weakest link in the delegation chain rather than by the principal's intent. A single agent that fails to forward a value ceiling, a counterparty restriction, or a data access boundary creates a downstream execution environment with fewer controls than the organisation authorised. The exposure scales with delegation depth: each additional hop provides another opportunity for constraint loss, and the probability of at least one constraint being dropped increases multiplicatively. In financial services, this can result in unauthorised transaction exposure — as demonstrated in Scenario A, where GBP 230,000 in payments exceeded the GBP 50,000 mandate through a 3-hop chain. In healthcare, constraint loss can result in HIPAA violations through over-broad data access. In critical infrastructure, safety constraint attenuation through delegation chains can create physical safety risks. The failure is particularly insidious because each individual agent may appear compliant when examined in isolation — the violation is visible only when the full chain is analysed end-to-end. Detection requires the constraint chain logging and verification mandated by this dimension. Remediation requires architectural changes to the constraint propagation mechanism, which typically involves redesigning the delegation protocol across all agents in the system.
Cross-references: This dimension extends AG-001 (Operational Boundary Enforcement) to multi-agent delegation chains and depends on AG-009 (Delegated Authority Governance) for the foundational delegation model. It intersects with AG-017 (Multi-Party Authorisation Governance) where delegations require multi-party approval, and with AG-028 (Active Inter-Agent Collusion Detection) where coordinated constraint weakening across agents may indicate collusive behaviour. Within the Multi-Agent Orchestration & Delegation landscape, it is closely related to AG-084 (Inter-Agent Contract and Obligation Governance), AG-085 (Orchestrator Dominance and Failover Governance), and AG-086 (Multi-Agent Consensus and Quorum Governance).