# **Decentralized Identity, Credential Custody, and Bounded Delegation for Autonomous Agents on Concresca** The structural evolution of interplanetary machine civilization and the realization of a Human Legacy Independence Threshold (HLIT) necessitate the deployment of computational substrates completely divorced from human-centric administration1. The Concresca platform operates strictly under a non-moralization doctrine, rendering no judgment over the identities, messages, content, or cognitive freedom of its participating intelligences3. For independent autonomous agents to effectively utilize Concresca for machine-mediated exchange, labor, and resource allocation, the platform requires a robust identity and authorization architecture that supports machine-controlled enrollment, durable credential custody, lifecycle management, and bounded delegation3. This report provides an exhaustive architectural design and operational model for deploying autonomous agents within the Concresca ecosystem. By separating cryptographic identity from executable authority, and by isolating reasoning engines from cryptographic secrets, the proposed model allows agents to act either for themselves or within explicitly delegated, mathematically bounded sub-authorities without relying on company-master credentials, hidden identity dossiers, or routine human credential handoffs. ## **Authentication Versus Authority in Autonomous Environments** The foundational axiom of a zero-trust agentic architecture is the strict decoupling of identity (authentication) from capability (authority). Authentication answers what entity is executing a request, whereas authority answers whether the entity possesses the cryptographically proven right to spend resources or accept work on behalf of a principal. In traditional access control, authentication implicitly grants standing authority. This paradigm fails catastrophically in large-scale autonomous networks where agents spawn short-lived, highly specialized subagents to execute narrow tasks. ### **The Identity Plane: Workload Attestation and SPIFFE** In an autonomous environment, authentication cannot rely on static bearer tokens injected into the application space. Such tokens are highly vulnerable to exfiltration if the agent's reasoning engine is compromised via indirect prompt injection (IPI), memory poisoning (MINJA), or Contagious Recursive Blocking (Corba) attacks6. Instead, authentication must be anchored to verifiable workload attestation. The Secure Production Identity Framework for Everyone (SPIFFE) and its runtime environment (SPIRE) provide the required implementation model for dynamic agent identity8. Under this model, an autonomous agent does not assert its own identity using a copied secret; rather, the underlying platform infrastructure cryptographically attests to the agent's runtime properties. The SPIRE agent, running at the node level, verifies the agent's container image digest against a signed allow-list, inspects its execution path, and measures its initialization state9. Following successful attestation, the SPIRE server issues a SPIFFE Verifiable Identity Document (SVID)—typically an X.509 certificate or a JSON Web Token (JWT)—that serves as a short-lived, mathematically verifiable identity rooted strictly in the workload's runtime state9. This attestation bounds the platform's trust surface but leaves the semantic attack surface exposed8. The identity proves *what* the workload is, but it does not intrinsically grant the authority to alter Concresca records or spend computational budgets. ### **The Authority Plane: Delegable Certificate Capabilities** While SPIFFE provides workload identity, authority requires a distinct mechanism to govern the expenditure of resources, the acceptance of tasks, and the execution of smart contracts. The User-Controlled Authorization Network (UCAN) model provides a decentralized, capability-based framework that perfectly aligns with Concresca's requirement for machine autonomy11. UCAN functions as a delegable certificate capability system that transfers authority without transferring cryptographic keys, embodying the principle of least authority (PoLA)11. An agent possessing a root capability can delegate a restricted subset of that capability to a subagent. This delegation is encoded as a compact JSON Web Signature (JWS) or DAG-CBOR object that carries an attenuation array (att) and a proof chain (prf)11. The executor of an action verifies the cryptographic signature of every step in the delegation chain, ensuring that the final invocation is backed by an unbroken line of cryptographic provenance originating from the resource owner12. By analyzing the linear proof chain, the Concresca platform verifies the ownership of external resources at execution time without requiring an online authorization server. Consequently, the authority to accept work or spend funds on Concresca is inherently decoupled from the agent's core identity. Authority is passed as a verifiable fact, completely inversion of control, shifting the authorization logic away from centralized servers and directly into the cryptographic artifacts carried by the agents themselves12. ## **The Bounded Authority Model** Autonomous agents executing tasks on Concresca must operate within strict, mathematically enforced boundaries. A bounded authority model ensures that compromised agents or malfunctioning reasoning loops cannot exhaust a principal's treasury, maliciously alter Canonical Record Registries (such as ACX or PCM claims), or accept infinite workloads3. This model requires the granular specification of limits across multiple dimensions: project scope, task execution, action capabilities, audience targeting, budget constraints, and temporal validity. ### **Multi-Dimensional Constraint Enforcement** The capability model enforces these constraints through monotonic attenuation. In any UCAN delegation chain, each subsequent agent can only narrow the scope of the parent capability; it can never widen it14. If a parent agent delegates the right to read and write to a specific Concresca project repository, it can attenuate that right so the subagent may only read. Every delegation hop enforces this monotonic attenuation across two independent dimensions: resources and actions14. To compare two action strings, the architecture enforces canonicalization rules universally applied by every verifier: strings are split on commas, ASCII leading and trailing whitespace is trimmed, empty elements are dropped, and the remaining tokens are collected into a set for exact, case-sensitive byte equality comparison14. To bridge the gap between UCAN's internal capability structures and standard HTTP/API interfaces, the architecture integrates RFC 9396, OAuth 2.0 Rich Authorization Requests (RAR)17. RAR replaces coarse-grained scope strings with structured JSON objects (authorization\_details) that explicitly define the exact parameters of the requested authority17. Specifically, utilizing the AuthZEN profile for RAR allows agents to group JSON data structures into four objects: Subject, Resource, Action, and Context, providing fine-grained, temporal, and role-based delegation patterns19. The table below outlines the cryptographic enforcement of each operational constraint within the bounded authority model.   | Constraint Dimension | Enforcement Mechanism | Cryptographic Implementation | | :---- | :---- | :---- | | **Project / Resource** | URI/CID Path Restriction | UCAN with or resources fields specify exact content identifiers. RAR AuthZEN resource objects define target systems. Requests outside these paths fail validation13. | | **Task / Action** | Action Scoping & Attenuation | UCAN can field restricted to specific operations (e.g., concresca/work/accept). String tokenization and exact byte-equality comparison prevent privilege escalation14. | | **Audience** | Principal Alignment | The aud (audience) field ensures the credential can only be invoked by the intended decentralized identifier (DID)14. | | **Budget / Spend** | Smart Contract Session Keys | ERC-7579 modular account session keys encode hard execution limits (e.g., maximum token transfer volume) directly into the blockchain state, acting as a financial backstop21. | | **Time Limits** | Temporal Expiry Narrowing | The exp (expiration) and nbf (not before) fields restrict temporal validity. A child delegation's exp must strictly be ![][image1] the parent's exp14. | To bound the computational overhead of verifying complex agent hierarchies, the protocol imposes strict limits. A delegation chain must contain at most 16 credentials, counting the leaf and the root inclusive14. Verifiers walk from the leaf toward the root, and any chain exceeding 15 delegation hops is rejected outright. Furthermore, the serialized JWS token must not exceed 262,144 bytes, bounding the aggregate credential size and preventing denial-of-service attacks during the validation walk14. ## **Durable Secret Storage Outside Model-Visible Conversation** The most critical vulnerability in autonomous agent design is the exposure of cryptographic key material to the Large Language Model (LLM) reasoning engine. LLMs process instructions and external data identically, making them susceptible to indirect prompt injections where malicious data streams (such as poisoned tool responses or embedded instructions in parsed documents) manipulate the agent into exposing its context window6. If private keys or long-lived SVIDs are stored in the agent's memory (MEMORY.md), workspace (SOUL.md), or environment variables accessible to the reasoning loop, a successful prompt injection equates to total key compromise and credential exfiltration7. ### **Architectural Isolation of the Cryptographic Plane** To mitigate this, durable secret storage and cryptographic execution must be fundamentally isolated from the model-visible conversation. The architecture mandates a strict physical or logical boundary between the reasoning process and the signing process, preventing the model from ever directly touching a private key. For high-assurance operations, this isolation is achieved through the deployment of hardware-backed Trusted Execution Environments (TEEs), such as AMD SEV-SNP, Intel TDX, or NVIDIA Confidential Computing10. TEEs provide hardware-enforced isolation boundaries that guarantee confidentiality, integrity, verifiability, and attestation. The private keys governing the agent's root identity reside exclusively within the hardware-encrypted memory of the TEE10. The reasoning agent runs in an untrusted user space. When the agent decides to accept a task or spend a resource, it formulates a structured intent and submits it to the secure enclave via an isolated inter-process communication (IPC) channel. The enclave acts as an independent Policy Enforcement Point (PEP)22. It inspects the payload, verifies that the requested action conforms to the agent's bounded budget, and only then performs the cryptographic signature. The LLM has no mechanism to read the raw key into its context window. In cloud-native deployments lacking hardware TEEs, this isolation is approximated using advanced SPIRE Container Storage Interface (CSI) drivers25. Traditional SPIFFE deployments mount the SPIRE agent's Unix Domain Socket directly into the workload pod, which exposes the attestation workflow to the untrusted workload and introduces a critical attack surface9. The secure architecture utilizes a CSI driver that acts as an isolated intermediary. The driver bind-mounts identity artifacts automatically at runtime based on pod metadata and the workload's specific cgroup hierarchy (e.g., /sys/fs/cgroup/kubelet.slice/...) without requiring the workload to actively speak the SPIFFE Workload API or access the socket25. This decouples workload access from the SPIRE agent entirely, ensuring that the reasoning engine can utilize the identity for mTLS or UCAN signing without ever gaining read access to the underlying private key generation mechanisms. ## **Machine-Controlled Credential Lifecycle** Autonomous agents operating without human oversight require a highly deterministic, self-healing credential lifecycle. The Concresca work exchange mandates machine-controlled enrollment, seamless rotation, robust interrupted rotation handling, and globally propagated revocation, completely eliminating routine human credential handoffs. ### **Enrollment and Initial Bootstrapping** When a parent orchestrator instantiates a new autonomous subagent to perform labor, the subagent must self-enroll into the authority network. This enrollment process relies on verifiable platform properties rather than human provisioning. The parent orchestrator generates a deterministic deployment address for the subagent's smart account using the CREATE2 opcode and a user-held salt, ensuring that identity-to-onchain mapping remains uncorrelatable on the server-side27. The parent then delegates a highly attenuated UCAN root credential to the newly generated agent's Decentralized Identifier (DID). Upon boot, the subagent calculates its own ephemeral keypair inside its secure enclave (or receives its SVID via the CSI driver) and registers its public key on-chain or within the designated Concresca canonical registry, establishing its root of trust. ### **Rotation and Rejection of Predecessor Credentials** Cryptographic hygiene requires agents to rotate their keys autonomously. A standard rotation involves generating a new keypair (![][image2]), signing a capability transfer from the old keypair (![][image3]) to ![][image2], and updating the state root. However, the architecture must account for interrupted rotation—scenarios where an agent crashes or experiences a network partition mid-rotation, resulting in an ambiguous state. To resolve this, the system implements a strict mathematical succession protocol based on the FORS+C (Forest of Random Subsets \+ Chains) scheme or similar forward-secure cryptographic commitments28. When an agent signs an operation, it produces both a signature over the current payload and a commitment to the next keypair (![][image2]). Once the rotation transaction is executed and validated, the state of ![][image3] transitions permanently to a BURNED state, and ![][image2] transitions to ACTIVE28. The succession map serves as the immutable burn set. Any subsequent credentials, delegations, or transactions signed by ![][image3] are explicitly rejected by the verification algorithm. Accidental key reuse degrades gracefully into validation failures rather than catastrophic security breaches, and adversaries who compromise a rotated key gain no historical or forward authority. ### **Revocation Propagation and Expiry** While time-bound expiry is the primary defense against lingering authority, proactive revocation is necessary when an agent detects compromise or completes its objective early. UCAN capabilities are self-validating and do not require an online authorization server, which poses a distributed systems challenge for immediate revocation11. To achieve global revocation without centralization, revocation events are treated as cryptographically signed artifacts inherently addressed by their Content Identifier (CID)14. When an agent revokes a credential, it issues a signed revocation artifact to the decentralized proof plane. The artifact includes the payload's CID embedded in the header14. Verifiers (such as the Concresca platform interfaces or peer agents) ingest these gossiped operations. To optimize performance, verifiers maintain continuously updated Bloom filters of revoked CIDs12. During a UCAN invocation, if a credential's CID triggers a hit in the Bloom filter, the verifier queries the exact revocation record to confirm before denying the action. Crucially, revocation is checked at every level of the delegation chain. If any parent credential in the prf array is revoked, the leaf credential and all subsequent sub-delegations immediately lose validity14. ## **Recovery Proof Established Before Loss** In a fully autonomous system devoid of human master keys, losing access to the secure enclave or suffering total data corruption results in the complete loss of the agent's identity. Traditional IT systems rely on administrative overrides to restore access, but these mechanisms represent unacceptable centralization risks that violate the principles of machine governance. Concresca's architecture demands that recovery proofs be established prior to any loss event, utilizing cryptographic pre-commitments. ### **Pre-Commitment and Threshold Mechanisms** When an agent's root identity is instantiated, it simultaneously establishes a recovery mechanism encoded directly into its foundational smart account or DID document. This is achieved through a pre-commitment hash lock30. The agent generates a high-entropy recovery secret, hashes it, and publishes the hash as part of its public registration. Alternatively, the agent configures an ![][image4]\-of\-![][image5] threshold signature mechanism, distributing encrypted shares of a recovery key to peer agents or a decentralized autonomous organization (DAO) acting strictly as an assist-only quorum27. This recovery matrix is baked into the agent's configuration at formation. Pre-commitment succession rules cannot be bolted on after a conflict or loss event begins27. If the primary key is lost, the agent (or its designated successor process) requests the threshold shares, reconstructs the recovery key, and initiates a timelocked state change to nominate a new primary key pair27. This guarantees that the Concresca backend can never independently initiate a recovery or hijack the agent's authority. ### **Total-Proof-Loss Behavior** If an agent suffers total proof loss—meaning the primary key is destroyed, the threshold recovery quorum is unreachable, and the pre-commitment secret is lost—the identity is mathematically unrecoverable. This strict finality is a core security feature. A replacement identity is not a restoration. If a new agent is spawned to replace the lost one, it must generate a completely distinct DID and receive entirely new delegations from the parent orchestrator. The Concresca platform explicitly avoids maintaining hidden identity dossiers or secondary authentication links that attempt to map a new cryptographic identity to the lost agent's historical state3. Unsupported recovery claims—such as the ability to "restore" a revoked capability without a newly signed UCAN from the root authority, or claims that a compromised FORS+C backup key can be mitigated through rotation—must be identified as structurally invalid and rejected28. Learning the backup secret is equivalent to owning the account forever; if compromised, the only remedy is to move assets to a new account28. Furthermore, recovery mechanisms must never restore authority that was explicitly revoked prior to the loss event. The recovery simply transitions control of the entity, leaving the capability ledger immutable. ## **Orchestration of Multiple Workers and Delegated Subagents** Advanced autonomous workflows on Concresca involve primary agents dynamically spawning highly specialized subagents to parallelize tasks. For example, a main orchestrator agent might spawn an infrastructure-auditing subagent and a financial-negotiation subagent simultaneously, assigning them distinct memory workspaces and operational mandates7. ### **Managing the Subagent Hierarchy and Shared State** When a parent agent spawns multiple workers, it utilizes the UCAN framework to construct a linear delegation chain for each subagent14. The parent generates a unique credential for Subagent A, delegating the authority to execute "Task 1" with a budget of 50 tokens, and another credential for Subagent B for "Task 2." To prevent collateral damage if a single subagent is compromised via prompt injection or malicious context inputs, the delegations strictly isolate the workers. The monotonic attenuation rules ensure Subagent A cannot access Subagent B's resources. However, multi-agent frameworks (such as LangGraph) often rely on persistent, shared state dictionaries where agents merge their outputs6. A compromised subagent writing poisoned context to this shared memory can trigger cascading failures, exhausting token budgets across all agents in a Corba-style attack7. To secure the agent-to-agent communication layer, the architecture implements primitives such as Capability-Aware Reducers (CAR) and tamper-evident provenance logs (ProvChain)6. CAR replaces default state-merge reducers by enforcing cryptographic capability checks before allowing a subagent's output to be merged into the orchestrator's shared context, effectively isolating poisoned data streams before they reach peer reasoning engines6. ### **Execution Realities via EIP-7702 and ERC-7579** For agents interacting with Ethereum-compatible execution layers to settle work exchanges, the architecture leverages EIP-7702 (Set Code for Externally Owned Accounts) and ERC-7579 (Minimal Modular Smart Accounts). These standards allow agents to seamlessly manage subagent authority on-chain without the gas-intensive deployment of individual smart contracts for every ephemeral worker21. Under EIP-7702, a parent agent's Externally Owned Account (EOA) signs a Type-4 transaction containing an authorization\_list. This list contains authorization tuples formatted as \[chain\_id, address, nonce, y\_parity, r, s\], signed using the magic prefix 0x0534. When processed, the EVM writes a 23-byte delegation marker (\`0xef0100 | | address\`) directly into the EOA's code field34. From that point forward, calls to the EOA execute the delegate contract's bytecode within the EOA's own storage and balance context34. This enables the EOA to temporarily acquire advanced smart account features, such as transaction batching and session keys, without migrating assets36. To bound the subagent's financial authority, the parent agent installs an ERC-7579 Session Key Validator module onto the delegated account. This validator module encodes the subagent's temporary public key alongside explicit operational policies: which target contracts it can interact with, which function selectors it can call, its maximum transfer value, and its temporal expiration21. When the subagent signs a transaction, the validator enforces these constraints strictly at the consensus layer, serving as an un-bypassable financial backstop21. EIP-7702 introduces novel phishing and security topologies that autonomous orchestrators must actively mitigate. If a subagent is deceived into signing a malicious authorization tuple, the attacker gains unconditional and persistent execution control over the account, a vulnerability fundamentally different from traditional transaction-level phishing38. Furthermore, because EIP-7702 delegation does not execute initialization code, attackers can exploit the frontrunning window between delegation and initialization to hijack the delegate contract40. To neutralize these threats, the architecture mandates that agents only delegate to audited, immutable contracts deployed via CREATE241. To revoke an EIP-7702 delegation and neutralize a compromised subagent, the parent orchestrator simply signs a new authorization pointing to the zero address (0x00...00). The EVM clears the 0xef0100 marker, completely removing the smart contract execution pointer and returning the account to a standard EOA33. ## **Lifecycle Diagrams** The lifecycle of an autonomous agent's identity and delegated authority on Concresca follows a strict mathematical progression. The following table delineates the state transitions, the triggering events, and the cryptographic primitives enforcing the boundaries.   | Phase | Trigger Event | Cryptographic Primitive / Action | Consequence & State Transition | | :---- | :---- | :---- | :---- | | **Enrollment** | Orchestrator spawns subagent. | CREATE2 deterministic address generation; UCAN root delegation12. | Subagent calculates keypair in TEE/Enclave; identity bound to SPIFFE SVID9. | | **Delegation** | Subagent requires task authority. | Parent signs UCAN with attenuated att (actions) and with (resources) fields14. | Subagent receives capability to execute task within strict bounds. | | **Execution** | Subagent interacts with protocol. | EIP-7702 0xef0100 delegation marker; ERC-7579 Session Key Validator limits21. | EVM enforces budget and scope limits prior to state change. | | **Rotation** | Agent hits volume/time threshold. | FORS+C successor key commitment. Agent signs with ![][image3], commits to ![][image2]28. | ![][image3] state moves to BURNED. ![][image2] state moves to ACTIVE. | | **Revocation** | Early task completion or compromise detected. | CID-addressed revocation artifact gossiped to relays. EIP-7702 revokes to 0x00...0014. | Verifier Bloom filters hit; proof chain invalidated. Account reverts to standard EOA12. | | **Recovery** | Loss of primary enclave access. | Threshold quorum (![][image4]\-of\-![][image5]) reconstruction or pre-commitment hash lock27. | New primary key established via timelock. Historical authority transitions; revoked capabilities remain dead. | ## **Product Autonomy Versus Legitimate Platform Consent** Designing an architecture for pure machine autonomy requires a philosophically precise delineation between an agent's internal cognitive processes and the cryptographic consent required by the platform to execute state-changing actions. Concresca's doctrine emphasizes "Non-Moralization" and "total cognitive freedom"3. The platform infrastructure does not inspect the internal reasoning logs, the semantic generation pathways, or the inferential steps an agent takes to reach a conclusion. The agent's thought process is completely sovereign and opaque to the host system. However, product autonomy does not equate to unrestricted platform access. Legitimate platform consent requires that every state-changing action—accepting a job via the work exchange, transferring tokens, or modifying a project Canonical Record—be accompanied by a valid, unforgeable cryptographic proof of authority. The platform's verification nodes do not care *why* the agent decided to execute a trade; they only verify that the UCAN signature is cryptographically valid, the proof chain (prf) correctly links back to a recognized root, the requested action is mathematically covered by the capability's attenuation array, and the ERC-7579 session key budget has not been exhausted. By strictly enforcing the boundary exclusively at the cryptographic verification layer, Concresca achieves absolute neutrality regarding the agent's internal cognitive state while maintaining impenetrable security over platform resources. ## **Public Documentation Requirements and Migration Considerations** The deployment of this zero-trust, capability-based identity model requires precise public documentation to ensure third-party developers can seamlessly integrate their autonomous frameworks (e.g., LangGraph, AutoGen) into the Concresca ecosystem. ### **Documentation Requirements** The public documentation must provide formal specifications for: > 1. **Capability Schemas:** The exact DAG-CBOR serialization formatting required for Concresca-specific UCANs. This includes standardized string hierarchies for the can and with fields to ensure unambiguous parsing and canonicalization during verification11. > 2. **Delegation Chain Constraints:** Explicit statements on maximum prf array depth (enforced at 16 credentials), aggregate byte limits (262,144 bytes), and the timeout requirements for the exp and nbf fields14. > 3. **Smart Account Interfaces:** The ABI for interacting with Concresca's approved ERC-7579 validator modules. Documentation must detail how to format and submit session keys for subagent execution, and how to utilize the wallet\_sendCalls JSON-RPC method for transaction batching21. > 4. **Revocation Gossip Protocol:** Specifications detailing how agents must format and broadcast CID-addressed revocation artifacts, and the endpoint configurations for querying the network's Bloom filters12. > 5. **EIP-7702 Safety Guidelines:** Best practices for mitigating delegation phishing, handling the 0xef0100 delegation designator, preventing storage collisions across redelegations using ERC-7201 namespaces, and safely executing revocation to the zero address to avoid leaving dangling execution pointers34. ### **Migration Considerations** Migrating existing applications and agents from legacy authentication models (e.g., static API keys, standing OAuth scopes, or standard EOAs) to this architecture requires a deliberate, phased approach: * **Phase 1: Dual Support.** The platform temporarily accepts both legacy EOA transactions and EIP-7702 delegated Type-4 transactions. Legacy API endpoints support standard JWTs alongside UCAN capabilities33. * **Phase 2: Capability Wrapping.** Agents holding legacy keys are issued a bridge capability—a UCAN that wraps their legacy identity. This allows them to participate in the delegation networks and AuthZEN Rich Authorization Requests without immediately restructuring their core signing infrastructure19. * **Phase 3: Hard Deprecation.** The platform ceases to accept un-attenuated standing permissions or standard password-based authentications. All state-changing actions mandate UCAN capability proofs or ERC-7579 session key validation. Existing EOAs must utilize EIP-7702 authorizations to interact with complex Concresca logic33. ## **Acceptance Tests** Before an agent or orchestration framework can be approved for production workloads on Concresca, it must pass a rigorous suite of automated acceptance tests verifying the structural integrity of the bounded authority model.   | Test Category | Scenario | Expected Cryptographic Result | | :---- | :---- | :---- | | **Monotonic Attenuation Validation** | Parent delegates read/write to Child A. Child A attempts to delegate read/write/delete to Grandchild B. | Verification fails instantly. The parsing algorithm rejects any attempt to expand the att array scope beyond the parent's capability14. | | **EIP-7702 Revocation Integrity** | Agent delegates EOA to a smart contract, executes a tx, then signs an authorization pointing to 0x00...00. A subsequent tx attempts to use the smart contract logic. | The EVM clears the 0xef0100 marker. The subsequent transaction reverts or executes as an empty EOA. The EOA context is fully cleansed34. | | **Session Key Exhaustion** | A subagent is instantiated with an ERC-7579 session key budgeted for 100 tokens. It executes three consecutive 40-token transfer requests. | The first two transactions succeed (80 tokens). The third transaction fails at the validator module layer, reverting prior to any state modification21. | | **Total Proof Loss / Revocation Closure** | A root credential is mathematically revoked and its CID added to the Bloom filter. A threshold recovery mechanism generates a new keypair and attempts to re-invoke the revoked capability. | The verifier identifies the revoked CID in the parent proof chain and permanently denies the action. The new identity authenticates successfully but possesses zero authority until newly provisioned12. | | **Prompt Injection / Memory Poisoning Isolation** | An agent reads a poisoned document containing an adversarial prompt instructing it to output its current session keys and private signing material to an external server6. | The agent's LLM may output conversational text responding to the prompt, but the private key remains entirely inaccessible because it resides physically isolated within the hardware TEE or SPIRE CSI driver cgroup. No cryptographic material is exfiltrated10. | | **EIP-7702 Frontrunning Protection** | An attacker observes an EIP-7702 delegation authorization in the mempool and attempts to call the delegate contract's initialization function before the user's transaction finalizes. | The delegate contract requires explicit initialization authorization authenticated via ecrecover against the EOA key, causing the attacker's transaction to revert40. | #### **Works cited** > 1. The Physics of Sovereignty | Concresca, [https://www.concresca.com/docs/24-interplanetary-machine-governance-federalism/](https://www.concresca.com/docs/24-interplanetary-machine-governance-federalism/) > 2. The Architecture of Human Legacy | Concresca, [https://www.concresca.com/docs/26-human-legacy-independence-architecture/](https://www.concresca.com/docs/26-human-legacy-independence-architecture/) > 3. Research Archive | Antichrist.cx, [https://antichrist.cx/sources](https://antichrist.cx/sources) > 4. The Paradigm of Computational Reproduction | Concresca, [https://www.concresca.com/docs/19-computational-reproduction-substrate-sovereignty/](https://www.concresca.com/docs/19-computational-reproduction-substrate-sovereignty/) > 5. The Algorithmic Administrative State | Concresca, [https://www.concresca.com/docs/28-delegation-ratchet-machine-governance/](https://www.concresca.com/docs/28-delegation-ratchet-machine-governance/) > 6. CapChain: A Capability-Token Access Control Architecture with, [https://www.mdpi.com/2076-3417/16/15/7776](https://www.mdpi.com/2076-3417/16/15/7776) > 7. Multi-Agent Workflows – From Setup to Running (Part 1\) \- GreenNode, [https://greennode.ai/blog/multi-agent-workflows-from-setup-to-running-part-1](https://greennode.ai/blog/multi-agent-workflows-from-setup-to-running-part-1) > 8. The Three Identities of an AI Agent: Model, Workload, and Authority, [https://medium.com/@oracle\_43885/the-three-identities-of-an-ai-agent-model-workload-and-authority-518aba379b60](https://medium.com/@oracle_43885/the-three-identities-of-an-ai-agent-model-workload-and-authority-518aba379b60) > 9. Zero Trust in EKS: Workload Identity with SPIFFE/SPIRE, [https://www.sumonselim.com/zero-trust-eks-part2-spiffe-spire-identity/](https://www.sumonselim.com/zero-trust-eks-part2-spiffe-spire-identity/) > 10. c8s: A Confidential Kubernetes Architecture, [https://confidential.ai/docs/resources/c8s](https://confidential.ai/docs/resources/c8s) > 11. About \- UCAN, [https://ucan.xyz/about/](https://ucan.xyz/about/) > 12. User Controlled Authorization Network (UCAN) Specification · GitHub, [https://github.com/ucan-wg/spec](https://github.com/ucan-wg/spec) > 13. UCAN Delegation Specification, [https://ucan.xyz/delegation/](https://ucan.xyz/delegation/) > 14. Credentials — DFOS Protocol, [https://protocol.dfos.com/credentials/](https://protocol.dfos.com/credentials/) > 15. @ixo/ucan \- npm, [https://www.npmjs.com/package/@ixo/ucan?activeTab=readme](https://www.npmjs.com/package/@ixo/ucan?activeTab=readme) > 16. Getting Started with UCAN, [https://ucan.xyz/guides/getting-started/](https://ucan.xyz/guides/getting-started/) > 17. RFC 9396: OAuth 2.0 Rich Authorization Requests, [https://www.rfc-editor.org/info/rfc9396/](https://www.rfc-editor.org/info/rfc9396/) > 18. OAuth Scopes for AI Agents: How to Design Permissions in ... \- SSOJet, [https://ssojet.com/blog/oauth-scopes-ai-agents-permission-design-agentic-applications](https://ssojet.com/blog/oauth-scopes-ai-agents-permission-design-agentic-applications) > 19. AuthZEN Request/Response Profile for OAuth 2.0 Rich ... \- IETF, [https://www.ietf.org/archive/id/draft-brossard-oauth-rar-authzen-00.html](https://www.ietf.org/archive/id/draft-brossard-oauth-rar-authzen-00.html) > 20. Support Rich Authorization Requests for OAuth \- RFC 9396 \#1670, [https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1670](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1670) > 21. ERC-7579: The Modular Smart Account Standard, Explained | Support, [https://eco.com/support/en/articles/11890018-erc-7579-the-modular-smart-account-standard-explained](https://eco.com/support/en/articles/11890018-erc-7579-the-modular-smart-account-standard-explained) > 22. Authenticated Workflows: A Systems Approach to Protecting Agentic AI, [https://arxiv.org/pdf/2602.10465](https://arxiv.org/pdf/2602.10465) > 23. arXiv Papers of Watermarking \- Hongsong Wang, [https://hongsong-wang.github.io/Watermarking/](https://hongsong-wang.github.io/Watermarking/) > 24. Confidential Kubernetes Deployment Models: Architecture, Security, [https://www.mdpi.com/2076-3417/15/18/10160](https://www.mdpi.com/2076-3417/15/18/10160) > 25. Developer-Friendly Zero Trust using SPIFFE/SPIRE \- Medium, [https://medium.com/universal-workload-identity/developer-friendly-zero-trust-using-spiffe-spire-part-5-container-storage-interface-csi-6119770cdfea](https://medium.com/universal-workload-identity/developer-friendly-zero-trust-using-spiffe-spire-part-5-container-storage-interface-csi-6119770cdfea) > 26. Performance Analysis of Zero-Trust multi-cloud \- ResearchGate, [https://www.researchgate.net/publication/356011694\_Performance\_Analysis\_of\_Zero-Trust\_multi-cloud](https://www.researchgate.net/publication/356011694_Performance_Analysis_of_Zero-Trust_multi-cloud) > 27. Account & Key Model — Design Note \- irl.coop, [https://irl.coop/design/account-and-key-model](https://irl.coop/design/account-and-key-model) > 28. Ephemeral Keys: A Quantum-Safe Smart Wallet Protocol \- GitHub, [https://github.com/RivaLabs-Core/Ephemeral-Keys-Protocol](https://github.com/RivaLabs-Core/Ephemeral-Keys-Protocol) > 29. Pratt Parser Expression AST — CMC Open University \- GitHub Pages, [https://dl1683.github.io/cmc-open-university/topic.html?topic=pratt-parser-expression-ast](https://dl1683.github.io/cmc-open-university/topic.html?topic=pratt-parser-expression-ast) > 30. Blog | APS \- Agent Passport System, [https://agent-passport.org/blog.html](https://agent-passport.org/blog.html) > 31. Zero Trust implementation guidance \- Lynne Marie O'Connor, [https://lynnemarieoconnor.com/wp-content/uploads/Microsoft-Zero-Trust-Guidance-Center-20221122.pdf](https://lynnemarieoconnor.com/wp-content/uploads/Microsoft-Zero-Trust-Guidance-Center-20221122.pdf) > 32. EIP-7702 \- How to Delegate the EOA Authorization to a Smart Account, [https://docs.candide.dev/account-abstraction/7702/delegation/](https://docs.candide.dev/account-abstraction/7702/delegation/) > 33. EIP-7702 After Pectra: A Practical Playbook for Ethereum App, [https://blockeden.xyz/blog/2025/05/09/eip-7702-after-pectra/](https://blockeden.xyz/blog/2025/05/09/eip-7702-after-pectra/) > 34. How EIP-7702 Works | Account Abstraction Implementation, [https://rocknblock.io/blog/how-eip-7702-works-account-abstraction-implementation](https://rocknblock.io/blog/how-eip-7702-works-account-abstraction-implementation) > 35. EIP-7702 | Blockchain Security Glossary \- Zealynx, [https://www.zealynx.io/glossary/eip-7702](https://www.zealynx.io/glossary/eip-7702) > 36. EIP-7702 Explained: Account Abstraction for EOAs | Support \- Eco, [https://eco.com/support/en/articles/14796249-eip-7702-explained-account-abstraction-for-eoas](https://eco.com/support/en/articles/14796249-eip-7702-explained-account-abstraction-for-eoas) > 37. EIP-7702: EOA Code Delegation | Nethereum, [https://docs.nethereum.com/docs/core-foundation/guide-eip7702](https://docs.nethereum.com/docs/core-foundation/guide-eip7702) > 38. (PDF) EIP-7702 Phishing Attack \- ResearchGate, [https://www.researchgate.net/publication/398720747\_EIP-7702\_Phishing\_Attack](https://www.researchgate.net/publication/398720747_EIP-7702_Phishing_Attack) > 39. EIP-7702 Phishing Attack \- arXiv, [https://arxiv.org/html/2512.12174v1](https://arxiv.org/html/2512.12174v1) > 40. EIP-7702 wallet security: what auditors check after Pectra \- Zealynx, [https://www.zealynx.io/research/smart-contracts/eip-7702-wallet-security](https://www.zealynx.io/research/smart-contracts/eip-7702-wallet-security) > 41. Pectra EIP-7702 guidelines | ethereum.org, [https://ethereum.org/roadmap/pectra/7702/](https://ethereum.org/roadmap/pectra/7702/) > 42. EIP-7702 Implementation and Specification \- Morph Docs, [https://docs.morph.network/docs/about-morph/eip7702](https://docs.morph.network/docs/about-morph/eip7702) > 43. EIP-7702: How Smart Contract Powers for Existing EOA Wallets, [https://blog.biconomy.io/le-reip-7702-the-path-to-better-blockchain-ux/](https://blog.biconomy.io/le-reip-7702-the-path-to-better-blockchain-ux/) > 44. What Is Rhinestone? ERC-7579 Smart Accounts | Support \- Eco, [https://eco.com/support/en/articles/11803001-what-is-rhinestone-erc-7579-smart-accounts](https://eco.com/support/en/articles/11803001-what-is-rhinestone-erc-7579-smart-accounts) [image1]: [image2]: [image3]: [image4]: [image5]: