Spherity Research · Executive Brief and Two-Paper Series
AI Agent Revocation and Containment in Multi-Agent Systems
Revocation and Containment in AI Agent Networks — an executive brief and two technical papers on trusted execution across companies
Browse this paper
In brief
What does this research establish?
This series addresses revocation and status propagation in multi-agent systems (MAS), not the design of a complete wallet or self-sovereign identity (SSI) architecture. The receiving resource must reevaluate authority and assurance for the exact operation, enforce freshness at its last preventable effect, and retain unresolved remote work until a valid terminal outcome. The papers develop this revocation and containment architecture using finite protocol models and synthetic workloads; they do not establish production stopping times or universal privacy and safety guarantees.
Key takeaways
- Authority withdrawal, status delivery, local installation and resource enforcement are different events.
- A renewed lease cannot make old authoritative evidence fresh, and a timeout does not prove remote cancellation.
- Evaluate status privacy, containment and lost legitimate work separately; faster lookup alone is not safer execution.
Start with the executive brief
Executive brief · PDFRevocation and Containment in AI Agent Networks. A 16-page leadership and engineering guide, prepared 11 October 2026.
Read the technical papers
Paper 1 — trust architecture: 76 pages. Paper 2 — protocol verification and evaluation: 73 pages. Both prepared 10 October 2026. All three documents are open access under CC BY 4.0.
Executive brief: from revoked credentials to controlled effects
An AI agent can lose permission while its requests are still queued, its evidence is cached or its work is executing in another company. Revocation is therefore an end-to-end execution-control problem, not simply a credential-status lookup. The receiving organisation must verify mandate and assurance for the same complete operation, enforce current dependencies at the last preventable effect and keep unresolved remote work visible until a valid outcome is known.
This Spherity Research series connects verifiable authority, protected execution, finite freshness limits, credential-status privacy and cascading-failure analysis. The executive brief translates the two technical papers into implementation choices for enterprise AI leaders, identity architects and industrial data-sharing teams. The results combine conditional arguments, finite models and synthetic experiments; deployment performance and software conformance require separate evidence.
Research scope: the papers focus on revocation and status propagation in multi-agent systems (MAS)—how authority withdrawals and status changes reach receiving domains and constrain further execution. They do not design a complete wallet or self-sovereign identity (SSI) architecture. Wallets, organisational identity and verifiable credentials appear as context and integration points for the revocation and containment mechanisms.
Leadership priority: qualify one receiving resource and its cancellation path before expanding an agent network. Measure prohibited effects, legitimate work lost and unresolved operations separately.
Keywords: AI agent revocation; runtime revocation; status propagation; multi-agent systems (MAS); bounded containment; verifiable authority; credential-status privacy; cascading trust failures; Trusted AI
Two complementary papers: trust architecture, then protocol evidence
Paper 1 — Cascading Trust Failures in AI Agent Networks
A Trust Architecture for Scalable Revocation and Bounded Containment develops the design principles, conditional bounds and practical trade-offs. It connects authority, status, protected execution and dependency processing to privacy and expected cascade harm. Read it to understand why stopping conditions depend on receiver control, trustworthy freshness and supported service capacity, rather than a particular hosting technology. Download Paper 1.
Paper 2 — Runtime Revocation in Multi-Agent Systems
Protocol Verification and Evaluation of Privacy and Containment turns the architecture into protected-protocol models, failure tests and implementation obligations. It examines withdrawal/commit races, parent-age limits on lease renewal, durable remote-operation accounting, privacy observers and synthetic fault comparisons. Read it to understand which controls must survive concurrency, retries, partitions and overload, and what the reported tests do and do not establish. Download Paper 2.
Recommended reading order: executive brief → Paper 1 (architecture, Article A in the brief) → Paper 2 (runtime verification, Article B in the brief). This is a new two-paper study, complementary to the separate Spherity AI Safety three-paper series.
1. Multi-issuer agent networks: coordination is not authority
In a cross-company multi-agent system, one issuer may establish legal-entity identity, another an employee’s representation authority, and another a tool’s assurance evidence. A receiving company must decide which sources it recognises, for which claims and scope. A valid signature authenticates a statement; it does not make the statement true or grant unlimited reliance.
Use case: engineering collaboration. An engineering agent asks a supplier to run a simulation, then proposes releasing a design file to a named subcontractor. The supplier’s approval does not authorise the subcontractor’s next action or the original company’s later disclosure. Each receiving resource evaluates its own complete operation: action, duration, continuation and context, including payload, audience and evidence versions. These are the engineering-file workflows used to motivate the research—not evidence of tested physical-robot stopping behaviour.
Monitoring agents are not depicted in the figures
The five figures focus on revocation, status propagation and controlled execution. Monitoring agents or services that observe authority and evidence changes—including behavioural drift detection—are not depicted. In an implementation, such monitors can trigger revocation, suspension or another status change when explicitly authorised by the relevant issuer or governance policy; otherwise they raise a signal for an authorised decision.
An observed anomaly is not automatically proof that a credential is invalid. The monitor’s evidence, decision rights and escalation rules must be defined. Detection, publication of the resulting status and enforcement at the receiving resource are separate steps. The diagrams do not establish a particular detector’s accuracy, false-positive rate or response time.
The diagram is read as a network of repeated protected boundaries. A and B identify authority/evidence and distribution roles; C identifies a relying and executing domain. One organisation can perform several roles, and a network can contain many instances of each. An agent-to-agent message does not itself transfer permission to execute. Explicit delegation must still be accepted and checked by the receiving domain for scope, audience, expiry and current status.
2. Runtime revocation at the receiving resource
The three-domain model separates the source of a claim from its delivery and from the party that controls the effect. A status service can deliver an authenticated withdrawal without becoming a general decision authority. The resource owner retains its own policy decision point (PDP) and policy enforcement point (PEP).
Three rules turn that separation into an execution contract:
- Bind mandate and assurance to the same record. Permission for one recipient cannot be combined with assurance for a different payload or continuation. A changed immutable record may need new admission.
- Check at the last preventable effect. Once a relevant withdrawal is installed locally, the final dependency and expiry checks must exclude the old supporting evidence before commit. An alternative valid evidence set may still justify the action; blanket rejection of every dependent action is not always correct. Withdrawals still in transit are a separate freshness case.
- Preserve authoritative age and pending work. A recent fetch or new wrapper signature does not refresh the source’s completeness watermark. Child leases cannot extend the parent evidence’s age cap. Keep a stable logical operation identifier and unresolved accounting across retries and restarts until authenticated execution or cancellation evidence closes the operation.
For example, if the receiver released a file but its receipt was lost, a timeout does not make the exposure disappear. Durable receiver outcomes and cancellation records are needed to prevent retries from causing an additional effect. The research’s at-most-once result depends on the receiver’s qualified atomicity and recovery contract; a sender-side database alone is insufficient.
3. Credential-status privacy: distinguish local checks, decoys and masks
Both signed mirrors and ledger-backed replicas can support authenticated local status checks without contacting a status endpoint for every decision. That can reduce one tracking channel, provided refreshes and telemetry do not disclose the activity. It does not by itself hide a credential’s stable status handle or every communication pattern.
The proposed decoy and initial-mask profiles address different questions. Decoys reserve positions that do not represent credentials and create cover transitions. Their privacy argument requires genuine and decoy histories to match under the declared observer—including incident shocks, timing, writers, batching and later side information. Matching only average transition rates is not enough.
Random appearance is not a privacy guarantee. If the public initial state is known to be active, it reveals the fixed mask used in this model. The runtime study therefore compares matched histories with and without masking. Random masks also reduce the compression advantage of sparse bitstrings. Byte fixtures measure representation cost, not network latency, safety or anonymity.
AnonCreds offers a different mechanism: proving non-revocation without revealing the revocation index. Such proofs still need binding to the accepted registry state, challenge, audience and operation. They do not make an old authoritative state fresh. The series does not supply an accumulator-performance benchmark, and treats the proposed masked and unissued-decoy profiles as experimental.
4. Bounded containment and cascading trust failures
An agent can influence another agent before either is stopped. The architecture relates conditional propagation and harm assumptions to detection and post-detection influence windows. Shorter supported windows can improve the conditional expected-harm bound, but a measured average delay cannot be substituted for a guaranteed influence limit.
The illustration shows why capacity is part of trust infrastructure: status distribution is not enough if withdrawal processing waits behind unbounded work. Reserved service, bounded job size and backlog, and a separately supported restrictive fallback are needed to justify an enforcement deadline.
The bound is expected harm under stated assumptions, not the maximum loss in every incident. Continuing external failures can add new roots even when secondary propagation is subcritical. If the subcritical certificate is unavailable, that does not prove infinite damage. A file-release gate also cannot contain an agent-messaging channel it does not control.
5. Integrating revocation into trust and execution infrastructure
This revocation-focused view connects organisational identity and agent mandates with assurance evidence, credential status, local relying policy and durable operation accounting. It treats identity and wallet services as supporting inputs and integration points, not as a complete wallet or SSI design. Business Wallets can hold the relevant keys and evidence. Wallet possession alone, however, does not establish the holder’s mandate or the eligibility of a particular action.
Read the diagram from evidence to effect: recognise scoped issuers; validate the evidence and current status; decide eligibility for the complete record; enforce at the resource; then retain an accountable outcome or an unresolved operation. The persistent operation ledger is an accounting function and does not require blockchain.
The business objective is useful, accountable delegation across company boundaries. Explicit stopping and recovery contracts can make pilots easier to evaluate, clarify responsibility between identity, platform and resource teams, and expose trade-offs between risk reduction and service continuity. These are design benefits to test—not measured returns on investment or a production-performance claim.
6. Architecture options for status publication and proofs
No single storage or proof pattern removes the need for recognised issuers, authoritative freshness and resource-side enforcement. Table 6 from Paper 1 compares alternative publication and proof patterns; it is not a ranking of complete revocation systems. Several options can be combined, such as a Merkle root committed on-chain with proofs and snapshots served by independent mirrors.
On small screens, scroll the table horizontally to compare all three columns. Keyboard users can focus the table region and use the arrow keys.
| Pattern | Useful property | Cost and limitation |
|---|---|---|
| Complete packed state on DLT | Local authenticated status after synchronization; shared update ordering. | Writes, consensus delay, public update history and replicated state; no automatic issuer truth or freshness. |
| On-chain digest with signed mirrors or IPFS | Small commitment; large snapshots can use caches and independent replicas. | Both an accepted commitment and available matching bytes are needed. A CID alone does not retain data. |
| Merkle status map | A bit or word plus a logarithmic authentication path can prove its value under a root. | Current root, data and proof availability remain necessary. Index-revealing proofs are not anonymous proofs. |
| RSA or other accumulator | Some constructions offer compact membership or non-membership witnesses. | Witness maintenance, setup and manager assumptions vary. RSA and pairing constructions are not post-quantum. |
| L2 publication | Can amortize transactions and reduce some publication costs. | Sequencer acceptance, data availability, proof or dispute completion and L1 settlement are different conditions. |
| Participant state channel | Can amortize repeated updates among a fixed group. | Co-signature and dispute rules complicate public revocation; counterparties must not veto unilateral withdrawal. |
Source: Dr. Carsten Stöcker, Cascading Trust Failures in AI Agent Networks, Section 5.4.6, Table 6, page 21. Original table wording and numbering retained; layout adapted for the web. © 2026 Dr. Carsten Stöcker, CC BY 4.0. DLT means distributed ledger technology; IPFS is the InterPlanetary File System; CID is a content identifier; L1 and L2 mean the base chain and a layer-2 system respectively.
Ethereum and EVM smart contracts for credential-status publication
Smart-contract blockchains such as Ethereum can be an advantageous implementation option when independent organisations need programmable update controls, shared ordering and independently validated status. The Ethereum Virtual Machine (EVM) provides deterministic execution of contract state transitions. A suitably designed registry can restrict writes, enforce update rules and expose changes for reconciliation. This is a conditional architectural assessment—not a claim that blockchain is necessary, faster or more private than authenticated signed mirrors. See the Ethereum EVM documentation.
Store the bitstring itself on L1 or L2. An EVM smart contract can hold the actual packed status bitstring in persistent storage on Ethereum L1 or an EVM-compatible L2. One implementation uses an array or mapping of uint256 or bytes32 words: each word can represent 256 one-bit status entries, with authorised calls updating the relevant word. This is the table’s complete packed state on DLT pattern, not merely an on-chain hash of an off-chain bitstring. L2 deployment can be combined with this storage pattern; the two table rows are not mutually exclusive. See Solidity’s storage layout.
On an L2, the bitstring resides in that L2 contract’s state. Rollup commitments and published data connect it to Ethereum; this does not mean every expanded L2 storage word is also held directly in an L1 contract’s storage. By contrast, a digest-only design leaves the bitstring on a mirror or IPFS and stores its commitment on the chosen chain. Qualify the selected L2’s data availability, sequencer and settlement assumptions separately. See Ethereum’s rollup architecture documentation.
The paper examines a packed-status profile over the draft ERC-7506 Trusted Hint Registry. The draft supplies namespaces, 32-byte hints, delegated write permissions and change events. Packing status bits, preserving irreversible withdrawals under concurrent writes, defining suspension semantics and mapping W3C bit order remain application-profile obligations. ERC-7506 is not a final standard or a complete revocation protocol; it deliberately leaves governance to the ecosystem.
For a cross-company pilot, qualify four boundaries:
- Authority and freshness: pin the accepted chain, contract, issuer and status profile. Consensus does not establish issuer truth or guarantee that every off-chain withdrawal has been published. A block timestamp is not an authoritative completeness watermark. Smart contracts need an authorised input path for external facts; they do not independently detect behavioural drift. See Ethereum’s smart-contract limitations.
- Timing and cost: distinguish submission, inclusion, accepted or finalized state, local installation and enforcement. Include transaction fees, capacity, reorganisation policy and node operation in the design. EVM compatibility alone does not establish a network’s consensus or finality guarantees.
- Privacy: public state, logs, writer activity and timing can disclose information. Permissioned writes do not make public-chain data confidential. Local reads remove a lookup channel only under the stated observation assumptions.
- Delivery and containment: change events are notifications, not proof of receipt or execution control. Recover from disconnects and missed events using checkpointed reconciliation and reorganisation handling; keep freshness limits and the final resource gate independent of a live subscription. Geth’s event documentation explains these delivery limitations.
Selection rule: choose Ethereum/EVM where shared programmable state justifies these costs and operational responsibilities. Use signed mirrors, commitments or another pattern where they meet the same verified requirements more simply. The publication layer does not replace the protected receiving boundary, and the papers remain a study of MAS revocation and status propagation—not a full wallet or SSI architecture.
Evidence, standards and the limits of the results
The executive brief separates four evidence classes:
- Conditional mathematics: eligibility, privacy, stopping, accounting and expected-harm arguments depend on their stated authority, timing, mediation and observation assumptions.
- Finite protocol exploration: the runtime study reports 477 states for one operation and 6,651 for two, with no monitored baseline violation. Removing key controls yields short counterexamples. This is a small abstraction, not verification of a deployed distributed system.
- Synthetic experiments: 6,144 model incidents and 5,000 privacy cohorts exercise stipulated conditions. They do not measure a live agent platform, mirror service or ledger.
- Reproducible calculations: byte fixtures and model charts make assumptions inspectable; real hardware calibration, full wire conformance and implementation mapping remain separate tasks.
The following primary sources support the standards context. They do not certify the proposed architecture:
| Standard or specification | Role and implementation boundary |
|---|---|
| NIST SP 800-207: Zero Trust Architecture | Resource-focused policy decision and enforcement. The papers add explicit freshness and remote-operation obligations for their agent workflows. |
| W3C Bitstring Status List v1.0 | Recommendation baseline for publishing credential status. Pin encoding, purpose, authority and version; do not present experimental masking as standard conformance. |
| OpenID Shared Signals Framework 1.0 and CAEP 1.0 | Authenticated security-event transport and an access-evaluation profile. Event receipt is not proof of resource-side enforcement or an execution lease. |
| AnonCreds specification | The v1.0 draft describes anonymous credential and non-revocation proof mechanisms. Hidden indices still require freshness, proof binding and an enforceable invalidation strategy. |
| NIST FIPS 204: ML-DSA | Post-quantum digital signatures. Upgrading object signatures alone does not upgrade transport, proof systems or ledger consensus. |
The PDFs also review emerging W3C drafts and a proposed packed profile over the draft ERC-7506 Trusted Hint Registry. Those proposals must be distinguished from the stable baseline and require their own conformance and failure testing.
Start with one receiver, one effect and explicit acceptance tests
For an initial pilot, use a named engineering-file release, ordinary unmasked credential status, authenticated snapshots and full evidence reevaluation. Add dependency-index optimisations, alternative hosting or privacy profiles only when they preserve the reference decision and execution boundary.
- Security architecture: pin issuers, algorithms, status purpose, bit order, epoch and decoding limits; reject ambiguous or oversized inputs within bounded work.
- Resource team: mutate payload and recipient after admission; install withdrawals before and after commit; prove that queues and alternative APIs cannot bypass the final gate.
- Trust infrastructure team: drop, duplicate and reorder updates; partition all freshness paths; test expiry and restart without extending authoritative age.
- Receiver and storage teams: crash both sides, retry requests and lose receipts; retain pending operations and durable cancellation outcomes.
- Platform operations: inject bursts, verify the reserved-service assumptions and test the restrictive fallback. Report prohibited effects, legitimate deadline loss and unresolved operations separately.
Call to action: select a cross-company workflow with an identifiable resource owner, agree the last preventable effect and acceptable evidence age, and independently test the stop, cancellation and recovery paths before scaling. The author is Spherity’s founder; independent implementations and review are important to assessing deployment relevance.
Research sources and citations
- Stöcker, Carsten (2026-10-11). Revocation and Containment in AI Agent Networks: Executive Brief and Engineering Implementation Guide. Spherity GmbH. Executive Brief PDF. CC BY 4.0.
- Stöcker, Carsten (2026-10-10). Cascading Trust Failures in AI Agent Networks: A Trust Architecture for Scalable Revocation and Bounded Containment. Spherity GmbH. Paper 1 PDF. CC BY 4.0.
- Stöcker, Carsten (2026-10-10). Runtime Revocation in Multi-Agent Systems: Protocol Verification and Evaluation of Privacy and Containment. Spherity GmbH. Paper 2 PDF. CC BY 4.0.
Figure explanations follow the executive brief, Sections 3–4, 6 and 10, and the architecture paper’s Figure 1. The original filenames are retained so download references remain faithful to the supplied editions. © 2026 Dr. Carsten Stöcker. Reuse is permitted under CC BY 4.0 with attribution, a licence link and an indication of changes, except where otherwise noted.
Open research
License and citation
This research page, the executive brief, both technical papers and the five attributed research figures, except where otherwise noted is licensed by its named author under the Creative Commons Attribution 4.0 International License (CC BY 4.0). Reuse must credit every named author, link to this canonical version and the license, and indicate whether changes were made.
How to cite this work
Dr. Carsten Stöcker (2026-10-11). “AI Agent Revocation and Containment in Multi-Agent Systems: Revocation and Containment in AI Agent Networks — an executive brief and two technical papers on trusted execution across companies.” Spherity GmbH. https://spherity.github.io/spherity-research/ai-agent-revocation-containment-multi-agent-systems.html. Licensed CC BY 4.0.
Direct answers
Questions this research answers
Do these papers design a complete wallet or SSI architecture?
No. The series focuses on revocation and status propagation in multi-agent systems (MAS): how authority withdrawals and status changes reach receiving domains, affect local decisions and constrain further execution. Wallets, organisational identity and verifiable credentials provide context and integration points. The papers do not specify a complete wallet or self-sovereign identity (SSI) architecture.
What is AI agent runtime revocation?
Runtime revocation is the withdrawal of authority or supporting evidence while an AI workflow is active. The receiving resource stops unsupported effects after installing the withdrawal, or when required authoritative evidence exceeds its accepted age or validity limit even if no update arrives. Publishing a status change alone does not stop queued or remote work.
What is the difference between revocation and containment?
Revocation withdraws a previously accepted basis for action. Containment limits further effects, including work already dispatched to other systems. It requires protected resource gates, enforceable freshness limits and durable accounting until execution or cancellation is established. Neither control can undo an irreversible disclosure that has already occurred.
Where are the monitoring agents that detect behavioural drift or changed authority?
They are not depicted in the five figures. Monitoring agents or services can observe authority and evidence changes, including behavioural drift, and trigger revocation or another status change when explicitly authorised by the relevant issuer or governance policy. Otherwise they raise a signal for an authorised decision. Detection, status publication and resource-side enforcement remain distinct; the figures do not validate a particular detector's accuracy or latency.
Can Ethereum and EVM smart contracts support AI agent revocation?
Yes. The actual status bitstring can be stored in an EVM smart contract on Ethereum L1 or an EVM-compatible L2, for example as packed 256-bit words. This differs from storing only a digest or Merkle root while keeping the bitstring off-chain. Programmable write controls, shared update ordering and independently validated state can be advantageous across organisations. The draft ERC-7506 Trusted Hint Registry is one possible interface, not a requirement or a complete revocation protocol. Gas, finality, data availability, public history and recovery from missed events require evaluation. Neither Ethereum nor EVM compatibility automatically establishes issuer truth, evidence freshness, confidentiality or stopping at an off-chain resource.
Why must mandate and assurance apply to the same operation?
Permission for one action and assurance for a different continuation do not jointly justify execution. Both must cover the same action, duration, continuation and context, including the recipient, resource, payload and bound evidence versions. Changing these elements can require a newly admitted operation.
What happens when credential-status updates are unavailable?
A receiver may rely on authenticated local state only within its accepted source-age and validity limits. Freshness is measured from authoritative completeness, not the last download. At the strict expiry limit, affected ordinary effects stop; separately authorised containment and recovery may continue. Stale or missing state is unknown, not proof that a credential was revoked.
Why is a timeout not proof that an AI agent's remote operation was cancelled?
The receiver may have executed the operation even if its receipt was lost. Keep the stable operation identity and unresolved exposure through retries, crashes and agent replacement. Close the record only on authenticated, contract-valid terminal evidence; a cancellation request or transport acknowledgement is insufficient.
Do decoys, random masks or blockchain guarantee credential-status privacy?
No. Resident local checks can remove per-decision status requests on both mirror and ledger paths. Matched decoys require matching complete observable histories, including incidents and metadata. A fixed mask adds no membership protection when known-active initialization reveals it. Anonymous status proofs can hide a status handle, but their freshness, metadata and recovery costs still need evaluation.
What has this research demonstrated, and what remains to be tested?
The series provides conditional mathematical results, finite protocol exploration, deterministic byte fixtures and synthetic revocation and privacy experiments. It does not benchmark a production agent network, certify complete software conformance or demonstrate universal containment. Receiver implementation, realistic timing, continuous issuance privacy and independently calibrated harm assumptions remain to be validated.