> For the complete documentation index, see [llms.txt](https://docs.zk.me/hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zk.me/hub/how-built/credential-sys/agent-ready-credentials.md). # Agent-Ready Credentials As the digital ecosystem evolves toward an agent economy, autonomous AI agents require a secure, verifiable, and privacy-preserving way to prove their identity, capabilities, and permissions on behalf of human users. Traditional identity systems were built for human-to-machine interactions and are fundamentally unsuited for machine-to-machine autonomy. zkMe introduces **Agent-Ready Credentials**, a specialized extension of the zkMe Credential System designed specifically to empower AI agents with verifiable trust. *** ## The Problem: Trust in the Agent Economy When a user delegates a task to an AI agent (e.g., “trade this asset on my behalf” or “book a flight using my loyalty points”), the target platform needs answers to three critical questions: 1. **Agent Authenticity:** Is this agent who it claims to be, or is it a malicious bot spoofing a legitimate agent? 2. **User Authorization:** Did the human user actually authorize this specific agent to perform this specific action? 3. **Data Access:** How can the agent prove the user’s eligibility (e.g., KYC status, credit score) without the platform having to process the user’s raw PII? Traditional API keys and OAuth tokens are brittle, easily leaked, and provide coarse-grained access that violates the principle of least privilege. They also fail to bind the agent’s actions to the user’s verifiable identity in a privacy-preserving manner. *** ## What Are Agent-Ready Credentials? Agent-Ready Credentials are Verifiable Credentials (VCs) that have been optimized for consumption, presentation, and verification by autonomous agents via the [Agent Trust Gateway](/hub/how-built/agent-trust-gateway.md). They differ from standard user credentials in three key ways: ### 1. Cryptographic Delegation Agent-Ready Credentials utilize a secure delegation protocol. When a user authorizes an agent, they do not hand over their root identity keys or raw credentials. Instead, the user’s SSI Wallet generates a mathematically bound “delegate proof” or a constrained proxy credential. This delegation specifies: * **The Agent DID:** The decentralized identifier of the authorized agent. * **The Scope:** The specific claims the agent is allowed to prove (e.g., “can prove user is > 18”, but not “can prove user’s exact age”). * **The Context:** The specific platforms or smart contracts the agent is allowed to interact with. * **The Expiration:** A strict time-to-live (TTL) for the delegation. The delegation is cryptographically bound to both the user’s DID and the agent’s DID. If the agent attempts to use the credential outside the specified scope, context, or time window, the verification will fail. The binding is enforced at the ZK circuit level, making it impossible to circumvent without breaking the underlying cryptographic assumptions. ### 2. Machine-Readable Schemas While all zkMe credentials use JSON-LD schemas, Agent-Ready Credentials are specifically structured to be parsed and reasoned about by LLMs and programmatic logic. The schemas include explicit metadata defining: * **Semantic meaning of claims:** What each claim represents in natural language, allowing an LLM to understand what it holds. * **Presentation triggers:** Conditions under which the credential should be presented (e.g., “present when challenged for KYC status by a DeFi protocol”). * **Proof generation parameters:** The specific ZK circuit, query operators, and disclosure level to use when generating a proof. This machine-readable design means an agent can autonomously determine when and how to use its credentials during a complex, multi-step workflow, without requiring human intervention at each step. ### 3. Automated Proof Generation Agent-Ready Credentials are designed to be integrated directly into the agent’s execution environment via the [Agent Trust Gateway](/hub/how-built/agent-trust-gateway.md). When a target platform challenges the agent for proof of eligibility, the agent can automatically construct the necessary Zero-Knowledge Proof (ZKP) based on the delegated credential, without requiring synchronous human intervention. The proof generation flow: 1. The agent receives a challenge from the target platform (e.g., “prove KYC status”). 2. The agent routes the challenge to the Gateway via MCP or another supported protocol. 3. Inside the TEE enclave, the Gateway retrieves the delegated credential from the zkVault, verifies it is within scope, and generates the ZKP. 4. The Gateway returns the proof to the agent, which presents it to the target platform. At no point does the agent have access to the raw credential data or the user’s private keys. The proof is generated entirely inside the TEE. *** ## How It Works in Practice ### Scenario 1: AI Financial Advisor Applying for a Loan User Bob wants his AI Financial Advisor to apply for a DeFi lending protocol that requires [Proof-of-Credit Score (PCS)](/hub/what/zkobs/zkcredit.md). {% stepper %} {% step %} #### **User Onboarding** Bob completes [zkOBS](/hub/what/zkobs.md) verification via zkMe, which generates a credential attesting to his credit score range (e.g., “score > 700”) and asset holdings without revealing exact figures. {% endstep %} {% step %} #### **Agent Authorization** Bob authorizes the Financial Advisor agent. The delegation specifies: scope = “credit\_score\_range, asset\_bracket” (ranges only, not exact values), target = “LendingProtocol.eth”, TTL = 1 hour, value\_limit = “$50,000 maximum loan request”. {% endstep %} {% step %} #### **Loan Application** The Financial Advisor agent connects to the lending protocol and submits a loan application on Bob’s behalf. {% endstep %} {% step %} #### **Eligibility Check** The lending protocol challenges the agent to prove Bob meets the minimum credit score and collateral requirements. {% endstep %} {% step %} #### **Multi-Credential Proof** The agent routes the challenge to the Gateway. The Gateway generates a [Multi-Credential Proof](/hub/how-built/credential-sys/selective-disclosure.md) combining the credit score credential and the asset holdings credential into a single ZKP using the LinkedMultiQuery circuit. {% endstep %} {% step %} #### **Approval** The lending protocol verifies the combined proof. Bob’s loan is approved. The protocol never sees Bob’s exact credit score, bank name, or account details. {% endstep %} {% endstepper %} ### Scenario 2: AI Trading Agent on a Regulated DeFi Exchange User Alice wants her AI Trading Agent to execute a transaction on a regulated DeFi exchange that requires [Proof-of-Citizenship (PoC)](/hub/what/zkkyc/zkpoc.md). {% stepper %} {% step %} #### **User Onboarding** Alice completes [zkKYC](/hub/what/zkkyc.md) via zkMe and holds a citizenship credential in her wallet. {% endstep %} {% step %} #### **Agent Authorization** Alice authorizes the Trading Agent via her SSI Wallet. The wallet generates a constrained, time-limited delegation allowing the agent to prove her citizenship status specifically to the DeFi exchange’s smart contract. The delegation specifies: scope = “citizenship\_status” (boolean only), target = “0x1234…DeFiExchange”, TTL = 24 hours. {% endstep %} {% step %} #### **Agent Execution** The Trading Agent connects to the DeFi exchange to execute the trade. {% endstep %} {% step %} #### **Challenge** The exchange’s smart contract requires a ZKP of citizenship before processing the trade. {% endstep %} {% step %} #### **Automated Presentation** The agent routes the challenge to the Agent Trust Gateway. Inside the TEE, the Gateway verifies the delegation, generates the ZKP using the delegated credential, and returns the proof. {% endstep %} {% step %} #### **Verification** The smart contract verifies the ZKP on-chain. The trade executes. The exchange never learns Alice’s identity or nationality, and the agent never had access to Alice’s underlying passport data. {% endstep %} {% endstepper %} *** ## Benefits for the Agent Ecosystem ### For Users (Agent Principals) * **Complete control** over what agents can do and prove on their behalf, defined at delegation time. * **Instant revocation** of agent access by updating the on-chain State Contract or expiring the delegation. * **Zero leakage** of raw PII to either the agent developer or the target platform. The agent never sees the underlying credential data. * **Human-in-the-loop** option for high-risk actions, triggered automatically by the Gateway’s Policy Engine. ### For Agent Developers * **Removes the liability** of handling user PII. The agent developer never needs to store, process, or transmit personal data. * **Simplifies integration** with compliance-gated platforms. Instead of implementing KYC/AML checks, the agent presents a proof via the Gateway. * **Enables more powerful workflows.** Agents can autonomously prove user eligibility across multiple platforms in a single session without human intervention. * **Standard protocol support.** Integration via MCP, OIDC4VP, or direct API calls; no custom cryptography required. ### For Platforms (Verifiers) * **Cryptographic assurance** that an interacting agent is authorized by a verified human who meets all regulatory requirements. * **Protection against malicious bots** and Sybil attacks via Nullifier-based uniqueness proofs. * **Zero data liability.** The platform receives only a boolean proof result, not PII. This significantly reduces regulatory burden and data breach risk. * **Reduced integration complexity.** The platform verifies a single proof or PASETO token instead of implementing a full identity verification pipeline. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.zk.me/hub/how-built/credential-sys/agent-ready-credentials.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.