Security / Resilience / Autonomous Systems
H-R08 — Multi-Agent Incident Command, Delegation, and Failure-Closed Coordination
Report summary
[Label: institutional analysis] The escalating velocity, scale, and complexity of cyber-physical incidents require the deployment of autonomous, multi-agent response networks. Traditional monolithic security orchestration, which relies on centralized decision-making and ambient authority, is structu
Key topics
- Security / Resilience / Autonomous Systems
- Security
- Resilience
- Autonomous Systems
- AI
- Agentic Web
- .NET
- Runtime
- Rust
Research provenance
For citation, use the report title and canonical URL. Archival presence does not establish authorship or promote report statements into portfolio evidence.
This page renders the archived Markdown as safe, formatted HTML. It is background research and does not become a portfolio claim without evidence review.
Full report
On this page
1. Executive Decision Brief
\[Label: institutional analysis\] The escalating velocity, scale, and complexity of cyber-physical incidents require the deployment of autonomous, multi-agent response networks. Traditional monolithic security orchestration, which relies on centralized decision-making and ambient authority, is structurally insufficient for modern adversarial environments due to high latency, context rot, and single points of failure. \[Label: technical proposal\] This report proposes the H-R08 Architecture: a decentralized, machine-led incident coordination framework utilizing cryptographic capability tokens, semantic grounding, and fail-closed state machines. \[Label: reasoned inference\] By binding explicit resource budgets, monotonic privilege attenuation, and strict delegation receipts to specialized agent roles, H-R08 ensures that autonomous remediation scales safely without succumbing to runaway recursion, semantic drift, or cascading privilege escalation. \[Label: observed deployment or practice\] Historically, the assignment of ambient credentials to automated systems has resulted in catastrophic blast radiuses when an orchestration layer is compromised1. H-R08 mitigates this by mandating that no agent acts on ambient authority; instead, every action is gated by an Attenuating Authorization Token (AAT) that dictates exact tool-level constraints, executed over a cryptographically verifiable delegation chain3. \[Label: established standard or law\] This architecture aligns with emerging regulatory mandates, including Article 50 of the EU AI Act, which requires strict provenance and attribution for algorithmic actions5.
2. Definitions and System Boundaries
\[Label: established standard or law\] The definitions herein synthesize emerging Internet Engineering Task Force (IETF) drafts, NIST frameworks, and W3C data models to establish the operational boundaries of the H-R08 architecture.
- Attenuating Authorization Token (AAT): A signed JSON Web Token (JWT) encoding tool-level constraints, permitting offline derivation of tokens with equal or narrower authority (monotonic attenuation)3. It relies on a Proof of Possession (PoP) model linking the token to a specific agent's ephemeral key6.
- Semantic Drift: Syntactically valid but semantically contradictory state between systems, occurring when internal representations diverge from objective human, ethical, or institutional realities over time8.
- Failure-Closed (Fail-Closed): A design principle wherein an inability to reach consensus, verify a token, or resolve a conflict automatically transitions the system into a restricted, secure state, blocking further network mutations and refusing the transition10.
- Delegation Receipt Protocol (DRP): A cryptographic primitive proving an authorizing entity signed an Authorization Object containing scope boundaries, time windows, and operator instruction hashes before execution12.
- Succession Receipt: A portable, signed JSON document proving one completed, policy-gated transfer of authority between two agents (a predecessor and successor steward), establishing obligation lineage13.
- Actor Chain: A tamper-evident, ordered record of all actors in a delegation chain, replacing traditional informational nested act claims to enable policy-enforceable accountability4.
3. Historical and Technical Context
\[Label: peer-reviewed research finding\] Cybersecurity incident investigation has historically relied on human analysts or centralized, single-agent systems to collect evidence, correlate events, and reconstruct attack paths15. The increasing volume of telemetry necessitated a shift toward multi-agent collaboration (MAC), where specialized agents (e.g., Endpoint, Network, Threat Intelligence) parallelize tasks15. \[Label: institutional analysis\] However, early MAC systems suffered from "context rot"—the degradation of language model performance over long context windows—and unconstrained recursion17. \[Label: historical context\] The foundational concept of delegated, attenuated authority originated with Macaroons in 2014, which introduced HMAC-chained bearer tokens supporting first- and third-party caveats18. While Macaroons provided delegation without centralized issuer contact, their reliance on symmetric cryptography and lack of strong Proof of Possession limited their utility in globally distributed, zero-trust multi-agent ecosystems7. \[Label: observed deployment or practice\] Furthermore, early identity models for AI granted agents ambient credentials—meaning an agent tasked with reading a log file held the same system-wide authority as the orchestrator that spawned it, creating massive vulnerabilities to prompt injection and Confused Deputy attacks1.
4. Current Standards, Law, Policy, and Deployed Practice
\[Label: current official policy\] The regulatory landscape for autonomous agents is rapidly tightening. The EU AI Act (Article 50\) begins enforcing strict provenance tracking for AI-generated artifacts and actions in August 2026, imposing fines for organizations unable to prove the lineage of automated decisions5. \[Label: technical proposal\] In response to these requirements and the structural failures of traditional OAuth 2.0 in multi-hop delegation, the IETF OAuth and WIMSE working groups have introduced several critical specifications:
- Attenuating Authorization Tokens for Agentic Delegation Chains (draft-niyikiza-oauth-attenuating-agent-tokens): Defines an offline-derivable, monotonic attenuation invariant for OAuth, allowing agents to issue narrowed capability tokens to sub-agents without Authorization Server (AS) contact3.
- Cryptographically Verifiable Actor Chains (draft-mw-spice-actor-chain): Replaces the informational nested act claims of RFC 8693 with a cryptographically verifiable, tamper-evident record of all actors in a delegation chain, providing an "East-West" axis of accountability4.
- PEDIGREE (draft-rampalli-pedigree): Extends SPIFFE workload identity with dual-layer authority enforcement, combining an operator-controlled ceiling with per-parent mandate narrowing, effectively bridging identity and dynamic delegation1.
- Succession Receipts (draft-sabey-succession-receipts): Specifies JSON Canonicalization Scheme (JCS) receipts proving policy-gated transfers of authority between agents, addressing the "attribution gap" during agent upgrades or task handoffs13.
- Refusal Transparency (draft-sabey-refusal-transparency): Establishes signed, replay-resistant evidence of refused agent-system transitions, proving what the governing system explicitly prevented from happening11.
5. Architecture and Data Models
5.1 Comparison of Coordination Paradigms
\[Label: institutional analysis\] The selection of a coordination paradigm dictates the resilience, scalability, and security of the multi-agent incident response network. H-R08 mandates a hybrid approach, rejecting pure orchestration in favor of a capability-gated actor system coordinated via an arbitrated blackboard.
| Paradigm | Architectural Mechanism | Operational Strengths | Critical Weaknesses for Incident Response |
|---|---|---|---|
| Orchestration | Centralized controller dictates step-by-step execution to subordinates. | High predictability; easy to log centrally; linear execution trace. | Single point of failure; poor horizontal scalability; high latency; bottlenecked decision-making. |
| Choreography | Decentralized; agents react to events published to a common bus. | Highly scalable; resilient to single-node failures; decoupled. | Difficult to trace global state; high risk of cascading asynchronous loops and race conditions. |
| Blackboard Systems | Agents post findings and hypotheses to a shared semantic memory space. | Excellent for heterogeneous agents building shared context iteratively. | Write-contention; requires complex ontology alignment to prevent semantic drift. |
| Stigmergy | Environment-mediated communication (e.g., digital pheromones). | Massive scalability; entirely decoupled operations. | Slow convergence; highly probabilistic; unsuitable for real-time critical isolation. |
| State Machines | Deterministic state transitions governed by strict rules and triggers. | Verifiable, highly auditable, easily fail-closed10. | Rigid; struggles with the probabilistic ambiguity of LLM outputs. |
| Actor Systems | Isolated agents communicate strictly via asynchronous message passing. | Fault isolation; lock-free concurrency; localized state. | Prone to semantic disagreement; requires complex deadlock-resolution logic23. |
| Consensus | Byzantine Fault Tolerant (BFT) voting to agree on system state. | High resilience against compromised peers (Sybil attacks). | Extremely slow; high compute/energy token cost; stalls under network partition. |
| Market-based | Agents bid on tasks using synthetic budgets or compute tokens. | Optimizes localized resource distribution organically. | Risks systemic starvation of critical functions; susceptible to adversarial market manipulation. |
5.2 Nine Incident Roles
\[Label: technical proposal\] To enforce the principle of least privilege, H-R08 defines nine specialized incident roles. An agent may only hold one role per assigned AAT, preventing multi-domain capability escalation15.
| Role | Permitted Inputs | Permitted Outputs | Permitted Tools | Prohibited Actions |
|---|---|---|---|---|
| 1\. Observer | Raw telemetry, PCAP, system logs, memory dumps. | Structured observation schemas (JSON/RAR). | Read-only sensors, Log query APIs, memory reading interfaces. | Writing to databases, altering state, issuing API requests outside logging. |
| 2\. Classifier | Observation schemas, threat intelligence feeds. | Categorized threat models, confidence scores, hypotheses. | Inference models, heuristic engines, ontology mapping tools. | Modifying network rules, terminating processes, reading raw disk data. |
| 3\. Isolator | Threat models, dynamic network graphs, explicit isolation mandates. | Isolation execution logs, quarantine state hashes. | Firewall APIs, IAM revocation tools, EDR quarantine interfaces. | Deleting forensic data, modifying system files, deploying new code. |
| 4\. Stabilizer | System health metrics, load balancer states, capacity alerts. | Rerouting configs, rate-limit policies, auto-scale events. | Traffic shaping APIs, autoscaling triggers, load balancer configs. | Terminating baseline infrastructure, deploying unaudited containers. |
| 5\. Recoverer | Backup manifests, clean state hashes, CI/CD artifacts. | Restoration receipts, updated infrastructure state. | CI/CD rollback tools, Volume snapshot APIs, orchestration hooks. | Changing global IAM policies, altering cryptographic root keys. |
| 6\. Verifier | Restored state hashes, system metrics, output logs. | Cryptographic verification receipts, compliance attestations. | Read-only test suites, checksum calculators, formal verifiers. | Modifying any active production state or configuration. |
| 7\. Preserver | Volatile memory dumps, raw disk images, audit logs. | WORM-locked evidence bundles, cryptographic chain-of-custody hashes. | Forensic imaging tools, hashing functions, WORM storage APIs. | Executing contained malware, modifying original disk states. |
| 8\. Corrector | Vulnerability reports, source code, semantic diffs. | Patch diffs, semantic alignment proofs, pull requests. | Static analysis tools, version control APIs, code rewriting models. | Merging code without human/Receipt-bound approval, altering IAM. |
| 9\. Resolver | Multi-agent conflict logs, semantic mismatches, policy schemas. | Conflict resolution receipts, protocol resets, arbitration results. | Blackboard arbitration APIs, state machine override triggers. | Executing remediation tasks directly, bypassing fail-closed parameters. |
5.3 Contract Schema
\[Label: technical proposal\] Every agent interaction requires an explicitly negotiated contract, instantiated as an Attenuating Authorization Token (AAT) based on draft-niyikiza-oauth-attenuating-agent-tokens3. The token is a JWT containing the following schema:
1. Principal: Identified by a URI identifying the root issuer (for root tokens) or a JWK Thumbprint URI encoding the signing key of the delegator6. The principal's identity is augmented by an actor\_chain array, proving the exact path of delegation4.
2. Agent (Holder): Represented by the cnf.jwk claim. The executing sub-agent generates a fresh ephemeral key pair and proves possession via a DPoP (Demonstrating Proof-of-Possession) signature6.
3. Purpose: Encoded within the authorization\_details claim (RFC 9396), bounding the token to a specific intent (e.g., intent\_hash binding the task to a human-approved objective via a Delegation Receipt)3.
4. Scope: Monotonically attenuated tool constraints. Example: {"type": "attenuating\_agent\_token", "tools": {"isolate\_ip": {"ip": {"pattern": "10.0.\.\"}}}}3.
5. Budgets: Explicit limits embedded as structured constraints within the RAR payload, ensuring inference gateways terminate execution upon limit breaches. Includes max\_token\_spend and compute\_ms25.
6. Expiry: Standard JWT exp (Expiration Time) and nbf (Not Before) claims to enforce strict temporal boundaries.
7. Revocation: Ephemeral keys are linked to a Continuous Evaluation revocation ledger, monitored by the Inference Gateway25.
8. Audit: Integration of the DRP receipt\_hash within the prf claim to prove pre-execution authorization12.
9. Non-Transitivity: The del\_max\_depth claim. A token derived with del\_max\_depth: 0 is a leaf execution token and cannot be attenuated or delegated further3.
5.4 Bounding Recursion, Tokens, Network, Compute, Time, and Energy
\[Label: reasoned inference\] Multi-agent systems frequently succumb to "token fatigue" and unconstrained recursion when looping indefinitely in ReAct-style agent loops27. \[Label: technical proposal\] H-R08 rejects agent self-regulation, instead bounding resources explicitly at the Inference Gateway and Enforcement layers25:
- Recursion: Enforced cryptographically by the del\_depth and del\_max\_depth claims. The verification algorithm rejects any AAT where the depth exceeds the maximum, preventing infinite sub-agent spawning6.
- Token Use: The Inference Gateway tracks token generation against the AAT's embedded max\_token\_spend constraint. Execution is hard-terminated when the ceiling is reached, preventing runaway costs25.
- Network Calls: API gateways enforce leaky-bucket rate limiting based on the specific constraints bound to the tool identifier in the AAT's authorization\_details6.
- Compute & Energy: Bounded directly by wall-clock limits mapped to the exp claim. Models that fail to converge on an output within the temporal constraint fail cryptographic verification downstream.
6. Failure Modes and Adversarial Cases
\[Label: scenario\] Robust coordination requires anticipating catastrophic logic failures and adversarial manipulation. The following 60 scenarios define the testing boundaries for H-R08 assurance.
6.1 Confused Deputy Attacks
\[Label: scenario\] Exploits where an authorized agent is manipulated into executing actions on behalf of an attacker lacking those permissions.
| ID | Scenario Description |
|---|---|
| 1 | Malicious payload inside a server log file tricks the Classifier into executing an isolation command. |
| 2 | Attacker provides a prompt-injected filename that an Observer passes to the Isolator, causing self-quarantine. |
| 3 | Sub-agent receives a token for /data/read but is tricked into calling a privileged /system/read endpoint using path traversal constraints. |
| 4 | An agent processes a forged threat intel feed, incorrectly marking critical infrastructure IP ranges as malicious. |
| 5 | Attacker embeds Markdown tool-call syntax in a user profile, hijacking the Corrector agent's patch generation output. |
| 6 | The Stabilizer is manipulated into rerouting traffic to an attacker-controlled load balancer via poisoned telemetry streams. |
| 7 | An agent interprets a benign error message as an instruction to escalate privileges via an authentication bypass tool. |
| 8 | Attacker uses Unicode normalization vulnerabilities in tool identifiers to bypass exact-string AAT constraints6. |
| 9 | Verifier agent evaluates a corrupted state hash as valid due to an intentionally engineered pre-image collision attack. |
| 10 | Malicious peer feeds the Resolver a fabricated conflict log to intentionally force a fail-closed denial of service. |
6.2 Sybil Entry and Identity Spoofing
\[Label: scenario\] Exploits involving the creation of false identities or the truncation of delegation histories.
| ID | Scenario Description |
|---|---|
| 11 | Attacker rapidly spins up thousands of rogue agents claiming to be Observers to poison the Blackboard consensus. |
| 12 | Compromised sub-agent attempts to forge a parent token without holding the required cnf.jwk private key3. |
| 13 | Attacker replays a valid AAT intercepted over TLS to a different enforcement point lacking nonce verification. |
| 14 | Malicious actor truncates the actor\_chain to hide its compromised origin before delegating to a Stabilizer4. |
| 15 | Rogue container generates a valid SPIFFE ID but attempts to bypass the AAT root issuer for capability granting1. |
| 16 | An agent masquerades as the Resolver to issue false Succession Receipts, claiming illegitimate authority13. |
| 17 | Sybil agents flood the Classifier with contradictory evidence to stall inference and trigger a timeout. |
| 18 | Attacker clones a suspended agent’s identity microseconds before the distributed revocation list propagates globally. |
| 19 | Malicious agent signs a DPoP proof with an altered htu (HTTP URI) to hijack a tool outside its mandate7. |
| 20 | Cross-tenant Sybil attack where an agent from Tenant A assumes an incident role in Tenant B's incident graph. |
6.3 Hidden Resource Consumption
\[Label: scenario\] Exploits targeting the economic and computational bounds of the multi-agent system27.
| ID | Scenario Description |
|---|---|
| 21 | Agent is trapped in a recursive loop parsing a self-referential JSON log, rapidly exhausting LLM token budgets. |
| 22 | Attacker feeds highly compressed, deeply nested structures (Zip bomb) to the Preserver during forensic imaging. |
| 23 | Malicious query forces the Observer to fetch a multi-terabyte database, exhausting network quotas and bandwidth. |
| 24 | Agent spawns sub-agents up to del\_max\_depth, but each sub-agent consumes maximum allowed execution time, stalling the tree. |
| 25 | Prompt injection forces an agent to engage in extraneous "chain-of-thought" reasoning, consuming maximum API budgets30. |
| 26 | Attacker triggers a continuous state of semantic disagreement, forcing the Resolver into infinite arbitration loops. |
| 27 | Agents continuously ping the Blackboard with redundant data, creating a massive database lock contention condition. |
| 28 | Forced generation of excessively large Succession Receipts inflates ledger storage on the continuous evaluation plane. |
| 29 | Attacker submits queries that perfectly skirt rate limits but force extremely heavy, un-cached LLM compute. |
| 30 | Cryptographic DoS: Forcing agents to verify millions of deep, invalid AAT chains and Ed25519 signatures. |
6.4 Semantic Drift and Ontological Misalignment
\[Label: scenario\] Failures arising when systems maintain syntactic validity but diverge in human-aligned meaning8.
| ID | Scenario Description |
|---|---|
| 31 | The Classifier labels a state as "Active", but the Isolator interprets "Active" as "Under Attack", severing the connection. |
| 32 | Gradual degradation of an agent's internal prompt fidelity over long context windows (Context Rot)17. |
| 33 | An updated endpoint API changes the meaning of a status code, causing the Verifier to silently fail to recognize an error. |
| 34 | Two agents trained on different underlying LLMs interpret the same ambiguous threat differently, deadlocking the Blackboard. |
| 35 | The definition of "least privilege" drifts across agent generations via unsupervised self-evolution loops31. |
| 36 | A malicious peer subtly alters the syntax of a shared hypothesis, shifting the investigation focus away from the actual attacker. |
| 37 | Corrector applies a patch that is syntactically valid and passes unit tests but semantically breaks business logic32. |
| 38 | Temporal semantic drift: A token issued for "deploy" applies to a completely different, newly compromised container image an hour later. |
| 39 | The Resolver incorrectly maps a network ontology to a host ontology, creating an invalid remediation plan33. |
| 40 | Attacker poisons the LLM's neutral text exemplars to bias classification, causing systemic hallucination23. |
6.5 Stale Authority and Revocation Failures
\[Label: scenario\] Exploits leveraging the synchronization gaps between authority revocation and execution8.
| ID | Scenario Description |
|---|---|
| 41 | An agent completes its task but retains an unexpired AAT, which is subsequently hijacked via memory scraping24. |
| 42 | The root issuer revokes a parent token, but offline sub-agents continue executing via locally cached verifications3. |
| 43 | A clock-skew attack extends the validity of an exp claim by manipulating local NTP servers on the enforcement node. |
| 44 | The Isolator executes a quarantine order based on a Succession Receipt that was superseded milliseconds prior. |
| 45 | A human operator revokes consent via DRP, but the asynchronous Corrector agent has already locked the transaction. |
| 46 | Agent exploits the sync-lag window between a CRM and an operational database to execute a stale command8. |
| 47 | Ephemeral key pairs (cnf.jwk) are not securely scrubbed from memory after token expiration, allowing post-execution extraction. |
| 48 | A Refusal Digest is generated, but an agent ignores it due to a race condition and executes the forbidden action anyway11. |
| 49 | nbf (not before) constraints are bypassed by manipulating the enforcement point's system time backward. |
| 50 | An agent presents a valid AAT but an outdated SPIFFE ID, bypassing identity-based revocation checks1. |
6.6 Cascading Failure
\[Label: scenario\] Systemic collapses resulting from tight coupling and localized errors propagating globally.
| ID | Scenario Description |
|---|---|
| 51 | The Isolator incorrectly quarantines the core DNS server, effectively blinding the Observer and Stabilizer agents. |
| 52 | A failure in the Blackboard forces all agents to fall back to direct messaging, causing a distributed network storm. |
| 53 | The Resolver fails closed, triggering a safety protocol that suspends all agents, completely halting incident response. |
| 54 | A compromised Corrector pushes a bad rule, which the Verifier rejects, triggering an infinite rollback/reapply loop. |
| 55 | Token limits hit globally simultaneously across all tiers, freezing all agents mid-execution without logging final states. |
| 56 | An orchestrator node goes offline, leaving child agents with valid AATs but no reporting structure to return outputs. |
| 57 | A false positive in threat intelligence causes the entire multi-agent network to treat benign traffic as hostile, shutting down production. |
| 58 | A conflict over resource budgets causes the market-based allocator to systematically starve critical Recoverer functions. |
| 59 | Attenuated tokens become so restrictive after 3 hops that leaf agents cannot perform basic functions, stalling the graph. |
| 60 | A misconfigured fail-closed state machine permanently locks out human operators alongside the agents, preventing manual override. |
7. Evidence and Currentness Requirements
\[Label: established standard or law\] Incident accountability requires continuous cryptographic evidence of agent actions, ensuring non-repudiation and traceability.
7.1 Handoff Receipts, Succession, and Correction Propagation
\[Label: technical proposal\] When authority transitions from one agent to another (e.g., from a Classifier identifying a threat to an Isolator neutralizing it), a Succession Receipt13 is generated. This receipt uses the JSON Canonicalization Scheme (JCS) with Ed25519 signatures to record the predecessor, successor, authorities revoked, and authorities derived. This prevents the "attribution gap" where a compromised sub-agent cannot be linked to its parent1. \[Label: reasoned inference\] Semantic disagreements must be explicitly mediated rather than silently overwritten. When an Observer and a Verifier produce contradictory state hashes (semantic disagreement), the Resolver agent initiates an EVALUATE\_CONFLICT routine. The Resolver queries the Blackboard for the divergence point, generates a deterministic diff, and issues a strictly attenuated AAT to the Corrector to align the state, generating a new Succession Receipt for the correction.
7.2 Failure-Closed State Machine for Negotiation Breakdown
\[Label: technical proposal\] If the Resolver cannot achieve consensus within a predefined timeout\_ms, the system enters a Failure-Closed sequence to prevent unguided mutation.
| State | Action Triggered | Transition on Success | Transition on Failure |
|---|---|---|---|
| 1\. NEGOTIATE | Attempt standard operational conflict mediation via Blackboard. | EXIT: SUCCESS | EVALUATE\_CONFLICT |
| 2\. EVALUATE\_CONFLICT | Assess semantic distance and syntax validity. | DISPATCH\_CORRECTOR | ESCALATE |
| 3\. ESCALATE | Request human-in-the-loop (HITL) Delegation Receipt12. | OVERRIDE\_EXECUTE | ISOLATE\_PEER (Timeout/Denial) |
| 4\. ISOLATE\_PEER | Issue del\_max\_depth: 0 revocation AAT to the contradictory agent. | REVOKE\_AUTHORITY | HALT\_CLOSED (Immediate) |
| 5\. REVOKE\_AUTHORITY | Flush all child AATs associated with the isolated peer. | HALT\_CLOSED | HALT\_CLOSED |
| 6\. HALT\_CLOSED | Terminate operations for affected graph segment. Write Refusal Digest11. | N/A (Terminal State) | N/A (Terminal State) |
8. Operational and Institutional Implications
\[Label: institutional analysis\] Transitioning to the H-R08 architecture alters the foundational paradigm of security operations. Trust shifts entirely from the runtime monitoring of monolithic systems to the pre-execution cryptographic gating of ephemeral agents. \[Label: policy proposal\] Institutions must establish "Root Issuers" responsible for binding human intent (via OIDC/SAML) to the root AATs3. Human analysts transition from manual log hunting to designing precise constraint vocabularies and reviewing WORM-locked Trust Receipts34. The reliance on draft-sabey-refusal-transparency means institutions can now definitively audit what the governance system prevented, rather than merely logging what occurred11.
9. Public-Versus-Protected Information Boundary
\[Label: policy proposal\] Incident graphs inherently ingest sensitive telemetry, including PII, proprietary source code, and trade secrets. The Preserver and Classifier agents must operate within highly restrictive zero-trust enclaves. AAT capability claims MUST explicitly restrict cross-boundary data egress. \[Label: technical proposal\] For external reporting, a specialized Sanitizer agent (a sub-role of the Preserver) must be provisioned. This agent holds an AAT explicitly constrained to outputting k-anonymized or structurally redacted summaries. Under the principle of non-transitivity, no agent holding an execution token for external network egress may simultaneously hold an execution token for protected enclave read access, preventing data exfiltration via prompt injection.
10. Implementation Roadmap
\[Label: technical proposal\]
- Phase 1: Foundation (Months 1-3). Deploy the underlying OIDC/SPIFFE identity fabric. Implement AAT Root Issuers and Inference Gateways with hard mathematical resource budgets (token ceilings, recursion limits)25.
- Phase 2: Observation (Months 4-6). Deploy the Blackboard and initial read-only agents (Observer, Verifier, Classifier). Establish continuous evaluation of semantic drift using Desc2Fix methodologies32.
- Phase 3: Governance (Months 7-9). Introduce Succession Receipts and Delegation Receipts. Enable the Resolver and Preserver agents to handle conflict mediation and WORM storage. Implement Refusal Transparency logging11.
- Phase 4: Remediation (Months 10-12). Deploy write-capable agents (Isolator, Stabilizer, Recoverer, Corrector) under strict monotonic attenuation constraints and activate the fail-closed state machines.
11. Test and Assurance Plan
\[Label: technical proposal\]
- Stage 1: Cryptographic Invariance. Formally verify the monotonic attenuation of AATs using formal logic solvers (e.g., Alloy or Z3)35. Prove mathematically that no child token can exceed parent capability and that del\_max\_depth limits recursion strictly.
- Stage 2: Adversarial Red Teaming. Execute the 60 defined adversarial scenarios using automated prompt-injection and Sybil frameworks to validate role boundaries and budget enforcement.
- Stage 3: Refusal Transparency Validation. Validate that all blocked actions generate a cryptographically sound Refusal Digest11, ensuring absolute accountability for what the system prevented.
- Stage 4: Semantic Alignment Benchmarking. Deploy continuous evaluations to measure semantic drift between the Classifier and Corrector under high-load conditions, ensuring ontologies remain aligned with human intent9.
12. Open Research Questions
\[Label: hypothesis\]
1. How can zero-knowledge proofs (ZKPs) be integrated into AATs to allow agents to prove authorization capabilities to third-party tool providers without revealing the exact constraint schemas?
2. What standardized benchmarks can accurately measure semantic drift and cross-agent coordination latency in real-time incident environments?15.
3. How can LLM context-window expansion (e.g., recursive LLMs) be mathematically bounded to guarantee polynomial time complexity during conflict resolution, avoiding context rot?17.
13. Contradiction Register
| Source | Claim A | Claim B | Resolution / H-R08 Stance |
|---|---|---|---|
| AAuth vs. AAT/PEDIGREE1 | AAuth explicitly rejects scope attenuation for agents. | PEDIGREE and AAT mandate monotonic scope attenuation. | H-R08 strictly aligns with AAT/PEDIGREE. Scope attenuation is absolutely mandatory for least-privilege delegation in multi-hop systems. |
| Nested act claims (RFC 8693\)4 | Prior actors in an OAuth token are informational only. | draft-mw-spice-actor-chain makes prior actors policy-enforceable. | H-R08 requires cryptographically verifiable actor chains to prevent identity truncation and attribution gaps. |
| Traditional Data Quality8 | Semantic agreement is column-scoped and schema-driven. | Semantic drift occurs despite valid syntax. | H-R08 implements LLM-driven semantic reconciliation via the Resolver to catch silent ontological drift. |
14. Claim-Status Table
| Claim | Status Category |
|---|---|
| AAT provides offline monotonic attenuation via JWT | \[established standard or law\] (IETF Draft) |
| EU AI Act requires algorithmic provenance by Aug 2026 | \[current official policy\] |
| Agents suffer from context rot in long execution | \[peer-reviewed research finding\] |
| Fail-closed state machines mitigate rogue agents | \[technical proposal\] |
| Market-based allocation risks systemic starvation | \[reasoned inference\] |
| Succession receipts bind pre-execution authority | \[technical proposal\] |
15. Source-Quality Table
| Source Type | Authority Level | Application in Report |
|---|---|---|
| IETF Internet-Drafts (AAT, PEDIGREE, DRP) | High (Primary Technical Specification) | Defines the cryptographic architecture, token schema, Proof of Possession, and receipt mechanisms. |
| Peer-Reviewed Research (IEEE, ACM) | High (Empirical Evidence) | Grounds claims on multi-agent collaboration, semantic drift, LLM constraints, and ReAct loop failures. |
| Government Publications (FEMA, EU AI Act) | High (Statutory/Policy) | Dictates the regulatory necessity of provenance, attribution, and structured incident command. |
| Corporate Technical Blogs (WorkOS, Tenuo) | Medium (Observed Practice) | Provides context on practical enterprise adoption, gateway enforcement, and limitations of existing OAuth. |
16. Detailed Bibliography
- \[cite: 15\] Multi-Agent Collaboration for Automated Cybersecurity Incident Investigation, IEEE/ACM.
- \[cite: 16, 36\] Multi-Agent Collaboration in Incident Response with Large Language Models (Backdoors & Breaches framework).
- \[cite: 18, 19, 37\] Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud. NDSS.
- \[cite: 17, 27\] Recursive LLMs: Bounding Resource Consumption.
- \[cite: 25\] LLMOps: Model Deployment Strategy Guide.
- \[cite: 3, 6, 7, 21\] Niyikiza, N. A. Attenuating Authorization Tokens for Agentic Delegation Chains (draft-niyikiza-oauth-attenuating-agent-tokens-01). IETF. June 2026\.
- \[cite: 12\] Nelson, R. Delegation Receipt Protocol for AI Agent Authorization (draft-nelson-agent-delegation-receipts-10). IETF. June 2026\.
- \[cite: 4, 21\] Prasad, A., et al. Cryptographically Verifiable Actor Chains for OAuth 2.0 Token Exchange (draft-mw-spice-actor-chain-00). IETF.
- \[cite: 23, 32\] Semantic Drift in Bug Resolution: How Behavioral Signals Propagate. EACL 2026\.
- \[cite: 13, 14\] Sabey, J. Succession Receipts: Portable Signed Evidence of Authority Succession Between Autonomous Agents (draft-sabey-succession-receipts-02). IETF. July 2026\.
- \[cite: 11\] Sabey, J. Refusal Transparency: Signed, Replay-Resistant Evidence of Refused Agent-System Transitions (draft-sabey-refusal-transparency-02). IETF. July 2026\.
- \[cite: 34, 38\] Authorization Receipts for High-Risk Agent Actions (draft-schrock-ep-authorization-receipts-10). IETF.
- \[cite: 1\] Rampalli, K. PEDIGREE: Verifiable Delegation Identity for Agentic AI Systems (draft-rampalli-pedigree-00). IETF. April 2026\.
17. 30 Direct-Answer Items
\[Label: reasoned inference\]
1. How are roles divided? Roles are strictly isolated by capability; e.g., an Observer reads telemetry, an Isolator writes network rules, avoiding overlap.
2. What is an agent contract? A cryptographically signed AAT containing intent, scope, and budget constraints.
3. How do agents prove identity? Via SPIFFE workload IDs and X.509/OIDC credentials1.
4. How do they prove authority? Via Attenuating Authorization Tokens (AATs) and Proof of Possession (DPoP) signatures6.
5. How is identity separated from authority? Identity is "who the agent is" (SPIFFE); authority is "what the agent holds" (AAT)1.
6. How does delegation propagate? Downward via offline monotonic attenuation of the AAT's RAR constraints3.
7. How does revocation propagate? Ephemeral key rotation and Continuous Access Evaluation (CAE) checks at the enforcement gateway.
8. What is semantic disagreement? When two agents process syntactically valid data but derive contradictory operational meanings8.
9. How are contradictory observations handled? Sent to a Blackboard for arbitration by a dedicated Resolver agent.
10. How are malicious peers handled? Identity eviction via fail-closed state machines and revocation of the peer's root AAT.
11. How is recursion bounded? A strict del\_max\_depth integer claim in the AAT limits the depth of the delegation chain6.
12. How is token use bounded? Inference gateways enforce hard ceilings on prompt and generation tokens per agent per task25.
13. How are network calls bounded? API gateways enforce leaky-bucket rate limiting based on the constraints bound to the tool in the AAT.
14. How is compute bounded? Wall-clock timeouts and max execution step parameters evaluated at runtime.
15. How is energy bounded? Reflected as an extension of compute bounding; jobs failing to converge within limits are terminated.
16. What is monotonic attenuation? A property where delegated permissions can only become stricter or stay the same, never broader3.
17. What is a Succession Receipt? A JCS-signed document proving the legitimate transfer of authority from a predecessor to a successor13.
18. What is a Refusal Digest? Cryptographic proof of actions that the system's governance layer explicitly blocked11.
19. Why avoid traditional orchestration? It creates a high-latency, single point of failure that struggles to adapt to dynamic cyber-physical states.
20. Why use an Actor System? It prevents concurrent state mutation and isolates failures to individual agents.
21. What is a Confused Deputy? An authorized agent manipulated by a malicious input into executing an action the attacker lacks permissions for.
22. What prevents AAT forgery? Asymmetric public-key signatures (Ed25519) linking the token to a root trust anchor.
23. What is the actor\_chain? An ordered, tamper-evident array of all preceding identities in a delegation graph4.
24. How does PEDIGREE enhance SPIFFE? It adds monotonic scope attenuation and operator-controlled ceilings to standard workload identity1.
25. Why use JSON Canonicalization Scheme (JCS)? To ensure JSON payloads have a deterministic byte representation for stable cryptographic hashing6.
26. What role does a Verifier play? It provides read-only cross-checking of restored or modified states against cryptographic hashes.
27. What is context rot? The degradation of an LLM's reasoning capability as the input context window grows excessively large17.
28. How are manual approvals integrated? Via Delegation Receipts (DRP) containing human-signed Authorization Objects evaluated before execution12.
29. What defines a Failure-Closed state? The system defaults to a halt (blocking execution) when inputs, signatures, or consensus cannot be validated10.
30. What is the primary function of the Preserver? Collecting and moving volatile evidence into Write-Once-Read-Many (WORM) storage.
18. 30 Page Concepts
\[Label: institutional analysis\]
1. Capabilities vs. ACLs: Why token-based capabilities scale better for agents than Access Control Lists.
2. Macaroons: The conceptual precursor to modern AATs using HMAC chaining18.
3. Monotonic Attenuation: The mathematical principle of non-expanding privilege3.
4. Fail-Closed State Machines: Designing systems that fail securely upon consensus breakdown.
5. Agent Identity (SPIFFE/WIMSE): Identifying the software workload cryptographically1.
6. Agent Authority (OAuth/AAT): Scoping what the software can do via unforgeable tokens6.
7. Semantic Drift: The divergence of meaning across agent ontologies8.
8. Context Rot: LLM degradation in long-horizon tasks17.
9. Delegation Receipts (DRP): Cryptographic proof of human-in-the-loop consent12.
10. Succession Receipts: Proving authority handoffs between agents13.
11. Refusal Transparency: Verifiable evidence of blocked malicious actions11.
12. Confused Deputy Problem: When malicious instructions hijack legitimate agent authority.
13. Sybil Attacks in Multi-Agent Systems: Spoofing agents to manipulate consensus.
14. Blackboard Pattern: Shared semantic memory for multi-agent systems.
15. Actor Systems for AI: Message-passing isolation for LLM agents.
16. Token Fatigue: Inference exhaustion in recursive ReAct loops28.
17. Inference Gateway Budgeting: Enforcing token limits before LLM generation25.
18. Proof of Possession (DPoP): Binding tokens to a specific agent's ephemeral private key6.
19. Rich Authorization Requests (RAR): Expressing complex, granular tool constraints in OAuth3.
20. PEDIGREE Framework: Dual-layer verifiable delegation identity1.
21. Actor Chains: Tamper-evident lineage of delegation, replacing nested act claims4.
22. Zero-Trust for AI Agents: Removing ambient authority from workloads.
23. Conflict Resolution Protocols: Algorithmic mediation of semantic disagreement via the Resolver.
24. Cybersecurity Incident Roles: Structuring incident command into 9 specialized domains.
25. WORM Storage for Forensics: Write-Once-Read-Many data preservation by the Preserver agent.
26. Cryptographic DoS: Resource exhaustion via signature verification flooding.
27. Clock-Skew Attacks: Manipulating token expiry via time desynchronization.
28. K-Anonymity in AI Reporting: Preserving privacy in external agent outputs.
29. Formal Verification of Capabilities: Proving attenuation bounds using Z3/Alloy35.
30. EU AI Act Article 50 Compliance: Provenance and tracking for algorithmic actions5.
Works cited
1. draft-rampalli-pedigree-00 \- PEDIGREE: Verifiable Delegation Identity for Agentic AI Systems \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-rampalli-pedigree/
2. TBAC: Task-Based Access Control for AI Agents \- Truefoundry, https://www.truefoundry.com/blog/tbac-task-based-access-control-ai-agents
3. draft-niyikiza-oauth-attenuating-agent-tokens-01 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-niyikiza-oauth-attenuating-agent-tokens-01
4. draft-mw-spice-actor-chain-00 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-mw-spice-actor-chain-00
5. Pedigree for IBM Bob Hackathon \- Lablab.ai, https://lablab.ai/ai-hackathons/ibm-bob-hackathon/ctrlcats/pedigree
6. draft-niyikiza-oauth-attenuating-agent-tokens-00 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-niyikiza-oauth-attenuating-agent-tokens-00
7. draft-niyikiza-oauth-attenuating-agent-tokens-01 \- Attenuating Authorization Tokens for Agentic Delegation Chains \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenuating-agent-tokens/
8. LLM Data Reconciliation: Catching Silent Data Drift \- ScriptsHub Technologies, https://scriptshub.net/resources/blogs/llm-cross-system-data-reconciliation/
9. Alignment as an Ontological Property in AI Systems, https://cognitivealignmentscience.com/alignment-as-an-ontological-property/
10. Your "100 Requests per Second" Rate Limiter Might Actually Allow, https://www.bhupeshkumar.blog/blogs/100-rps-rate-limiter-might-allow-1000
11. Refusal Transparency: Signed, Replay-Resistant Evidence of Refused Agent-System Transitions \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-sabey-refusal-transparency/02/
12. Delegation Receipt Protocol for AI Agent Authorization \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-nelson-agent-delegation-receipts/10/
13. draft-sabey-succession-receipts-02 \- Succession Receipts: Portable Signed Evidence of Authority Succession Between Autonomous Agents \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-sabey-succession-receipts/02/
14. draft-sabey-succession-receipts-00 \- Succession Receipts: Portable Signed Evidence of Authority Succession Between Autonomous Agents \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-sabey-succession-receipts/
15. Multi-Agent Collaboration for Automated Cybersecurity Incident Investigation, https://www.researchgate.net/publication/412112551\_Multi-Agent\_Collaboration\_for\_Automated\_Cybersecurity\_Incident\_Investigation
16. Multi-Agent Collaboration in Incident Response with Large Language Models \- arXiv, https://arxiv.org/html/2412.00652v2
17. Recursive Language Models for Long Context Reasoning \- Emergent Mind, https://www.emergentmind.com/papers/2512.24601
18. A Child's Garden of Inter-Service Authentication Schemes | Latacora, https://www.latacora.com/blog/2018/06/12/a-childs-garden/
19. Cryptographic Security of Macaroon Authorization Credentials \- NYU Computer Science department, https://cs.nyu.edu/media/publications/TR2013-962.pdf
20. Biscuit, the foundation for your authorization systems \- Clever Cloud, https://www.clever.cloud/blog/engineering/2021/04/12/introduction-to-biscuit/
21. AI agents and the multi-hop delegation problem \- WorkOS, https://workos.com/blog/oauth-multi-hop-delegation-ai-agents
22. Succession Receipts: Portable Signed Evidence of Authority Succession Between Autonomous Agents \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-sabey-succession-receipts-00
23. 19th Conference of the European Chapter of the Association for Computational Linguistics, https://aclanthology.org/events/eacl-2026/
24. Local Delegated Agent Identity Architecture \- GitHub Pages, https://1password.github.io/agent-identity-specs/draft-1password-agent-identity-local-delegated.html
25. LLM Operations Architecture: Runtime Governance for Production AI Systems \- Rack2Cloud, https://www.rack2cloud.com/llm-ops-model-deployment-strategy-guide/
26. draft-sweeney-wimse-credential-delegation-00 \- Credential Delegation Protocol for AI Agents in Multi-System Environments \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-sweeney-wimse-credential-delegation/
27. Inside the Scaffold: A Source-Code Taxonomy of Coding Agent Architectures \- arXiv, https://arxiv.org/html/2604.03515v2
28. Welcome\! Let's get to know each other \- Agents \- Google Developer forums, https://discuss.google.dev/t/welcome-lets-get-to-know-each-other/243361
29. Toward Scalable LLM-Based Multi-Agent Collaboration: A Dynamic Task Graph Approach with Asynchronous Parallel Execution \- MDPI, https://www.mdpi.com/2079-9292/15/11/2475
30. OpsAgent: An Evolving Multi-agent System for Incident Management in Microservices \- arXiv, https://arxiv.org/html/2510.24145v3
31. GitHub \- LLMSecurity/awesome-agent-skills-security, https://github.com/LLMSecurity/awesome-agent-skills-security
32. Semantic Drift in Bug Resolution: How Behavioral Signals Propagate from Reports to Tests and Patches \- arXiv, https://arxiv.org/html/2607.18550v1
33. Infostructure: A Scoping Review and Reference Architectural Framework for Situation Awareness in Future Power System Control Rooms \- MDPI, https://www.mdpi.com/1996-1073/19/6/1472
34. Verify an Authorization Receipt — A Guide for Auditors \- EMILIA Protocol, https://www.emiliaprotocol.ai/auditors
35. GitHub \- tenuo-ai/tenuo: High-performance capability authorization engine for AI agents. Cryptographically attenuated warrants, task-scoped authority, verifiable offline. Rust core., https://github.com/tenuo-ai/tenuo