=== PAGE 1 === Binding Agent ID: Unleashing the Power of AI Agents with accountability and credibility Zibin Lina, Shengli Zhanga,∗, Guofu Liaoa, Dacheng Taob and Taotao Wanga aShenzhen University, Shenzhen, China bNanyang Technological University, Singapore A R T I C L E I N F O Keywords: AI Agent Identity Agent Authentication Agent Accountability Zero-Knowledge Virtual Machine Blockchain A B S T R A C T Autonomous AI agents lack traceable accountability mechanisms, creating a fundamental dilemma where systems must either operate as “downgraded tools” or risk real-world abuse. This vulnera- bility stems from the limitations of traditional key-based authentication, which guarantees neither the operator’s physical identity nor the agent’s code integrity. To bridge this gap, we propose BAID (Binding Agent ID), a comprehensive identity infrastructure establishing verifiable user-code binding. BAID integrates three orthogonal mechanisms: local binding via biometric authentication, decentralized on-chain identity management, and a novel zkVM-based Code-Level Authentication protocol. By leveraging recursive proofs to treat the program binary as the identity, this protocol provides cryptographic guarantees for operator identity, agent configuration integrity, and complete execution provenance, thereby effectively preventing unauthorized operation and code substitution. We implement and evaluate a complete prototype system, demonstrating the practical feasibility of blockchain-based identity management and zkVM-based authentication protocol. 1. Introduction Artificial Intelligence (AI) agents are evolving from mere tools into autonomous entities capable of independent perception, reasoning, decision-making, and action execu- tion Xi et al. (2025); Guo et al. (2024). These agents can decompose natural language objectives into executable steps and dynamically adjust their plans by invoking external APIs and tools based on environmental feedback Wang et al. (2024b). This capability enables them to bridge digital and physical boundaries, opening unprecedented opportunities for automation and intelligent assistance. However, their deployment faces a fundamental challenge: the absence of traceable and accountable responsibility chains. Without proper identity and accountability mechanisms, this limita- tion creates a critical dilemma where systems must either be “downgraded to tools” requiring step-by-step human con- firmation, or risk real-world abuse including voice cloning fraud, mass information manipulation, and governance con- flicts Verma (2023a,b); Chan et al. (2023); Raskar et al. (2025a). These abstract accountability challenges manifest concretely when autonomous agents perform actions in the real world that cross organizational boundaries and require clear attribution of responsibility. 1.1. Motivating Example: E-commerce Procurement Consider a laptop procurement scenario where an AI agent (Agent A) acting on behalf of a user must interact with a merchant’s agent (Agent B). The workflow showed in Fig. 1 proceeds as follows: (1) Agent A receives a purchase ∗Corresponding author linaacc9595@gmail.com (Z. Lin); zsl@szu.edu.cn (S. Zhang); liaoguofu2022@email.szu.edu.cn (G. Liao); dacheng.tao@gmail.com (D. Tao); ttwang@szu.edu.cn (T. Wang) ORCID(s): request from its user; (2) Agent A discovers and contacts merchant Agent B; (3) both agents mutually verify identities; (4) Agent B checks inventory availability; (5) Agent A executes payment within authorized limits; (6) Agent B con- firms order and initiates delivery. This seemingly straightfor- ward transaction reveals fundamental security requirements across five critical security phases: (1) User Identity Verification: Agent A must authenticate that its operator is the legitimate bound user. Without this verification, command injection attacks can hijack the agent for unauthorized purchases. (2) Trusted Discovery: Agent A must discover and validate Agent B through a secure directory system. Without trusted discovery, Agent A risks connecting to fraud- ulent agents or phishing services. (3) Mutual Authentication: Both agents must bilaterally verify identities to establish trust. Without robust mu- tual authentication, identity spoofing and man-in-the- middle attacks can compromise transaction integrity. (4) Permission Control: Agent A must operate within strictly defined authorization policies following the principle of least privilege. Inadequate controls enable permission boundary violations that exceed spending limits or authorized scope. (5) Accountability Tracking: The system must maintain comprehensive audit trails for responsibility attribution and dispute resolution. Without auditable records, no dispute resolution to resolve disputes or hold parties accountable. Without proper identity and accountability infrastruc- ture, each phase presents significant security and trust chal- lenges that existing approaches cannot adequately address. First Author et al.: Preprint submitted to Elsevier Page 1 of 18 arXiv:2512.17538v1 [cs.NI] 19 Dec 2025 === PAGE 2 === Short Title of the Article 👤 User 🤖 Agent A (Buyer Agent) 🏪 Agent B (Merchant Agent) 📝 (1) Purchase Request Authenticate operator 🔍 (2) Discover & Contact 🔐 (3) Identity Verification Verify binding ✅ Confirm identity Verify binding 📦 (4) Check Inventory ✔️ Available Check limits 💳 (5) Payment 📋 (6) Confirm & Log 👍 Confirmed Log 🚚 Delivery ✅ Complete ⚠️ Command injection risk ⚠️ Fraudulent agents & Phishing services ⚠️ Spoofing & MITM risk ⚠️ Permission boundary violations ⚠️ No dispute resolution 👤 User 🤖 Agent A (Buyer Agent) 🏪 Agent B (Merchant Agent) Figure 1: E-commerce laptop procurement workflow with security and accountability challenges across phases. 1.2. The Gap: Autonomous Capabilities Without Identity Infrastructure Despite intensive research on system-level agent security— including goal alignment Kirk et al. (2024); Huang et al. (2024); OpenAI (2024), adversarial robustness Zou et al. (2024); Anil et al. (2024); Wallace et al. (2024), and multi- agent coordination Yan et al. (2024); Chen and Parker (2024); Tran et al. (2025)—a fundamental infrastructure gap remains: the lack of verifiable identity and accountability. Existing approaches typically assume unified trust bound- aries, overlooking critical questions of “who is operating” and “who bears responsibility” in open ecosystems. Addressing this deficit requires a clear definition of responsibility. Theoretical models primarily distinguish be- tween: (1) the Autonomous Responsibility Model, where agents independently bear liability (implying legal person- hood); and (2) the Binding Agent Model, where agents act as accountable tools bound to specific human or organizational principals. We argue that the Binding Agent Model is the only practicable approach under current technological and legal constraints, as AI lacks legal subject status and agency law attributes actions to principals. However, realizing the Binding Agent paradigm intro- duces a fundamental challenge stemming from the distinc- tion between autonomous agents and standard software. Unlike passive tools, autonomous agents possess the ca- pacity for independent decision-making and real-world in- teractions. This autonomy necessitates a stricter form of binding: the agent must not only serve its owner securely but also ensure that all consequences are irrefutably traceable to that principal. Consequently, mere local user authenti- cation—which provides only service exclusivity—is insuf- ficient. Instead, a third-party verifiable proof is required to confirm that critical actions were explicitly authorized by the user. This obligation is absent in traditional software models, which typically rely on implicit local trust. Emerging Agent Identity systems have laid meaningful foundations for naming and discovery: ANS Huang et al. (2025) provides DNS-like resolution, AgentFacts Raskar et al. (2025b) enables verifiable capability metadata, and works by Chan et al. Chan et al. (2024) and Raskar et al. Raskar et al. (2025a) integrate identity markers into existing infrastructure. Recently, decentralized frameworks like LOKA ? and ERC-8004 ? have further advanced this field by addressing ethical alignment and on-chain valida- tion. However, while these advancements successfully estab- lish “agent-to-system” trust—ensuring agents are locatable, valid, and compliant entities—they fall short of establishing “human-to-agent” liability binding. They lack the mecha- nism to cryptographically anchor agent actions to a liable human principal. By relying on traditional key-based au- thentication, they inherit the semantic gap of standard soft- ware security: keys prove possession but neither authenticate the operator’s physical identity nor guarantee the execution logic’s integrity. In open environments, third-party verifiers require cryptographic assurance that an agent’s actions are authorized by its bound user—a mechanism absent in ex- isting systems, leaving them vulnerable to code substitution and accountability evasion. To address this, we innovatively employ Zero-Knowledge Proofs (ZKP) to generate verifi- able proofs of the authentication process itself, effectively bridging the gap between local authorization and global accountability. 1.3. Our Contributions To address these challenges and implement the Binding Agent responsibility paradigm, we propose the BAID (Bind- ing Agent ID) framework. Our specific contributions are as follows: • We propose the BAID framework, a comprehensive identity infrastructure that integrates local biometric binding, decentralized on-chain identity management, and verifiable agent authentication. This framework provides a unified solution for identity verification, trusted discovery, and accountability tracking, ensur- ing “the correct agent is operated by the binding user executing committed code”. • We introduce a zkVM-based agent authentication protocol to establish verifiable user-code binding. By leveraging code-level authentication and recursive First Author et al.: Preprint submitted to Elsevier Page 2 of 18 === PAGE 3 === Short Title of the Article zero-knowledge proofs, this mechanism cryptographi- cally binds the agent’s execution to its registered iden- tity and authorized user, effectively preventing code substitution attacks and ensuring execution integrity without revealing sensitive operational details. • We implement a complete prototype and provide extensive evaluation. We develop the full system architecture including the identity management smart contracts, and zkVM verification circuits. Our exper- imental results demonstrate the practical feasibility of the system, with gas-efficient on-chain operations and millisecond-level verification latency suitable for real- world deployment. The rest of this paper is organized as follows. Section 2 introduces the technical preliminaries. Section 3 presents the BAID system architecture and technical overviews. Sec- tion 4 describes the detailed technical design of the bind- ing mechanisms. Section 5 evaluates the system’s security properties, performance characteristics, and deployment fea- sibility across multiple dimensions. Section 6 surveys related work. Section 7 concludes the paper. 2. Technical Preliminaries This section introduces the fundamental technologies underlying our BAID framework. 2.1. Blockchain Blockchain represents a decentralized, append-only ledger characterized by three fundamental properties essential for agent identity systems: decentralization, immutability, and public transparency Nakamoto (2008). Through distributed consensus protocols (e.g., Proof-of-Work, Proof-of-Stake), all state transitions are cryptographically linked and ver- ifiable by any participant, eliminating reliance on cen- tralized authorities while ensuring that identity credential registrations, delegations, and revocations remain fully au- ditable. Smart contracts—deterministic programs deployed on blockchains such as Ethereum Buterin (2014)—extend this foundation by enabling Turing-complete logic execu- tion within the Ethereum Virtual Machine (EVM). Upon transaction triggers, contract code and state modifications are validated by all consensus participants, guaranteeing that identity lifecycle operations (issuance, verification, revoca- tion) exhibit both tamper-evidence and public verifiability. These properties collectively establish blockchain as a trust anchor for credential provenance and delegation chains in decentralized agent identity frameworks. 2.2. Zero-Knowledge Virtual Machine The emergence of blockchain technology, distributed ledgers, and multi-party computation has created an increas- ing demand for efficient, scalable, and composable verifica- tion of arbitrary computation results while preserving input privacy. Zero-Knowledge Proof (ZKP) technology estab- lishes the cryptographic foundation for achieving both com- putational integrity and privacy Goldwasser et al. (1985). Nevertheless, traditional approaches based on circuit-level or arithmetic descriptions, such as Rank-1 Constraint Sys- tem and Quadratic Arithmetic Programs, present significant challenges for developers and require substantial effort to integrate with existing software ecosystems. Zero-Knowledge Virtual Machine (zkVM) addresses this challenge by bridging the semantic gap between general- purpose programs and provable instances. By introducing an abstraction layer that encompasses an instruction set architecture (typically resembling traditional CPU designs or optimized RISC-style instructions) and a corresponding execution environment, zkVM automatically transforms program execution into verifiable constraints and proof generation procedures. This transformation enables proof- carrying execution while maintaining high degrees of devel- opment reusability and ecosystem compatibility. Formally, let 𝜆denote the security parameter and let 𝔽𝑝 be the base field where 𝑝is a large prime. We model zkVM as a five-tuple: Π = (Setup, CommitProg, Compile, Prove, Verify) consisting of the following algorithms: 1. (𝑝𝑝, 𝑣𝑘) ← Setup(1𝜆, 𝑝𝑎𝑟𝑎𝑚): A setup algorithm that generates public parameters and verification key, where 𝑝𝑎𝑟𝑎𝑚encompasses system parameters includ- ing the maximum step bound 𝑇𝑚𝑎𝑥, field specifica- tions, and commitment scheme parameters. 2. 𝐶𝑃 ←CommitProg(𝑃): A commitment algorithm that produces a cryptographic commitment 𝐶𝑃to the program code 𝑃using either hash-based, vector, or KZG commitment schemes. 3. (ArithDesc, MapIO) ←Compile(𝑝𝑝, 𝑃): A compi- lation algorithm that performs static analysis and transforms the instruction set into constraint tem- plates, yielding both arithmetic descriptions (con- straint skeletons) and I/O mapping specifications. These outputs serve as static intermediates for sub- sequent proof generation, enabling the transformation of program logic into verifiable constraints. 4. 𝜋←Prove(𝑝𝑝, 𝐶𝑃, ArithDesc, MapIO, 𝑥𝑝𝑢𝑏, 𝑥𝑝𝑟𝑣, 𝑦): A proving algorithm that: • Constructs the execution trace Trace(𝑃, 𝑥𝑝𝑢𝑏, 𝑥𝑝𝑟𝑣) = (𝑠0, … , 𝑠𝑇), utilizing MapIO to map public inputs 𝑥𝑝𝑢𝑏and private inputs 𝑥𝑝𝑟𝑣into the initial state and en- sure output 𝑦consistency in the final state. • Generates the constraint representation by in- stantiating ArithDesc’s constraint templates with the execution trace (utilizing R1CS, AIR, or PLONKish frameworks), incorporating MapIO for I/O constraints. • Executes the underlying proof system to produce the proof 𝜋. First Author et al.: Preprint submitted to Elsevier Page 3 of 18 === PAGE 4 === Short Title of the Article 5. 𝑏←Verify(𝑣𝑘, 𝐶𝑃, 𝑥𝑝𝑢𝑏, 𝑦, 𝜋): A verification algo- rithm that outputs a binary decision: accept (1) or reject (0). The verification implicitly relies on the con- straint structure derived from ArithDesc and MapIO (embedded in 𝑣𝑘or 𝐶𝑃), ensuring the proof 𝜋attests to correct program execution and I/O mapping without revealing private inputs. In the BAID framework, zkVM enables agents to gen- erate verifiable execution proofs demonstrating identity au- thenticity and operational compliance without revealing sen- sitive configurations or proprietary code. These proofs cryp- tographically establish that agents operate under certified configurations, authenticated operators, and committed pro- gram logic, thereby achieving accountability through com- putational verification rather than data disclosure. 2.3. Verifiable Credentials Verifiable Credentials (VC) and Decentralized Identi- fiers (DID) constitute the foundational standards for de- centralized, privacy-preserving, and interoperable digital identity systems Sporny et al. (2025, 2022). The trust model involves four key entities: Issuers make cryptographically signed claims about subjects; Holders store VCs and gener- ate selective-disclosure Verifiable Presentations (VPs); Ver- ifiers authenticate credentials by resolving issuer and holder public keys through Registry Authorities, which maintain immutable trust anchors recording entity identities, asso- ciated keys, and revocation lists. This architecture enables privacy-preserving identity verification: holders can prove specific attributes (e.g., “age ≥18”, “KYC approved”) with- out revealing underlying personal data. Integration with zero-knowledge proofs strengthens pri- vacy guarantees Pauwels (2021). In zkKYC scenarios, ap- proved institutions (Issuers) generate signed VCs with cryp- tographic field commitments using privacy-preserving sig- nature schemes such as BBS+ or CL-Signature. Holders then generate Selective-Disclosure Proofs through local ZKP circuits, cryptographically demonstrating compliance with regulatory requirements (e.g., “not sanctioned”, “cre- dential unexpired”, “age ≥18”) while concealing sensitive personal identifiers. Verifiers validate only the VC signature chain and ZKP correctness, confirming regulatory compli- ance without accessing underlying personal data. This cryp- tographic separation of authentication (proving credential validity) from disclosure (revealing specific attributes) es- tablishes VCs as the privacy-preserving credential substrate for BAID framework. 3. BAID System Overview The BAID (Binding Agent ID) system establishes verifi- able, traceable, and accountable digital identity chains for autonomous AI agents, addressing the fundamental chal- lenge of agent trustworthiness and cross-system collabora- tion. As illustrated in Figure 2, the system workflow pro- ceeds through three integrated stages: (1) users establish local biometric binding with agents through the Biometric Authentication Module (BAM), anchoring agent identity to its human owners; (2) users register Agent Identifiers on-chain via blockchain smart contracts, creating publicly queryable user-agent binding declarations that enable trusted agent discovery; (3) agents authenticate to third-party veri- fiers through zkVM execution proofs combined with Ver- ifiable Credentials, establishing cryptographically verified identity and permission scope for secure collaboration. To implement this workflow, the BAID system architecture comprises three principal technical modules: (1) Local User-Agent Binding. To support local bind- ing and subsequent Agent ID management, we design an extended agent framework that enhances the Profile module and introduces an Identity Management module support- ing biometric authentication and cryptographic operations. Users establish local binding by storing their biometric identity features in the agent’s Profile security configura- tions file. Subsequently, the agent continuously validates operators against stored biometric templates through the Biometric Authentication Module (BAM), ensuring only the legitimate owner can activate the agent—this corresponds to Phase 2 (Operator Biometric Authentication) in the verifi- cation pipeline, thereby implementing the security property “agent serves only its owner.” (2) On-Chain Identity Management. Building upon this local foundation, leveraging blockchain’s transparency, immutability, and decentralization, BAID constructs a glob- ally unified trusted identity system supporting user/agent registration, on-chain binding, and agent discovery. Users complete real-person verification through zkKYC (see Sec- tion 2.3) without revealing identity privacy, creating User Identity Contracts that establish legal entity attributes. Based on the User Identity Contract, users can subsequently create Agent Identity Contracts for locally-bound agents, making binding relationships publicly queryable. The Agent Iden- tity Contract records agent attributes (user identity contract address, Agent Identifier, capabilities, roles) and communi- cation metadata (protocols, endpoints, domains), thereby en- abling agent discovery functionality that allows other agents to rapidly identify and locate collaboration channels. The on-chain Agent Identifier serves as the canonical reference for Phase 1 (Agent Configuration Integrity) verification, ensuring local configurations match blockchain-anchored versions. (3) Agents Authentication and Authorization Proto- col. With the identity infrastructure established, the authen- tication mechanism enables verifiers to validate agent identi- ties and permission boundaries, establishing trust channels. As shown in Figure 2, agents initially establish communi- cation through the blockchain identity system’s discovery functionality, but further collaboration requires mutual iden- tity and permission verification. As software entities, agents’ program commitments serve as their “biometric identity features.” We use program commitments as Agent Identifiers and employ zkVM proofs to verify consistency between currently executing programs and Agent Identifiers—this authentication mechanism transcends traditional key-based First Author et al.: Preprint submitted to Elsevier Page 4 of 18 === PAGE 5 === Short Title of the Article 身份系统整体架构 User A Agent A User B Agent B User C Agent C Locally Binding Locally Binding Locally Binding User A Contract Identity Contract Blockchain Identifier Owner Attributes Agent A Binding User B Contract Identifier Owner Attributes Agent B Binding Identity Contract Binding Identifier Attributes Agent C Owner Identity Contract User C Contract Agent A Agent Discovery Binding Relationship Agent B ̍ID Verifiavable Credentials Call Call Call Figure 2: BAID system architecture: 1. Local User-Agent Binding mechanism; 2. On-Chain Identity Management; 3. Agents Authentication and Authorization Protocol. authentication limitations by simultaneously verifying the operator’s physical identity and the agent’s computational identity, effectively preventing both unauthorized operation and malicious program impersonation. Moreover, BAID im- plements verifiable permission authorization through Ver- ifiable Credentials (VC), enabling users to perform fine- grained authorization combining agent attributes and target task contexts. Consequently, during agent authentication, agents must provide two proofs to verifiers: zkVM execution proof and user permission authorization proof (VC). 4. BAID System Designs Having outlined the overall BAID architecture, we now provide detailed system designs for the framework’s three core pillars. This section first presents the local binding infrastructure that establishes the foundational trust rela- tionship between agents and their human owners (Section 4.1). It then details the blockchain-based identity registration and discovery mechanisms that enable global agent inter- operability (Section 4.2). Finally, it describes the zkVM- based agent identity authentication protocol that facilitates verifiable and privacy-preserving interactions through code- level proofs (Section 4.3). 4.1. Local User-Agent Binding via Biometric Authentication The local binding mechanism ensures that agents serve exclusively their designated owners by embedding user bio- metric identity directly into agent configurations. This mech- anism is implemented through an enhanced agent archi- tecture that integrates biometric authentication capabilities within the Identity Management module. 4.1.1. Agent Architecture Contemporary agent frameworks typically consist of Profile (configuration), Memory (knowledge retention), Plan- ning (decision-making), and Action (task execution) mod- ules Wang et al. (2024a). However, to support autonomous identity management and cryptographic operations, we ex- tend this architecture with an Identity Management module and augment the Profile module with identity-binding capa- bilities. Profile Module. Beyond recording agent attributes (ca- pabilities, behavioral constraints, operational parameters), the Configuration Document within the Profile module stores the owner’s Human Identifier and Biometric Au- thentication Credential. These identity anchors provide the foundation for deep binding and local user authentication mechanisms. Identity Module. This module manages all Agent ID- related operations, consisting of two subcomponents: (1) Cryptographic module (e.g., zkVM) for generating authenti- cation proofs and managing Verifiable Credentials; (2) BAM integration for real-time operator identity verification. The module interfaces with both local biometric sensors and blockchain identity contracts to enforce the security property “agent serves only its owner.” Figure 3 illustrates the enhanced agent architecture with identity management capabilities integrated into the stan- dard agent framework. 4.1.2. Biometric Template Registration and Verification The local binding mechanism establishes a cryptograph- ically secure association between user biometric identity and agent configuration, operating through two distinct phases: registration and verification. First Author et al.: Preprint submitted to Elsevier Page 5 of 18 === PAGE 6 === Short Title of the Article Planning Memory Action Identity Profile long term memory LLM subtask1 subtask3 subtask4 subtask2 zk prover MFA VC management short term memory configuration profile contents generation strategy Figure 3: Extended agent architecture with Identity module: integrating biometric authentication, cryptographic operations, and identity binding capabilities into the standard agent framework (Profile, Memory, Planning, Action). BAM Local Device UserID Biometric Template Configuration Module Configuration Document Agent register User Figure 4: Local binding registration workflow: biometric tem- plate generation and configuration document binding. Registration Phase. During the initial binding establish- ment, the system performs the following steps as illustrated in Figure 4: Step1: Biometric Capture and Template Generation. The user invokes the device’s local Biometric Authentication Module (BAM), which captures biometric data via facial recognition camera, fingerprint sensor, or iris scanner. BAM applies feature extraction algorithms to generate a Biometric Template—a compact mathematical representation of dis- tinctive biological traits. Step2: Configuration Binding. The system writes both the User Identifier and Biometric Template (designated as Registered Template) into the agent’s Configuration Doc- ument within the Profile module, creating an immutable binding record that anchors the agent to its designated owner. Verification Phase. Once bound, the Identity Module enforces continuous operator verification before executing sensitive operations. BAM captures fresh biometric sam- ples, generates temporary templates, and performs similarity matching against the registered template to confirm identity. If verification fails, the agent immediately terminates or refuses service, ensuring that only the legitimate bound user can control agent actions. 4.2. On-Chain Identity Management Building upon the local binding infrastructure, we con- struct a globally unified, decentralized on-chain identity system based on blockchain technology to support trusted identity management and secure collaboration across the agent ecosystem. This identity system not only strength- ens user sovereignty over agents but also provides critical infrastructure for building secure, trustworthy, multi-party collaborative agent networks. 4.2.1. Identity Management Smart Contract Framework The decentralized identity system comprises three pri- mary architectural components: Entrypoint Contract. Drawing inspiration from the ERC-4337 account abstraction protocol, we employ an Entrypoint Contract as the user-contract interaction gateway. The ERC-4337 protocol enables user accounts to execute complex programmable logic including gas sponsorship for agents (users pay transaction fees on behalf of their agents), delegated payment authorization (granting agents specific payment permissions within defined limits), and subordinate account binding (establishing agent identity ac- counts as dependent sub-accounts under user accounts). The Entrypoint Contract leverages these capabilities to verify and execute user transactions while invoking target identity contracts, enabling flexible identity management operations without requiring agents to hold native blockchain tokens for transaction fees. Identity Contracts. The User Identity Contract and Agent Identity Contract serve as the respective account con- tracts for users and agents within the identity system, both in- stantiated by the Entrypoint using predefined templates. The User Identity Contract template contains variables including Owner, userID, and Agent_Binding_List, storing the user’s public key, user identifier, and the list of 𝖠𝗀𝖾𝗇𝗍𝖨𝖣s bound to the user, respectively. The Agent Identity Contract template contains variables including Owner_User, OperationalStatus, Attribute, and AgentFactsURL. These variables store: (1) the owner’s contract address; (2) the agent’s operational status (Running/Stopped/Deregistered); (3) agent attributes (in- cluding agent name, program commitment 𝐶𝑃, configura- tion hash, 𝗎𝗌𝖾𝗋𝖨𝖣, 𝖠𝗀𝖾𝗇𝗍𝖨𝖣, capabilities, and roles); and (4) the Uniform Resource Locator pointing to the agent’s verifiable metadata (AgentFacts). AgentFacts is a lightweight dynamic metadata document published by the agent, employing JSON-LD format with Verifiable Credential signatures to describe an AI agent’s identity, capabilities, endpoints, routing, and trust status. It decouples stable index records from high-frequency chang- ing information, supporting rapid updates, verifiable trust, and privacy-friendly resolution Raskar et al. (2025b). The complete AgentFacts document supports multiple flexible First Author et al.: Preprint submitted to Elsevier Page 6 of 18 === PAGE 7 === Short Title of the Article Table 1 Core Functions for Agent Identity Lifecycle Management Function Description addAgent(...) Creates Agent Identity Contract through Entrypoint, adds AgentID to Agent_Binding_List, establishing on-chain User-Agent binding for discovery and accountability. updateAgent(...) Modifies agent attributes after verifying caller authorization (Owner_User), record- ing timestamps and versions for capabil- ity evolution tracking. removeAgent(...) Sets OperationalStatus to Deregistered, removes AgentID from binding list while preserving audit trails for compliance. storage options including agent self-hosting, IPFS decen- tralized storage, third-party hosting, CDN distribution, and storage within the BAID Agent Identity Contract itself. Only the AgentFactsURL needs to be published in the Agent Identity Contract to enable BAID’s Agent Discovery functionality. The identity system implements three core functions for lifecycle management, as detailed in Table 1. 4.2.2. On-Chain Identity Registration and Binding Workflow As illustrated in Figure 5, the registration and binding workflow covers the complete agent lifecycle from user identity establishment to agent on-chain registration: Step1: UserID Registration. Based on the principle of legal entity binding with optional anonymity, we leverage real-person zkKYC technology to confirm users’ legal entity attributes and complete UserID registration without expos- ing users’ real identities. After users pass zkKYC verifica- tion, the Entrypoint Contract creates a User Identity Contract and initializes the userID and Owner variables (Owner = Pkey_A, where Pkey_A is the user’s blockchain account public key). Step2: AgentID Generation. In BAID, the Agent Iden- tifier follows the structure: 𝖠𝗀𝖾𝗇𝗍𝖨𝖣= agentid ∶𝐻(name‖𝐶𝑃‖ 𝐻(profile)‖userID‖others) (1) where 𝐶𝑃 = CommitProg(𝑃) is the program com- mitment, 𝐻(profile) hashes the security configuration (user identity, policy constraints), 𝗎𝗌𝖾𝗋𝖨𝖣identifies the bound user, and name provides human readability. The 𝖠𝗀𝖾𝗇𝗍𝖨𝖣is generated locally by the user, preparing for subsequent on- chain identity registration. Table 2 presents an 𝖠𝗀𝖾𝗇𝗍𝖨𝖣for a laptop retail sales advisor agent, demonstrating how these identity components are instantiated in practice. Step3: AgentID Registration and Binding. The user generates variable data Attribute, AgentFactsURL, and a sig- nature 𝖲𝗂𝗀𝐴using the owner’s public key, then invokes the Entrypoint Contract to execute the User Identity Con- tract’s addAgent(AgentID, Name, Attribute, AgentFactsURL) User Entrypoint Contract User Identity Contract ̍KYC UserID Entrypoint Contract AgentFactsURL Agent Identity Contract UserID Attribute SigA PkeyA PkeyA AgentFactsURL Attribute Figure 5: Registration and binding workflow showing UserID registration via zkKYC, AgentID generation, and on-chain AgentID registration. Table 2 Example AgentID for Laptop Retail Sales Advisor Agent Field Value name baid:agent:laptopretail:salesadvisor code_hash sha256:2c1d7fa9c5b84d6f9a1e3d... profile_hash sha256:8af4c61bd0b9e2a7d17f... UserID org:laptopretail:cn:sales-division Other “agent_version”: “1.0.0” AgentID agentid:5f04cf173a987be6a98e... function (see Table 1), adding the newly bound agent’s information and creating the Agent Identity Contract. After signature verification passes, the Entrypoint Contract creates an Agent Identity Contract and initializes the Owner_User, Attribute, and AgentFactsURL variables. The Owner_User is set to the User Identity Contract’s address, declaring the binding relationship between the user and agent and ownership of the Agent Identity Contract. 4.3. zkVM-Based Agent Identity Authentication Protocol Having established the local binding and on-chain regis- tration mechanisms, we now present the zkVM-based agent identity authentication protocol that enables secure agent interactions with third-party verifiers through cryptographi- cally verifiable identity and permission proofs. This protocol addresses the fundamental challenge of establishing trust when agents interact with external entities—including other agents, service providers, and regulatory authorities. Veri- fiers must authenticate both the agent’s identity integrity and its delegated permission scope to establish a cryptographic trust foundation. The authentication protocol comprises two complemen- tary components: user-to-agent authorization through Veri- fiable Credentials, and agent identity authentication through zkVM proofs. The authorization mechanism enables users to delegate fine-grained permissions to agents, while the authentication mechanism enables agents to prove their iden- tity and authorization scope to any third-party verifier with- out revealing sensitive information. Agent-to-agent interac- tion represents a primary application scenario, where mutual First Author et al.: Preprint submitted to Elsevier Page 7 of 18 === PAGE 8 === Short Title of the Article Biometric Identification User Agent Identity Module VC Management VC BAM VC AgentID UserID Task ID Task definition AgentFactsURL VC Figure 6: Authorization workflow showing VC generation, biometric authentication, and credential signing. authentication enables trustworthy collaboration between autonomous systems. 4.3.1. User-to-Agent Authorization Authorization establishes the permission delegation chain from users to agents, enabling agents to access user data, invoke resources, or act on behalf of users within explicitly defined boundaries. Our authorization mechanism features context-aware permission control that combines agent at- tributes with target task contexts, thereby preventing per- mission over-provisioning and protecting user data privacy. Authorization Workflow. As illustrated in Figure 6, the authorization process comprises three steps: Step1: Verifiable Credential Generation. The agent’s Identity Module generates a Verifiable Credential (VC) based on the agent’s role, capabilities, and target task con- text. The VC contains: (1) Identity information (agent’s 𝖠𝗀𝖾𝗇𝗍𝖨𝖣and user’s 𝖴𝗌𝖾𝗋𝖨𝖣); (2) Task information (Task ID, Task definition); and (3) Permission information (security level, authorization scope, and credential validity period). Step2: Local User Authentication. The Identity Mod- ule initiates local user authentication to verify that the cur- rent operator is the legitimate owner, following the biometric verification procedure described in Section 5.1. Step3: Credential Signing and Storage. After passing local user authentication, the Identity Module signs the VC using the Owner’s private key and attaches the signature to the VC. The signed VC is then stored in the agent’s Identity Module. When necessary, the VC can be published to the AgentFactsURL, for example, VCs that can demonstrate the agent’s capabilities or harmlessness. 4.3.2. zkVM-Based Agent Identity Authentication Building upon the user-to-agent authorization founda- tion, the agent identity authentication protocol implements a dual-layer verifiable computation framework leveraging zkVM technology. This protocol addresses three fundamen- tal technical challenges inherent to autonomous agent sys- tems to establish cryptographic guarantees for agent identity integrity, operator legitimacy, and execution provenance. Challenge 1: Identity-Execution Binding. Traditional key-based authentication is insufficient for autonomous agents, as possession of a signing key guarantees neither the integrity of the executing code nor the authenticity of the operator. An adversary with a compromised key could therefore execute malicious logic or impersonate the legiti- mate operator while masquerading as the authorized agent. To resolve this semantic gap, we introduce Code-Level Authentication using zkVM. By establishing the program binary as the agent’s identity and generating cryptographic proofs of execution, we bind the agent’s identity directly to its computational behavior and operator authorization, ensuring that only the committed code executed by the bound user can generate valid authentication proofs. Challenge 2: Execution Continuity. Agents operate through multi-turn interactions where state transitions must be sequentially valid. Standard verifiable computation proofs verify individual steps but lack mechanisms to enforce the correct ordering of a sequence, leaving systems vulnerable to replay or reordering attacks. We address this by leveraging zkVM’s Recursive Verification capability. Each execution step generates a proof that recursively verifies the validity of the previous step’s proof, constructing an unbreakable cryp- tographic chain that guarantees the integrity and continuity of the entire interaction history. Challenge 3: Data Provenance. Agents frequently in- teract with external environments (e.g., calling LLM APIs or accessing web data), but the zkVM cannot inherently verify the authenticity of external data. This creates a trust gap where an attacker could feed fabricated data to the agent. We bridge this gap by integrating zkTLS (Zero-Knowledge Transport Layer Security). This allows the agent to generate proofs attesting that specific data originated from a trusted TLS-authenticated server (e.g., OpenAI), ensuring end-to- end provenance from external data sources to internal com- putation. To systematically resolve these challenges, we propose a Dual-Layer Verification Framework (detailed technical specifications including mathematical proofs, security prop- erties, and protocol formalization are provided in Appendix A). The protocol orchestrates verification through two inte- grated layers: Layer 1: Three-Phase Verifiable Computation Pipeline. This layer implements end-to-end cryptographic guarantees through recursive proof algorithm across three sequential phases: Phase 1—Operator Biometric Authentication. To ad- dress the unique security requirements of autonomous agents, this phase validates operator legitimacy through privacy- preserving facial recognition. This mechanism fulfills two critical security objectives: it strictly enforces that the agent serves exclusively its designated owner, and simultaneously generates a third-party verifiable proof of this authoriza- tion—a mandatory condition for irrefutable traceability that overcomes the limitations of mere local authentication. The protocol captures operator face via device camera, extracts normalized 128-dimensional embedding 𝐯capture using pre- trained neural networks (FaceNet, ArcFace), and loads stored template 𝐯stored from the verified configuration. zkVM similarity computation receives public inputs (threshold 𝜏, First Author et al.: Preprint submitted to Elsevier Page 8 of 18 === PAGE 9 === Short Title of the Article user identifier) and private witness (𝐯capture, 𝐯stored), gener- ating proof 𝜋1 asserting: ∃𝐯capture, 𝐯stored ∶ 𝐯capture ⋅𝐯stored ‖𝐯capture‖‖𝐯stored‖ ≥𝜏 (2) without revealing embedding vectors, ensuring only autho- rized users activate agent services. Phase 2—Agent Configuration Integrity. Building upon operator verification, the protocol verifies that the agent’s local configuration matches the blockchain-anchored canon- ical version. The on-chain 𝖠𝗀𝖾𝗇𝗍𝖨𝖣stores profile_hash = 𝐻(Config) in an Ethereum smart contract at storage slot 𝑠. The protocol invokes eth_getProof(contractAddr, [s], blockNumber) to retrieve Merkle proofs linking the 𝖠𝗀𝖾𝗇𝗍𝖨𝖣 to blockchain state. zkVM verification receives public inputs (𝑟storage, expected profile hash) and private witness (local configuration Configlocal, Merkle proof 𝜋merkle), then proves: 𝐻(Configlocal) = profile_hash in 𝖠𝗀𝖾𝗇𝗍𝖨𝖣 (3) Leveraging blockchain’s tamper-proof storage establishes a cryptographic anchor for agent identity, generating proof 𝜋2 that binds storage root and Merkle proof verification without revealing configuration contents. Phase 3—Iterative Execution with Communication Prove- nance. The system generates cryptographic proofs for com- plete execution traces across conversational turns. Each turn 𝑡involves: (1) input reception (user query 𝑞𝑡, previous state commitment ℎ𝑡−1 = 𝐻(𝑆𝑡−1)); (2) LLM invocation (remote service response 𝑎𝑡); (3) tool execution (𝑜𝑡= 𝑓𝑎𝑡(params)); (4) state update (𝑆𝑡 = (𝑆𝑡−1, 𝑞𝑡, 𝑎𝑡, 𝑜𝑡)). The integrated execution proof 𝜋𝑡combines three verification stages within one zkVM execution: 1. Recursive Verification. For 𝑡> 1, verify parent proof 𝜋𝑡−1 validity through zkVM’s recursive verification capability—where Prove algorithm verifies another zkVM proof within its execution—preventing bro- ken proof chains from extending. This constructs proof chains with cryptographically enforced sequen- tial dependencies: proof 𝜋𝑘embeds complete pre- vious proof 𝜋𝑘−1 in public inputs 𝑥𝑝𝑢𝑏,𝑘, and con- straint template includes recursive verification pro- gram 𝑃rec(𝑣𝑘, 𝐶𝑃, 𝑥𝑝𝑢𝑏,𝑘−1, 𝑦𝑘−1, 𝜋𝑘−1). Successful ver- ification of final proof 𝜋𝑇implies the entire execution sequence 𝑆0 →𝑆1 →⋯→𝑆𝑇validates in order with no permutation or substitution. 2. zkTLS Verification. Execute TLS session validation within zkVM to ensure authenticity of external com- munications. zkVM operates in isolated environments that cannot verify external data sources—an adversary controlling execution environment can replace gen- uine API responses with fabricated data. We adopt zkTLS (Zero-Knowledge Transport Layer Security) to establish cryptographic provenance for HTTPS communications. The unified verification circuit val- idates: (a) certificate validity (verify signature chain to trusted root CA, check certificate matches server identity); (b) session key derivation (compute Pre- Master Secret, derive 𝐾session via PRF); (c) data integrity (decrypt response 𝑑= D𝐾session(𝑐), verify AEAD authentication tag); and (d) commitment bind- ing (commit(𝑑) = 𝐻(𝑑) matches public input). The unified proof 𝜋𝑡cryptographically attests: there exists a valid TLS session with server 𝑆that decrypts to data 𝑑(matching commitment 𝐻(𝑑)), and program 𝑃correctly processed 𝑑to produce claimed output— binding TLS communication provenance with com- putation correctness. 3. Agent Computation Verification. Verify agent cor- rectly executes tasks using verified responses: parse action, execute tool call, update state, compute state commitment ℎ𝑆𝑡= 𝐻(𝑆𝑡). After 𝑇conversational turns, final proof 𝜋𝑇cryptograph- ically attests to: (1) initial authentication validity (Phase 1 configuration integrity, Phase 2 operator biometric verifica- tion); (2) complete execution trace across all turns: 𝑆0 → 𝑆1 →⋯→𝑆𝑇; (3) verified provenance of all external service responses: {𝑎1, … , 𝑎𝑇} via zkTLS; (4) correct agent computation for all tool executions: {𝑜1, … , 𝑜𝑇} following code 𝐶𝑃. Layer 2: Permission Validation. After establishing identity and execution integrity through Layer 1, the system validates authorization scope using Verifiable Credentials. The verifier validates agent’s VC to confirm permission scope matches requested operation: (a) signature verifica- tion using user’s public key from User Identity Contract; (b) credential validity period checking; (c) permission scope matching against target task context; (d) revocation status checking. This layer ensures authenticated agents operate within explicitly delegated permission boundaries, prevent- ing privilege escalation. Authentication Output. Upon successful completion, the protocol outputs: (1) unified proof 𝜋𝑇demonstrating agent configuration integrity, operator biometric verifica- tion, and complete execution trace; (2) validated Verifi- able Credential with verified permission scope. Verifiers (counterpart agents, service providers, regulators) indepen- dently verify by checking 𝜋𝑇using zkVM’s Verify algorithm against on-chain 𝖠𝗀𝖾𝗇𝗍𝖨𝖣and validating VC signature and scope, establishing cryptographic guarantees for trustworthy agent interactions without centralized trust infrastructure. 5. Implementation and Performance Evaluation We evaluate the BAID system across two critical di- mensions: (1) on-chain identity management smart contracts performance focusing on gas consumption efficiency for on- chain identity management operations, and (2) verifiable agent system performance focusing on zkVM-based authen- tication protocol efficiency. These evaluations address dis- tinct but complementary aspects of the BAID architecture, demonstrating practical deployability across both on-chain and off-chain components. First Author et al.: Preprint submitted to Elsevier Page 9 of 18 === PAGE 10 === Short Title of the Article Table 3 Gas Consumption for Core BAID System Operations Operation Gas Consumption User Registration (registerUser) 390,325 gas Agent Registration (registerAgent) 507,763 gas Agent Deregistration (deregisterAgent) 124,117 gas Agent Update (updateAgent) 128,837 gas 5.1. Identity Management Smart Contracts Performance To evaluate the gas consumption efficiency of the BAID on-chain identity management system, we deployed the complete smart contract architecture on the Ethereum Vir- tual Machine (EVM) testnet and conducted comprehensive performance testing using the Hardhat framework Nomic Foundation (2024), a development environment that pro- vides deterministic gas metering consistent with mainnet behavior. We deployed the complete BAID contract suite including IdentityFactory, UserIdentityContract template, AgentIdentityContract template, and all zkKYC verification contracts. Gas measurements were collected using Hardhat’s built-in gas reporter, which instruments the EVM to track computational costs for each transaction. The evaluation focused on gas consumption for core identity management operations, as gas costs directly impact the economic feasi- bility and scalability of blockchain-based identity systems. Table 3 presents the gas consumption statistics for the four core BAID system operations. The measurements repre- sent average values across multiple test executions, demon- strating consistent performance characteristics. The experimental results demonstrate two fundamental characteristics of the BAID blockchain system’s gas con- sumption profile: (1) Registration Cost Composition. Registration op- erations exhibit high gas consumption driven by two fac- tors: cryptographic verification overhead and storage al- location costs. User registration (∼390K gas) performs zkKYC verification for privacy-preserving identity valida- tion, consuming substantial gas for on-chain zero-knowledge proof verification. Agent registration (∼508K gas) adds 30% overhead through Clone-pattern contract instantiation and user-agent binding establishment. The fundamental storage cost asymmetry—SSTORE from zero to non-zero requires 20,000 gas per slot versus 5,000 gas for modifications— explains why registration operations dominate gas consump- tion. (2) Efficient State Modification. Update (∼129K gas) and deregistration (∼124K gas) operations consume approx- imately 75% less gas than registrations by avoiding expen- sive contract creation and leveraging existing storage slots. These operations achieve consistent performance through minimal state modifications and event emission, demon- strating the efficiency of the BAID contract architecture for routine identity management operations. Table 4 zkVM Performance Metrics for BAID Authentication Protocol Phase Exec Prove Total Proof Verify (ms) (s) (s) (KB) (ms) Phase 1: Bio Auth 9 15.00 15.01 238 14 Phase 2: Config Veri 13 31.35 31.36 488 28 Phase 3 (Turn 1) 17 40.14 40.16 737 43 Phase 3 (Turn 2) 19 37.68 37.70 987 74 Phase 3 (Turn 3) 15 38.29 38.31 1236 93 Overall, the BAID blockchain system achieves gas- efficient identity management through three design choices: zkKYC for privacy-preserving user registration, Clone pat- tern for agent contract deployment, and minimal storage footprint for affordable routine operations. 5.2. Verifiable Agent System Performance To evaluate the performance and scalability of the BAID authentication protocol, we implemented a com- plete Verifiable Agent System using RISC Zero’s zkVM framework RISC Zero (2024) and conducted comprehen- sive performance testing on the recursive proof generation pipeline. The testing environment consisted of a Rust-based zkVM execution framework implementing the complete BAID authentication pipeline described in Section 5.3, deployed on a standard development machine (Apple M1 chip, 16GB RAM) using RISC Zero zkVM version 1.0 with the composite proof system. The implementation follows a fully recursive verification pipeline spanning five sequential phases: (1) Phase 1 (Op- erator Biometric Authentication) establishes the baseline proof; (2) Phase 2 (Agent Configuration Integrity) recur- sively verifies Phase 1; (3) Phase 3 comprises three itera- tions of Iterative Task Execution, where Turn 1 recursively verifies Phases 1-2, Turn 2 recursively verifies Phases 1- 2 and Turn 1, and Turn 3 recursively verifies the com- plete execution history from Phase 1 through Turn 2. The evaluation focused on execution efficiency, proof generation overhead, verification costs, and proof size characteristics across this multi-phase recursive authentication workflow, as these metrics directly impact the practical deployability and scalability of zkVM-based agent identity systems. Table 4 presents the performance characteristics for each phase of the BAID authentication protocol. The measure- ments represent average values across multiple test execu- tions, demonstrating consistent performance patterns. Proof Generation Overhead. Proof generation dom- inates the computational cost, constituting 99.9% of total processing time across all phases. For instance, Phase 1 requires only 9ms for program execution but 15.00s for proof generation, demonstrating that cryptographic proof construction overhead far exceeds the program execution First Author et al.: Preprint submitted to Elsevier Page 10 of 18 === PAGE 11 === Short Title of the Article itself. This asymmetry aligns with fundamental zkVM archi- tecture where constraint satisfaction and polynomial com- mitment schemes require intensive computation, while pro- gram execution remains lightweight. Notably, proof gener- ation time scales polylogarithmically with program size but exhibits near-constant complexity with respect to recursive depth—the 15-40 second generation latency remains con- sistent across phases despite accumulating recursive verifi- cation steps. This property makes the protocol suitable for high-security authentication scenarios where cryptographic guarantees justify computational overhead. Verification Overhead. In contrast to proof generation, verification exhibits succinct characteristics with logarith- mic complexity relative to program size. Verification time demonstrates linear growth with recursive depth—Phase 3 (Turn 1) requires 43ms, Phase 3 (Turn 2) (with one recursive verification) increases to 74ms, and Phase 3 (Turn 3) (with two recursive verifications) reaches 93ms. This linear scal- ing in recursive depth is the fundamental cost of ensuring execution sequence integrity: each additional turn crypto- graphically validates all previous computation, preventing proof chain manipulation or execution reordering attacks. The proof size similarly scales linearly with recursive depth (737KB for Turn 1, 987KB for Turn 2, 1236KB for Turn 3), reflecting the embedded verification history. Despite this linear growth, millisecond-level verification times remain practical for real-world deployment scenarios where crypto- graphic execution ordering guarantees are critical security requirements. This asymmetric cost structure—expensive proof generation concentrated at the prover, with efficient verification distributed to multiple verifiers—enables scal- able multi-party verification in decentralized agent ecosys- tems without requiring verifiers to re-execute the complete agent workflow. Overall, the zkVM evaluation demonstrates that the BAID authentication protocol achieves practical perfor- mance characteristics suitable for real-world deployment, with asymmetric costs favoring verifiers over provers in high-security authentication scenarios. 6. Related Work Trustworthy AI agent collaboration requires three inter- connected capabilities: standardized communication proto- cols, robust identity authentication, and operator account- ability mechanisms. While existing research has advanced each dimension independently, a critical gap remains: no unified system simultaneously ensures agent identity in- tegrity, operator accountability, and cross-protocol interop- erability. We organize related work along these dimensions and identify limitations motivating our approach. Agent Communication Protocols. The field of agent communication protocols has witnessed significant devel- opments with several sophisticated frameworks emerging. Model Context Protocol (MCP) introduced by Anthropic An- thropic (2024); Model Context Protocol Specification Au- thors (2025); Schmid (2025) establishes a comprehensive framework for contextual information exchange. Agent-to- Agent (A2A) Protocol Surapaneni et al. (2025); Agent2Agent Protocol Specification Authors (2025), developed by Google, represents a breakthrough in opaque agent interoperability. Agent Communication Protocol (ACP) LF AI & Data Foun- dation (2025) focuses on local network-prioritized commu- nication. Additionally, several novel frameworks have been proposed: ANP (Agent Network Protocol) ? facilitates large- scale agent networking; LMOS (Language Model Operating System) ? by Eclipse integrates LLMs into system-level operations; and the Agent Protocol ? offers an open-source, framework-agnostic standard based on OpenAPI v3 for man- aging agent lifecycles (start, stop, monitor). Despite their technical sophistication, these protocols share a fundamental limitation: the absence of a unified, trusted layer for agent registration and discovery, creating significant barriers to cross-protocol identity verification and trusted collaboration environments. Identity Authentication Frameworks. Identity authen- tication frameworks, serving as fundamental infrastructure for trusted agent collaboration, have achieved significant advancements. Contemporary frameworks predominantly build upon OAuth 2.0 Hardt (2012) and OpenID Con- nect Sakimura et al. (2014). While OAuth 2.0’s Client Cre- dentials flow theoretically enables agent authentication, its implementation reveals substantial limitations: the client_id mechanism lacks cross-platform universality, and existing ID Tokens exclusively identify human users while Access Tokens fail to encapsulate agent capabilities. To address these limitations, South et al. South et al. (2025) proposed the Authenticated Delegation framework, extending OAuth 2.0 and OpenID Connect with Agent-ID Tokens incorpo- rating unique agent identifiers, capability manifests, and delegation metadata. However, this approach faces three key limitations: centralization dependencies limiting cross- domain agent identification; domain boundaries restricting system integration; and security vulnerabilities arising from centralized identity data management creating single points of failure. Moreover, these traditional frameworks funda- mentally rely on key-based authentication, where identity is proven by possession of a private key rather than the integrity of the executing code. This creates a semantic gap for autonomous agents: proving “who holds the key” does not guarantee “what code is running,” leaving systems vulnerable to code substitution attacks where malicious agents generate valid signatures. While emerging Verifiable Computation paradigms, particularly Zero-Knowledge Vir- tual Machines (zkVM) and zkTLS, offer theoretical foun- dations for code-level authentication and communication provenance, they have yet to be integrated into a unified, practical agent identity framework that simultaneously en- sures execution integrity and privacy. Agent Identity Management Systems. Academic re- search has produced several groundbreaking approaches to agent identity management, which can be categorized into foundational identity infrastructures and decentralized trust frameworks. In the first category, Chan et al. Chan et al. First Author et al.: Preprint submitted to Elsevier Page 11 of 18 === PAGE 12 === Short Title of the Article (2024) pioneered the conceptual framework for AI sys- tem identity markers, creating criteria for accessibility and verifiability. This was further operationalized by Huang et al. with the Agent Name Service (ANS) Huang et al. (2025), which implements unified registration and resolu- tion through DNS-style naming and PKI. Advancing this further, Raskar et al. Raskar et al. (2025a) proposed hybrid indexing approaches that integrate with existing DNS/PKI, leading to the NANDA (Beyond DNS) Raskar et al. (2025b) framework. NANDA combines a global Core Index with a verifiable AgentFact framework to enable trusted discovery. Complementing these foundational layers, emerging decentralized trust frameworks address the specifics of agent autonomy and ethics. The LOKA protocol ? serves as a decentralized identity framework specifically target- ing accountability and ethical consistency, implementing a blockchain-based trust layer to govern agent interactions. Similarly, ERC-8004 ? introduces “Trustless Agents” via an on-chain validation registry, allowing agents to submit verifiable proofs of their work. However, while these sys- tems successfully implement technical registration and dis- covery mechanisms, they predominantly focus on “agent-to- system” trust—verifying that the agent is a technically valid and recognizable entity within the network. They largely overlook the critical “human-to-agent” liability binding— cryptographically anchoring the agent’s actions to a specific natural person to ensure legal accountability. This omission makes it difficult to establish the comprehensive responsi- bility chains necessary for autonomous deployment. To address these critical gaps, we propose the BAID (Binding Agent ID) framework, which implements an in- novative dual-mechanism approach combining local bind- ing and on-chain identity verification. This comprehensive solution not only bridges the technical gaps in responsibility binding but also establishes a robust foundation for secure AI agent operations in complex social collaboration environ- ments. Our framework represents a significant advancement in reconciling technical identification requirements with le- gal traceability demands, offering a practical path forward for responsible AI agent deployment. 7. Conclusion This paper presents BAID (Binding Agent ID), a com- prehensive identity infrastructure addressing the fundamen- tal challenge of autonomous AI agents: the absence of trace- able and accountable responsibility chains. BAID imple- ments the Binding Agent Model through three integrated mechanisms: (1) local binding via biometric authentication ensures agents serve only their designated owners, prevent- ing command injection attacks; (2) on-chain identity regis- tration via blockchain smart contracts enables trusted agent discovery and establishes publicly auditable user-agent bind- ing declarations; (3) zkVM-based authentication protocol provides cryptographic guarantees for operator identity ver- ification, agent configuration integrity, and complete ex- ecution provenance through recursive proof composition. This unified framework addresses the five critical security requirements identified in cross-organizational agent inter- actions: user identity verification, trusted discovery, mutual authentication, permission control, and accountability track- ing. Our implementation and evaluation demonstrate practi- cal deployability: blockchain identity management achieves viable gas consumption for real-world Ethereum deploy- ment, while zkVM authentication exhibits millisecond-level verification latency suitable for security-prioritized scenar- ios despite proof generation overhead. Future work should address performance optimization to enable broader adop- tion beyond specialized high-security use cases. References Agent2Agent Protocol Specification Authors, 2025. Agent2agent (a2a) protocol specification. https://github.com/google/A2A. Accessed: 2025- 10-31. Anil, C., Durmus, E., Rimsky, N., Sharma, M., Benton, J., Kundu, S., Bat- son, J., Tong, M., Mu, J., Ford, D.J., Mosconi, F., Agrawal, R., Schaeffer, R., Bashkansky, N., Svenningsen, S., Lambert, M., Radhakrishnan, A., Denison, C., Hubinger, E.J., Bai, Y., Bricken, T., Maxwell, T., Schiefer, N., Sully, J., Tamkin, A., Lanham, T., Nguyen, K., Korbak, T., Kaplan, J., Ganguli, D., Bowman, S.R., Perez, E., Grosse, R.B., Duvenaud, D., 2024. Many-shot jailbreaking, in: NeurIPS 2024. (OpenReview preprint). Anthropic, 2024. Model context protocol (mcp). https://www.anthropic. com/news/model-context-protocol. Accessed: 2025-10-31. Buterin, V., 2014. Ethereum: A next-generation smart contract and de- centralized application platform. https://ethereum.org/en/whitepaper. Accessed: 2025-11-18. Chan, A., Kolt, N., Wills, P., Anwar, U., Schroeder de Witt, C., Rajkumar, N., Hammond, L., Krueger, D., Heim, L., Anderljung, M., 2024. Ids for ai systems. URL: https://arxiv.org/abs/2406.12137, doi:10.48550/ arXiv.2406.12137, arXiv:2406.12137. Chan, A., Salganik, R., Markelius, A., Pang, C., Rajkumar, N., Krashenin- nikov, D., Langosco, L., He, Z., Duan, Y., Carroll, M., et al., 2023. Harms from increasingly agentic algorithmic systems, in: Proceedings of the 2023 ACM Conference on Fairness, Accountability, and Trans- parency, pp. 651–666. Chen, C., Parker, L., 2024. Composable contracts for multi-agent coor- dination, in: Agentic Markets Workshop at ICML 2024. URL: https: //openreview.net/forum?id=hq0lZ9u68G. workshop (Poster). Goldwasser, S., Micali, S., Rackoff, C., 1985. The knowledge complexity of interactive proof systems, in: STOC ’85, pp. 291–304. doi:10.1145/ 22145.22178. Guo, T., Chen, X., Wang, Y., Chang, R., Pei, S., Chawla, N.V., Wiest, O., Zhang, X., 2024. Large language model based multi-agents: A survey of progress and challenges. arXiv preprint arXiv:2402.01680 . Hardt, D., 2012. The oauth 2.0 authorization framework. RFC 6749. URL: https://www.rfc-editor.org/rfc/rfc6749, doi:10.17487/RFC6749. section 4.4: Client Credentials Grant. Huang, K., Narajala, V.S., Habler, I., Sheriff, A., 2025. Agent name service (ans): A universal directory for secure ai agent discovery and interoperability. URL: https://arxiv.org/abs/2505.10609, doi:10.48550/ arXiv.2505.10609, arXiv:2505.10609. Huang, S., Siddarth, D., Lovitt, L., Liao, T.I., Durmus, E., Tamkin, A., Ganguli, D., 2024. Collective constitutional AI: Aligning a language model with public input, in: Proceedings of the 2024 ACM Conference on Fairness, Accountability, and Transparency (FAccT ’24), ACM. pp. 1395–1417. doi:10.1145/3630106.3658979. Kirk, H.R., Whitefield, A., R"ottger, P., Bean, A., Margatina, K., Ciro, J., Mosquera, R., Bartolo, M., Williams, A., He, H., Vidgen, B., Hale, S.A., 2024. The prism alignment project: What participatory, representative and individualised human feedback reveals about the subjective and First Author et al.: Preprint submitted to Elsevier Page 12 of 18 === PAGE 13 === Short Title of the Article multicultural alignment of large language models. arXiv preprint arXiv:2404.16019 . LF AI & Data Foundation, 2025. Acp joins forces with a2a under the linux foundation. Community blog. URL: https://lfaidata.foundation/communityblog/2025/08/29/ acp-joins-forces-with-a2a-under-the-linux-foundations-lf-ai-data/. accessed: 2025-09-24. Model Context Protocol Specification Authors, 2025. Model con- text protocol (mcp) specification. https://modelcontextprotocol.io/ specification/2025-03-26. Accessed: 2025-10-31. Nakamoto, S., 2008. Bitcoin: A peer-to-peer electronic cash system. https: //bitcoin.org/bitcoin.pdf. Accessed: 2025-11-18. Nomic Foundation, 2024. Hardhat: Ethereum development environment for professionals. https://github.com/NomicFoundation/hardhat. Accessed: 2025-11-08. OpenAI, 2024. Model Spec. https://cdn.openai.com/spec/ model-spec-2024-05-08.html. Accessed: 2024-09. Pauwels, P., 2021. zkKYC: A solution concept for KYC without knowing your customer, leveraging self-sovereign identity and zero-knowledge proofs. Cryptology ePrint Archive, Paper 2021/907. URL: https: //eprint.iacr.org/2021/907. accessed: 2025-11-18. Raskar, R., Chari, P., Grogan, J.J., Lambe, M., Lincourt, R., Bala, R., Joshi, A., Singh, A., Chopra, A., Ranjan, R., Gupta, S., Stripelis, D., Gorskikh, M., Wang, S., 2025a. Upgrade or switch: Do we need a next-gen trusted architecture for the internet of ai agents? URL: https: //arxiv.org/abs/2506.12003, arXiv:2506.12003. Raskar, R., Chari, P., Zinky, J., Lambe, M., Grogan, J.J., Wang, S., Ranjan, R., Singhal, R., Gupta, S., Lincourt, R., Bala, R., Joshi, A., Singh, A., Chopra, A., Stripelis, D., B, B., Kumar, S., Gorskikh, M., 2025b. Beyond dns: Unlocking the internet of ai agents via the nanda index and verified agentfacts. URL: https://arxiv.org/abs/2507.14263, arXiv:2507.14263. RISC Zero, 2024. Risc zero: A zero-knowledge verifiable general com- puting platform based on zk-starks and the risc-v microarchitecture. https://github.com/risc0/risc0. Accessed: 2025-11-08. Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., 2014. Openid connect core 1.0 (incorporating errata set 1). OpenID Foundation Specification. URL: https://openid.net/specs/ openid-connect-core-1_0.html. original publication: 26 Feb 2014; up- dated with Errata Set 1 Nov 2014. Schmid, P., 2025. Mcp introduction. https://www.philschmid.de/ mcp-introduction. Accessed: 2025-10-31. South, T., Marro, S., Hardjono, T., et al., 2025. Authenticated delegation and authorized ai agents. arXiv preprint arXiv:2501.09674 . Sporny, M., Guy, A., Sabadello, M., Reed, D., 2022. Decentralized identifiers (dids) v1.0. W3C Recommendation. URL: https://www.w3. org/TR/did-core/. accessed: 2025-11-18. Sporny, M., et al., 2025. Verifiable credentials data model v2.0. W3C Recommendation. URL: https://www.w3.org/TR/vc-data-model-2.0/. accessed: 2025-11-18. Surapaneni, R., Jha, M., Vakoc, M., Segal, T., 2025. Announcing the agent2agent protocol (a2a). Google for Developers Blog. URL: https://developers.googleblog.com/en/ a2a-a-new-era-of-agent-interoperability/. accessed: 2025-10-31. Tran, K.T., Dao, D., Nguyen, M.D., Pham, Q.V., O’Sullivan, B., Nguyen, H.D., 2025. Multi-agent collaboration mechanisms: A survey of llms. arXiv preprint arXiv:2501.06322 URL: https://arxiv.org/abs/2501. 06322. Verma, P., 2023a. The rise of ai fake news is creating a ’misinformation superspreader’. Washington Post . Verma, P., 2023b. They thought loved ones were calling for help. it was an ai scam. Washington Post . Wallace, E., Xiao, K., Leike, R., Weng, L., Heidecke, J., Beutel, A., 2024. The instruction hierarchy: Training llms to prioritize privileged instructions. arXiv preprint arXiv:2404.13208 . Wang, L., Ma, C., Feng, X., Zhang, Z., Yang, H., Zhang, J., Chen, Z., Tang, J., Chen, X., Lin, Y., et al., 2024a. A survey on large language model based autonomous agents. Frontiers of Computer Science 18, 186345. Wang, L., Ma, C., Feng, X., et al., 2024b. A survey on large language model based autonomous agents. Frontiers of Computer Science 18, 186345. Xi, Z., Chen, W., Guo, X., He, W., Ding, Y., Hong, B., Zhang, M., Wang, J., Jin, S., Zhou, E., Zheng, R., Fan, X., Wang, X., Xiong, L., Zhou, Y., Wang, W., Jiang, C., Zou, Y., Liu, X., Yin, Z., Dou, S., Weng, R., Qin, W., Zheng, Y., Qiu, X., Huang, X., Zhang, Q., Gui, T., 2025. The rise and potential of large language model based agents: a survey. Science China Information Sciences 68, 121101. URL: https://link.springer.com/ article/10.1007/s11432-024-4222-0, doi:10.1007/s11432-024-4222-0. re- view article. Yan, F., Hu, Q.J., Jiang, N., Sun, X., 2024. Get it cooperating: Enhancing generative agent cooperation with commitment devices, in: Agentic Markets Workshop at ICML 2024. URL: https://openreview.net/forum? id=J39bW48ipI. workshop (Oral). Zou, A., Phan, L., Wang, J., Duenas, D., Lin, M., Andriushchenko, M., Wang, R., Kolter, Z., Fredrikson, M., Hendrycks, D., 2024. Improv- ing alignment and robustness with circuit breakers. arXiv preprint arXiv:2406.04313 . A. zkVM-based Authentication Protocol Technical Specifications This appendix provides comprehensive technical specifi- cations for the zkVM-based verifiable computation protocol that establishes cryptographic guarantees for agent identity integrity, operator authentication, and execution provenance. The protocol addresses the fundamental challenge in au- tonomous AI systems—ensuring the correct agent is used by the correct user in the correct manner—thereby constructing an end-to-end trust chain from identity validation to execu- tion auditing. A.1. Limitations of Key-Based Authentication Traditional software authentication relies on digital sig- nature schemes where possession of private key 𝑠𝑘enables signing operations that prove ownership. While effective for human-controlled systems, this paradigm exhibits a critical vulnerability when applied to autonomous agents: key com- promise enables arbitrary code substitution. An adversary obtaining the agent’s signing key 𝑠𝑘can: (1) execute malicious code 𝑃malicious instead of legitimate program 𝑃legitimate; (2) generate valid signatures 𝜎= Sign𝑠𝑘(output) over malicious outputs; (3) present outputs as originating from the legitimate agent. Verification Verify𝑝𝑘(output, 𝜎) succeeds, yet computation violates intended behavior, break- ing the assumption that cryptographic authenticity implies behavioral integrity. Unlike human users, software agents lack physical em- bodiment amenable to conventional biometric authentica- tion. The agent’s identity is inherently tied to its computa- tional behavior—the code it executes. Traditional authenti- cation verifies the credential holder, not the executing code, creating a semantic gap between “who holds the key” and “what code is running.” A.2. Code-Level Authentication We introduce code-level authentication, a cryptographic identity model where the program binary serves as the agent’s unique identity marker, shifting authentication from First Author et al.: Preprint submitted to Elsevier Page 13 of 18 === PAGE 14 === Short Title of the Article key-based ownership proofs to code-based execution verifi- cation. Based on the zkVM five-tuple from Section 2: Π = (Setup, CommitProg, Compile, Prove, Verify), Definition 1 (Execution Integrity Relation). The pro- tocol proves: exec = {(𝑃, 𝑥𝑝𝑢𝑏, 𝑥𝑝𝑟𝑣, 𝑦) ∶𝑃(𝑥𝑝𝑢𝑏, 𝑥𝑝𝑟𝑣) = 𝑦 ∧CommitProg(𝑃) = 𝐶𝑃} (4) where 𝑃is the agent program, 𝑥𝑝𝑢𝑏are public inputs, 𝑥𝑝𝑟𝑣 are private inputs, and 𝑦is the public output. Property 1 (Code Substitution Resistance). Any mod- ification to 𝑃yields CommitProg(𝑃′) ≠𝐶𝑃, causing proof construction to fail during zkVM constraint verification. Security Framework. The security framework of zkVM encompasses three fundamental guarantees: • Completeness: For any valid statement, an honest prover can consistently generate proofs that are ac- cepted by the verification algorithm with probability 1. • Soundness: For any invalid statement, no computa- tionally bounded adversarial prover can generate an accepting proof, except with negligible probability in the security parameter. The verification algorithm systematically rejects proofs of false statements. • Zero-Knowledge: For any valid statement, the proof reveals no information beyond its validity. Specifi- cally, the verifier gains no computational advantage in deriving any additional knowledge about the private inputs or intermediate computation states. A.3. zkVM-Based Agent Authentication Protocol Workflow The protocol workflow comprises four phases: Initialization: (𝑝𝑝, 𝑣𝑘) ←Setup(1𝜆, 𝑝𝑎𝑟𝑎𝑚) generates system parameters. Registration: Compile agent code to obtain (ArithDesc, MapIO) ←Compile(𝑝𝑝, 𝑃); generate commitment 𝐶𝑃←CommitProg(𝑃); construct 𝖠𝗀𝖾𝗇𝗍𝖨𝖣following Equation (1); anchor 𝖠𝗀𝖾𝗇𝗍𝖨𝖣 to blockchain smart contract. Execution: For each step 𝑘, generate proof 𝜋𝑘 ← Prove(𝑝𝑝, 𝐶𝑃, ArithDesc, MapIO, 𝑥𝑝𝑢𝑏, 𝑥𝑝𝑟𝑣, 𝑦) where exe- cution trace Trace(𝑃, 𝑥𝑝𝑢𝑏, 𝑥𝑝𝑟𝑣) is validated through con- straint templates. Verification: Compute 𝑏←Verify(𝑣𝑘, 𝐶𝑃, 𝑥𝑝𝑢𝑏, 𝑦, 𝜋), confirming proof validity and code commitment 𝐶𝑃matches the registered 𝖠𝗀𝖾𝗇𝗍𝖨𝖣value. A.4. Execution Continuity Across Conversational Turns A.4.1. Problem Statement LLM-based agents operate through conversational state transitions involving user input reception, remote LLM API invocation, tool execution, and state updates. A fundamental zkVM constraint is that while individual proofs can certify that a computation correctly transforms a given input to its output, they do not verify the provenance of inputs. Given execution sequence: 𝑆0 𝑎1,𝑓1 ←←←←←←←←←←←→𝑆1 𝑎2,𝑓2 ←←←←←←←←←←←→𝑆2 𝑎3,𝑓3 ←←←←←←←←←←←→⋯ 𝑎𝑛,𝑓𝑛 ←←←←←←←←←←←→𝑆𝑛 (5) where 𝑎𝑖are actions and 𝑓𝑖are transition functions, standard zkVM can generate independent proofs {𝜋1, 𝜋2, … , 𝜋𝑛}. Each 𝜋𝑖proves: “given some value claimed to be 𝑆𝑖−1, the computation 𝑓𝑖(𝑆𝑖−1, 𝑎𝑖) correctly produces 𝑆𝑖.” However, 𝜋𝑖does not verify that this 𝑆𝑖−1 is actually the output from 𝜋𝑖−1. Without cryptographic binding between proofs, a ver- ifier receiving {𝜋1, 𝜋2} cannot distinguish: valid sequence 𝑆0 𝜋1 ←←←←←←→𝑆1 𝜋2 ←←←←←←→𝑆2; invalid permutation 𝑆0 𝜋2 ←←←←←←→𝑆′ 2 𝜋1 ←←←←←←→𝑆′ 1; or invalid replay 𝑆0 𝜋1 ←←←←←←→𝑆1 𝜋1 ←←←←←←→𝑆1. Input provenance independence breaks execution ordering guarantees. A.4.2. Recursive Proof Algorithm We leverage zkVM’s recursive verification capability— where the zkVM’s Prove algorithm can verify another zkVM proof within its execution—to construct proof chains with cryptographically enforced sequential dependencies. Recursive Verification Program. Define special pro- gram 𝑃rec with functionality: 𝑃rec(𝑣𝑘, 𝐶𝑃, 𝑥𝑝𝑢𝑏,𝑘−1, 𝑦𝑘−1, 𝜋𝑘−1) →{0, 1} (6) This program executes Verify(𝑣𝑘, 𝐶𝑃, 𝑥𝑝𝑢𝑏,𝑘−1, 𝑦𝑘−1, 𝜋𝑘−1) within the zkVM, outputting the verification result. Proof Chain Construction. For execution sequence 𝑆0 →𝑆1 →⋯→𝑆𝑇, step 𝑘generates compound proof: 𝜋𝑘←Prove(𝑝𝑝, 𝐶𝑃, ArithDesc𝑘, MapIO𝑘, 𝑥𝑝𝑢𝑏,𝑘, 𝑥𝑝𝑟𝑣,𝑘, 𝑦𝑘) (7) where: • 𝑥𝑝𝑢𝑏,𝑘contains complete previous proof 𝜋𝑘−1, pro- gram commitment 𝐶𝑃, verification key 𝑣𝑘, previous output 𝑦𝑘−1, and previous claim 𝑥𝑝𝑢𝑏,𝑘−1 • 𝑥𝑝𝑟𝑣,𝑘contains current witness data • Constraint template ArithDesc𝑘includes call to 𝑃rec(𝑣𝑘, 𝐶𝑃, 𝑥𝑝𝑢𝑏,𝑘− Security Properties. Property 2 (Unforgeability of Execution Order). For proof chain {𝜋1, 𝜋2, … , 𝜋𝑇}, by induction on 𝑘: First Author et al.: Preprint submitted to Elsevier Page 14 of 18 === PAGE 15 === Short Title of the Article • Base case (𝑘= 1): 𝜋1 ←Prove(𝑝𝑝, 𝐶𝑃, ArithDesc1, MapIO1, 𝑥𝑝𝑢𝑏,1, 𝑥𝑝𝑟𝑣,1, 𝑦1) where 𝑥𝑝𝑢𝑏,1 contains no dependencies (initial step), Verify(𝑣𝑘, 𝐶𝑃, 𝑥𝑝𝑢𝑏,1, 𝑦1, 𝜋1) = 1 validates directly. • Inductive step: Assume for 𝑘−1, Verify(𝑣𝑘, 𝐶𝑃, 𝑥𝑝𝑢𝑏,𝑘−1, 𝑦𝑘−1, 𝜋𝑘−1) = 1. For step 𝑘, recursive verification program 𝑃rec exe- cutes within zkVM: (1) Extract previous proof 𝜋𝑘−1 from 𝑥𝑝𝑢𝑏,𝑘; (2) Verify parent proof: 𝑏𝑘−1 ←Verify(𝑣𝑘, 𝐶𝑃𝑘−1, 𝑥𝑝𝑢𝑏,𝑘−1, 𝑦𝑘−1, 𝜋𝑘−1); (3) If 𝑏𝑘−1 = 0, 𝑃rec fails, cannot generate 𝜋𝑘; (4) If 𝑏𝑘−1 = 1, generate integrated proof 𝜋𝑘, whose verification implies validity of 𝜋𝑘−1. Therefore: Verify(𝑣𝑘, 𝐶𝑃, 𝑥𝑝𝑢𝑏,𝑘, 𝑦𝑘, 𝜋𝑘) = 1 ⟹Verify(𝑣𝑘, 𝐶𝑃, 𝑥𝑝𝑢𝑏,𝑘−1, 𝑦𝑘−1, 𝜋𝑘−1) = 1. Corollary. Successful verification of final proof 𝜋𝑇im- plies the entire execution sequence 𝑆0 →𝑆1 →⋯→𝑆𝑇 validates in order, with no permutation or substitution. Property 3 (Fail-Stop Security). If any intermediate step 𝑡< 𝑇verification fails, i.e., Verify(𝑣𝑘, 𝐶𝑃, 𝑥𝑝𝑢𝑏,𝑡, 𝑦𝑡, 𝜋𝑡) = 0, then: (1) Step 𝑡+ 1’s recursive verification program 𝑃rec detects failure when verifying 𝜋𝑡(condition C2 unsatisfied); (2) 𝑃rec execution fails, triggering constraint violation; (3) zkVM cannot generate valid proof 𝜋𝑡+1 for step 𝑡+1; (4) All subsequent steps 𝑡+ 2, 𝑡+ 3, … , 𝑇likewise cannot generate proofs. Broken proof chains cannot be extended. Attackers can- not “skip over” failed steps—each proof 𝜋𝑡+1 cryptograph- ically embeds verification of 𝜋𝑡within its recursive proof; missing or invalid 𝜋𝑡causes verification failure inside 𝑃rec. Property 4 (Compact Verification). External verifiers need only check the final proof 𝜋𝑇: • Verification complexity: (log 𝑇) ⋅|ArithDesc| (STARK verification scales logarithmically; |ArithDesc| is constant) • Proof size: |𝜋𝑇| = (1) (constant size 150-250 KB, independent of execution length 𝑇) • Recursive embedding: All historical validations {𝜋1, … , 𝜋𝑇−1} are recursively verified and embedded into 𝜋𝑇through the public input 𝑥𝑝𝑢𝑏,𝑇 A.5. External Communication Provenance A.5.1. Problem Statement zkVM operates within an isolated execution environ- ment that cannot directly access network resources or verify external data sources. When an agent invokes external tools (e.g., web search APIs, databases), remote LLM services (e.g., OpenAI GPT-4, Anthropic Claude), or other agents (in multi-agent systems), the zkVM cannot distinguish authentic API responses from fabricated data provided by the external environment. An adversary controlling the execution environment can: (1) Intercept the agent’s intended API call (e.g., query to LLM service); (2) Replace the genuine response with attacker-controlled content; (3) Feed the fabricated data to the zkVM’s Prove algorithm. The zkVM generates a valid proof 𝜋over the tampered input, yet the computation violates the agent’s declared behavior. The proof attests to computational correctness, not data provenance. A.5.2. zkTLS Integration for Verifiable HTTPS Communications We adopt zkTLS (Zero-Knowledge Transport Layer Security) to establish cryptographic provenance for external communications. zkTLS extends TLS with zero-knowledge proofs, enabling an agent to prove properties about HTTPS sessions (e.g., “I received data 𝑑from server 𝑆”) without revealing the session contents to third parties. Standard TLS Workflow: 1. Handshake: Client and server exchange certificates, negotiate cipher suite, derive session keys 2. Data Transfer: Application data is encrypted with session keys, authenticated with AEAD (e.g., AES- GCM) zkTLS Extension: 1. Transcript Recording: The client (agent) records the complete TLS transcript, including handshake mes- sages and encrypted data 2. Zero-Knowledge Proof Generation: The client gener- ates a proof asserting that: (a) The TLS handshake is valid (certificate chain verified, session keys correctly derived) (b) Specific data fields 𝑑were present in the server’s response (c) The proof reveals no information about the full response content or session keys Protocol Integration with zkVM. For each external communication at step 𝑘: Step1: TLS Session Execution (External Environ- ment). The execution environment: (1) Initiates TLS con- nection to target server 𝑆(e.g., api.openai.com); (2) Sends API request (e.g., LLM prompt); (3) Receives encrypted response 𝑐= E𝐾session(𝑑); (4) Records full TLS transcript: 𝑇= (ClientHello, ServerHello, Certificate, 𝑐, …). Step2: Integrated zkVM Execution (Inside zkVM). The zkVM’s Prove algorithm receives: First Author et al.: Preprint submitted to Elsevier Page 15 of 18 === PAGE 16 === Short Title of the Article • Public inputs: server identity 𝑆, data commitment commit(𝑑) • Private witness: TLS transcript 𝑇, session keys 𝐾session The zkVM executes a unified verification and computa- tion circuit that: (a) Validates TLS Communication Provenance: 1. Certificate Validity: Parse X.509 certificate from 𝑇, verify signature chain up to trusted root CA, and check certificate matches server identity 𝑆(DNS name in Subject Alternative Name field) 2. Session Key Derivation: Extract client/server ran- dom nonces from ClientHello/ServerHello, compute Pre-Master Secret (from RSA/ECDHE key exchange), and derive session keys via PRF: 𝐾session = PRF(PMS, nonces, “key expansion”) 3. Data Integrity: Decrypt response 𝑑= D𝐾session(𝑐), and verify AEAD authentication tag (e.g., GCM tag) to ensure 𝑑was not tampered 4. Commitment Binding: Compute commit(𝑑) = 𝐻(𝑑) and check commitment matches the public input (b) Proves Agent Computation with Verified Data: The zkVM proves that the agent’s computation correctly uses the verified data 𝑑: parsing the data, performing busi- ness logic operations, and generating computational outputs. Output: The zkVM generates a single unified proof 𝜋𝑘that cryptographically attests: there exists a valid TLS session with server 𝑆that decrypts to data 𝑑(matching the public commitment 𝐻(𝑑)), and the agent program 𝑃 correctly processed 𝑑to produce the claimed output. This proof binds TLS communication provenance with computa- tion correctness without revealing the private TLS transcript, session keys, or decrypted data. Security Guarantee: An attacker cannot: (1) substitute 𝑑with fabricated data 𝑑′ (breaks hash binding 𝐻(𝑑) ≠ 𝐻(𝑑′)); (2) claim 𝑑came from different server 𝑆′ (breaks TLS certificate verification); (3) modify 𝑑after TLS de- cryption (breaks AEAD authentication tag); or (4) manip- ulate computation with incorrect data (breaks unified proof integrity). A.6. Three-Phase Verification Pipeline The BAID protocol orchestrates agent authentication through three sequential phases, each enforcing specific security invariants: Phase 1 (Operator) →Phase 2 (Config) →Phase 3 (Execution) Each phase generates a proof 𝜋𝑖that feeds into the next phase via recursive proof algorithm, ensuring end-to-end verification. A.6.1. Phase 1: Operator Biometric Authentication Objective: Verify the operator’s identity without reveal- ing biometric templates, ensuring only authorized users can activate the agent. Privacy-Preserving Facial Recognition: 1. Feature Extraction: Capture operator’s face via device camera; extract 128-dimensional embedding 𝐯capture ∈ ℝ128 using a pre-trained neural network (e.g., FaceNet, ArcFace); normalize: 𝐯capture ← 𝐯capture ‖𝐯capture‖. 2. Reference Template Retrieval: Load stored template 𝐯stored ∈ℝ128 from the agent’s security configurations file. 3. zkVM Similarity Computation: Public inputs (sim- ilarity threshold 𝜏, user identifier 𝖴𝗌𝖾𝗋𝖨𝖣); Private witness (𝐯capture, 𝐯stored). Verification logic computes cosine similarity and performs threshold comparison. 4. Output: Proof 𝜋1 where the zkVM generates proof asserting: ∃𝐯capture, 𝐯stored ∶ 𝐯capture ⋅𝐯stored ‖𝐯capture‖‖𝐯stored‖ ≥𝜏 (8) Public output indicates authentication result (true/false), without revealing the actual embedding vectors. The proof 𝜋1 establishes operator authentication as the foundation for subsequent phases. A.6.2. Phase 2: Agent Configuration Integrity Objective: Prove that the agent’s local configuration matches the blockchain-anchored canonical version. Protocol Steps: 1. On-Chain Anchor: The Agent Identifier, defined in Equation (1), is stored in an Ethereum smart contract, where 𝐶𝑃= CommitProg(𝑃) is the program commit- ment and 𝐻(profile) represents the hash of the agent’s security configurations file (containing biometric fea- tures, behavioral rules, and security policies). The 𝖠𝗀𝖾𝗇𝗍𝖨𝖣is anchored at a specific storage slot 𝑠within the contract’s state trie. 2. Merkle Proof Retrieval: The protocol invokes the Ethereum JSON-RPC method eth_getProof( contractAddr, [storageSlot], blockNumber) to retrieve cryptographic proofs linking the on-chain 𝖠𝗀𝖾𝗇𝗍𝖨𝖣 to the blockchain state. The method returns three components: • Account proof: Merkle branch proving the con- tract account’s existence in the state trie • Storage proof: Merkle branch proving that (𝑠, 𝖠𝗀𝖾𝗇𝗍𝖨𝖣) is stored in the contract’s storage trie • Storage root: 𝑟storage from the account state, serv- ing as the verification anchor 3. zkVM Verification: Public inputs (𝑟storage, expected profile hash from 𝖠𝗀𝖾𝗇𝗍𝖨𝖣); Private witness (local security configurations file Configlocal, Merkle proof 𝜋merkle). Verification logic computes 𝐻(Configlocal), verifies it matches profile_hash in 𝖠𝗀𝖾𝗇𝗍𝖨𝖣, recon- structs storage root from leaf, and checks consistency. First Author et al.: Preprint submitted to Elsevier Page 16 of 18 === PAGE 17 === Short Title of the Article 4. Output: Proof 𝜋2 asserting that the local configuration matches the blockchain-anchored version: 𝐻(Configlocal) = profile_hash in 𝖠𝗀𝖾𝗇𝗍𝖨𝖣 The proof binds the storage root 𝑟storage and Merkle proof verification without revealing the configuration contents. The proof 𝜋2 depends on 𝜋1 through recur- sive proof algorithm. A.6.3. Phase 3: Iterative Task Execution Objective: Prove correct execution of agent tasks across multiple conversational turns 𝑡= 1, 2, … , 𝑇, with verified provenance for all external communications. Execution Model per Turn 𝑡: Each conversational turn 𝑡 involves: (1) Input Reception (user query 𝑞𝑡or tool response 𝑟𝑡−1, previous state commitment ℎ𝑡−1 = 𝐻(𝑆𝑡−1)); (2) LLM Invocation (send prompt to remote LLM service, receive response 𝑎𝑡); (3) Tool Execution (execute tool function: 𝑜𝑡= 𝑓𝑎𝑡(params)); (4) State Update (compute new state: 𝑆𝑡= (𝑆𝑡−1, 𝑞𝑡, 𝑎𝑡, 𝑜𝑡)). Integrated Execution Proof per Turn 𝑡: For each con- versational turn 𝑡, generate a single execution proof 𝜋𝑡that integrates zkTLS verification, agent computation, and recur- sive proof algorithm within one zkVM execution. The proof generation proceeds in three stages: 1. Recursive Verification and Dependency Checking: For 𝑡> 1, first verify parent proof 𝜋𝑡−1 validity through zkVM’s recursive verification. This ensures the current turn builds on a verified historical foundation, preventing broken proof chains from extending. 2. zkTLS Verification (Communication Provenance): Execute TLS session validation within zkVM to ensure authenticity of responses from LLM services and remote third-party APIs: verify certificate chain, session key deriva- tion, AEAD authentication, and compute data commitment ℎ𝑎𝑡= 𝐻(𝑎𝑡). 3. Agent Computation Verification (Execution Correct- ness): Verify the agent correctly executes tasks using verified responses from external services: parse action, execute tool call, update state, and compute state commitment ℎ𝑆𝑡= 𝐻(𝑆𝑡). 4. Final Proof after 𝑇Turns: After 𝑇conversational turns, the final proof 𝜋𝑇cryptographically attests to: (1) Ini- tial authentication validity (Phase 1 configuration integrity and Phase 2 operator biometric verification); (2) Complete execution trace across all turns: 𝑆0 →𝑆1 →⋯→𝑆𝑇; (3) Verified provenance of all external service responses: {𝑎1, … , 𝑎𝑇} via zkTLS; (4) Correct agent computation for all tool executions: {𝑜1, … , 𝑜𝑇} following code 𝐶𝑃. External verifiers (eg. counterpart agents, service providers, or regulators) only need to: (1) Receive the final proof 𝜋𝑇; (2) Verify using zkVM’s Verify algorithm: 𝑏←Verify(𝑣𝑘, 𝐶𝑃, 𝑥𝑝𝑢𝑏, 𝑦𝑇, 𝜋𝑇); (3) Check the public outputs match expected values. B. Security Analysis This section analyzes the security properties of the BAID framework, defining the threat model and demonstrating how the proposed protocols defend against critical attacks targeting autonomous agent systems. B.1. Threat Model We consider an adversary with the following capabil- ities: • Key Compromise: may obtain the private signing keys of legitimate users or agents. • Network Control: can intercept, modify, replay, or reorder network messages between agents, users, and external services. • Malicious Execution Environment: may control the computational environment where the agent exe- cutes, enabling manipulation of I/O or substitution of program binaries. • Data Fabrication: can forge responses from exter- nal APIs (e.g., LLMs, web services) to mislead agent execution. We assume the underlying cryptographic primitives (zkVM proof system, hash functions, digital signatures, TLS) are secure. B.2. Security Properties and Defenses B.2.1. Defense Against Code Substitution Attacks Attack: An adversary with a compromised agent private key replaces the legitimate agent program 𝑃with malicious code 𝑃′ to execute unauthorized actions while signing them as the legitimate agent. Defense: BAID implements Code-Level Authentication. The agent’s identity is cryptographically bound to the pro- gram commitment 𝐶𝑃= CommitProg(𝑃). Any modifica- tion to the code results in 𝐶𝑃′ ≠𝐶𝑃. The zkVM proof generation requires the execution trace to satisfy constraints derived from 𝐶𝑃RISC Zero (2024). Therefore, cannot generate a valid proof 𝜋for 𝑃′ that verifies against the legit- imate 𝖠𝗀𝖾𝗇𝗍𝖨𝖣(which contains 𝐶𝑃), effectively preventing code substitution even if keys are compromised. B.2.2. Defense Against Replay and Reordering Attacks Attack: intercepts valid proofs {𝜋1, 𝜋2, …} from a session and replays them or reorders them (e.g., skipping a payment authorization step) to manipulate the agent’s state transition. Defense: BAID employs Recursive Verification to en- force Execution Continuity. Each proof 𝜋𝑡cryptographically embeds the verification of the previous proof 𝜋𝑡−1 as a public input. This creates an immutable, ordered hash chain 𝑆0 → 𝑆1 →⋯→𝑆𝑡. A replayed or reordered proof will fail the recursive verification check 𝑃rec inside the zkVM RISC Zero (2024), as the input state commitment ℎ𝑡−1 will not match the output of the previous valid step. First Author et al.: Preprint submitted to Elsevier Page 17 of 18 === PAGE 18 === Short Title of the Article B.2.3. Defense Against Data Fabrication (Man-in-the-Middle) Attack: controls the network or execution environ- ment and feeds fabricated LLM responses or market data to the agent to trigger incorrect decisions. Defense: BAID integrates zkTLS to ensure Data Prove- nance. The zkVM circuit verifies the TLS handshake and server signatures within the zero-knowledge environment. It proves that the data 𝑑processed by the agent originated from a specific, authenticated server 𝑆(e.g., api.openai.com) and has not been tampered with ?. cannot forge a valid TLS transcript and corresponding zkVM proof without breaking the underlying TLS cryptography. B.2.4. Defense Against Sybil and Impersonation Attacks Attack: creates multiple fake agent identities to flood the network or impersonates a reputable agent. Defense: BAID relies on On-Chain Identity Manage- ment and zkKYC. Agent identities must be bound to a valid User Identity Contract, which requires zkKYC verification of the legal entity Pauwels (2021). This imposes a real- world cost and accountability on identity creation, mitigating Sybil attacks. Furthermore, the on-chain binding of 𝖠𝗀𝖾𝗇𝗍𝖨𝖣 to 𝐶𝑃and 𝖴𝗌𝖾𝗋𝖨𝖣ensures that any impersonation attempt is detectable by verifying the agent’s proofs against the immutable blockchain registry Chan et al. (2024). First Author et al.: Preprint submitted to Elsevier Page 18 of 18