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. 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. 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).

1

User Onboarding

Bob completes zkOBS verification via zkMe, which generates a credential attesting to his credit score range (e.g., “score > 700”) and asset holdings without revealing exact figures.

2

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”.

3

Loan Application

The Financial Advisor agent connects to the lending protocol and submits a loan application on Bob’s behalf.

4

Eligibility Check

The lending protocol challenges the agent to prove Bob meets the minimum credit score and collateral requirements.

5

Multi-Credential Proof

The agent routes the challenge to the Gateway. The Gateway generates a Multi-Credential Proof combining the credit score credential and the asset holdings credential into a single ZKP using the LinkedMultiQuery circuit.

6

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.

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).

1

User Onboarding

Alice completes zkKYC via zkMe and holds a citizenship credential in her wallet.

2

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.

3

Agent Execution

The Trading Agent connects to the DeFi exchange to execute the trade.

4

Challenge

The exchange’s smart contract requires a ZKP of citizenship before processing the trade.

5

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.

6

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.

---

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.