# Agent Trust Gateway Stack

As the AI agent economy expands, autonomous agents are increasingly tasked with interacting with high-value, sensitive resources: executing trades, accessing private data APIs, signing smart contracts, and managing financial instruments. This shift from human-to-machine to machine-to-machine interaction creates a massive trust deficit.

How can a resource provider (a Verifier) trust that an AI agent is authorized by a verified human? And how can the human trust that the agent will not misuse their credentials?

The zkMe Agent Trust Gateway is the solution. It acts as a secure, privacy-preserving middleware layer, a “trust gatekeeper”, that mediates all interactions between AI agents and external resources.

## Core Positioning

The Agent Trust Gateway is **not** an agent execution environment itself. It is the authorization and policy enforcement layer that sits between the agent and the target resource. Its primary functions are:

1. **Real-Time Policy Evaluation.** Checking if an agent’s request complies with the human user’s predefined rules (time windows, value limits, target constraints).
2. **Credential Verification.** Validating the [Agent-Ready Credentials](/hub/how-built/credential-sys/agent-ready-credentials.md) (and underlying user credentials) presented by the agent against on-chain state.
3. **Secure Context Provisioning.** Injecting verified data or authorization tokens into the agent’s context only when all conditions are met, inside a hardware-secured enclave.

***

## Architectural Components

The Gateway is designed with a hardware-grade security foundation to ensure that even the gateway operators cannot tamper with the verification process or access sensitive data.

```
               ┌────────────────────────────────────────────────────────┐
               │                    TEE Enclave                         │
               │  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  │
               │  │   Policy     │  │  Credential  │  │   Protocol   │  │
               │  │   Engine     │  │  Verifier    │  │   Adapters   │  │
               │  │              │  │              │  │              │  │
               │  │ Time/Freq    │  │ Signature    │  │ MCP Server   │  │
               │  │ Value/Risk   │  │ Revocation   │  │ x402/APF     │  │
               │  │ Target       │  │ Expiration   │  │ OIDC4VP      │  │
               │  │ Constraints  │  │ Merkle Root  │  │ W3C VC/DID   │  │
               │  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘  │
               │         │                 │                  │         │
               │         └────────┬────────┘──────────────────┘         │
               │                  │                                     │
               │         ┌────────▼────────┐                            │
               │         │  PASETO Token   │                            │
               │         │  Signing        │                            │
               │         └────────┬────────┘                            │
               │                  │                                     │
               │         ┌────────▼────────┐                            │
               │         │  Audit Logger   │                            │
               │         │  (append-only)  │                            │
               │         └─────────────────┘                            │
               └────────────────────────────────────────────────────────┘
```

### TEE Enclave (Trusted Execution Environment)

The core logic of the Gateway runs inside a hardware-secured Trusted Execution Environment (e.g., Intel SGX or AMD SEV). This provides three critical guarantees:

<table><thead><tr><th width="183.484375">Guarantee</th><th>What It Means</th></tr></thead><tbody><tr><td><strong>Confidentiality</strong></td><td>Data processed inside the enclave (decrypted credentials, user policies, session keys) cannot be read by the host operating system, the infrastructure provider, or even zkMe itself.</td></tr><tr><td><strong>Integrity</strong></td><td>The code running inside the enclave cannot be modified without detection. Any tampering attempt invalidates the enclave’s attestation.</td></tr><tr><td><strong>Remote Attestation</strong></td><td>The Gateway can cryptographically prove to external parties (users, agents, and verifiers) that it is running the correct, unmodified zkMe Gateway code inside a genuine TEE. This proof is verifiable by anyone.</td></tr></tbody></table>

The TEE enclave is the reason the Gateway can handle sensitive operations (credential decryption, policy evaluation, token signing) without requiring users to trust the gateway operator. The hardware itself enforces the security guarantees.

### Policy Engine

The Policy Engine evaluates incoming agent requests against the authorization policies set by the human user (the Agent Principal). Policies are defined at delegation time and stored encrypted in the [zkVault](/hub/how-built/id-infra/zkvault.md).

Policies can be defined across multiple dimensions:

<table><thead><tr><th width="171.625">Dimension</th><th>Example Rules</th></tr></thead><tbody><tr><td><strong>Time / Frequency</strong></td><td><ul><li>“Agent can only trade between 9 AM and 5 PM UTC.” </li><li>“Maximum 5 requests per hour.” </li><li>“Delegation expires after 24 hours.”</li></ul></td></tr><tr><td><strong>Value / Risk</strong></td><td><ul><li>“Maximum transaction value of $1,000 per action.” </li><li>“Maximum cumulative spend of $10,000 per day.” </li><li>“Block any action flagged as high-risk by KYT.”</li></ul></td></tr><tr><td><strong>Target Constraints</strong></td><td><ul><li>“Agent can only interact with Uniswap V3 contracts on Ethereum mainnet.” </li><li>“Agent can only access the /api/portfolio endpoint.” </li><li>“Agent cannot interact with any contract not on the whitelist.”</li></ul></td></tr><tr><td><strong>Credential Scope</strong></td><td><ul><li>“Agent can prove user is over 18, but cannot prove user’s exact age.”</li><li>“Agent can prove KYC status, but cannot prove nationality.”</li></ul></td></tr></tbody></table>

If a request violates any policy constraint, the Gateway rejects the request immediately and logs the rejection. The agent receives a structured error response indicating which constraint was violated, without revealing the policy details.

### Credential Verifier

This module interfaces with the [zkMe Credential System](/hub/how-built/credential-sys.md). When an agent presents an Agent-Ready Credential, the Verifier performs the following checks:

1. **Cryptographic signature validation.** Verifies the credential was issued by a trusted zkMe Issuer and has not been tampered with.
2. **Non-revocation check.** Queries the on-chain State Contract to confirm the credential has not been revoked by the Issuer.
3. **Expiration check.** Confirms the credential and the delegation have not expired.
4. **Merkle root verification.** Validates the credential’s claims against the current on-chain Merkle root to ensure state consistency.
5. **Delegation chain validation.** Verifies the cryptographic binding between the agent’s credential and the human user’s underlying identity credential.

### Protocol Adapters

To ensure seamless integration into the existing AI and Web3 ecosystem, the Gateway includes native adapters for standard protocols. Each adapter translates protocol-specific requests into the Gateway’s internal evaluation format and returns protocol-compliant responses.

For detailed documentation on each supported protocol, see [Supported Protocols](/hub/how-built/agent-trust-gateway/supported-protocols.md).

<table><thead><tr><th width="256.3984375">Protocol</th><th>Use Case</th></tr></thead><tbody><tr><td><strong>MCP</strong> (Model Context Protocol)</td><td>AI agent communication. Agents connect as MCP Clients; the Gateway acts as an MCP Server exposing tools via JSON-RPC.</td></tr><tr><td><strong>APF / x402</strong></td><td>Agent payment facilitation. Handles HTTP 402 payment challenges by verifying agent payment credentials and facilitating transactions.</td></tr><tr><td><strong>W3C VC / DID</strong></td><td>Foundational data models. The Gateway natively parses and validates W3C Verifiable Credentials and resolves DIDs.</td></tr><tr><td><strong>ERC-8004</strong></td><td>On-chain agent reputation. Indexes agent reputation tokens and includes them in policy evaluation.</td></tr><tr><td><strong>OIDC4VP</strong></td><td>Web2 bridge. Handles OpenID Connect flows for Verifiable Presentations, enabling integration with traditional OAuth/OIDC services.</td></tr><tr><td><strong>PASETO</strong></td><td>Token issuance. Issues short-lived, scoped authorization tokens using PASETO v4 (stronger security guarantees than JWT).</td></tr></tbody></table>

***

## The Trust Flow

When an agent attempts to access a protected resource via the Gateway, the high-level flow is as follows:

{% stepper %}
{% step %}

### Request

The agent sends an action request (e.g., “Buy 1 ETH on Uniswap”) to the Gateway, attaching its Agent-Ready Credential. The request arrives via one of the supported protocol adapters (e.g., as an MCP tool call).
{% endstep %}

{% step %}

### TEE Ingress

The request enters the TEE enclave. From this point forward, all processing occurs inside the hardware-secured environment.
{% endstep %}

{% step %}

### Credential Verification

The Credential Verifier validates the agent’s credential (signature, revocation, expiration, Merkle root, delegation chain).
{% endstep %}

{% step %}

### Policy Evaluation

The Policy Engine evaluates the request against the user’s stored policies (time, value, target, scope constraints).
{% endstep %}

{% step %}

### Human-in-the-Loop (Optional)

If the policy dictates that the action is high-risk (e.g., exceeds a value threshold), the Gateway pauses execution and sends a push notification to the user’s SSI Wallet for explicit approval. The user can approve, reject, or modify the request.
{% endstep %}

{% step %}

### Context Provisioning / Token Issuance

If approved, the Gateway either:

* Proxies the request directly to the target resource with the necessary authorization, or
* Issues a short-lived, scoped PASETO token to the agent, which the agent presents to the target resource independently.
  {% endstep %}

{% step %}

### **Audit Logging**

The Gateway records a cryptographic hash of the transaction (action type, timestamp, result, policy evaluation outcome) to an append-only audit ledger. The log does not contain the payload itself, preserving privacy while enabling accountability.
{% endstep %}
{% endstepper %}

For the complete 8-step technical specification, see [Agent Session Flow](/hub/how-built/agent-trust-gateway/agent-session-flow.md).

***

## Why the Gateway is Essential

### For Users (Agent Principals)

The Gateway provides a single control panel to monitor, authorize, and instantly revoke access for all AI agents. Users define granular policies that constrain agent behavior, and they can require human approval for high-risk actions. Their digital identity and assets are never exposed to the agents directly; the agent only ever receives scoped, time-limited authorization tokens.

### For Agent Developers

The Gateway removes the liability of handling user PII. Agent developers do not need to implement complex cryptography, credential verification, or compliance checks. They integrate with the Gateway via standard protocols (MCP, OIDC4VP) and receive structured authorization responses. This enables the creation of more powerful, autonomous workflows without the security burden.

### For Verifiers (dApps, APIs, Smart Contracts)

The Gateway offloads the complex burden of verifying agent identity, user authorization, and credential validity. The Verifier only needs to trust the Gateway’s output (a PASETO token or a verified proof). This is backed by the TEE’s remote attestation, which cryptographically proves the Gateway is running unmodified code in a genuine hardware enclave.

***

## Available as Independent Services

The Agent Trust Gateway technology stack is available for licensing and deployment by external organizations. Customers can acquire any capability independently or license the full stack to build and operate their own agent authorization infrastructure using zkMe's TEE execution environment, policy engine, and protocol adapter suite.

<table><thead><tr><th width="211.462890625">Capability</th><th>Acquisition Model</th></tr></thead><tbody><tr><td>TEE-Enclaved Execution</td><td>License the enclave runtime (Intel SGX / AMD SEV integration, remote attestation, secure key management)</td></tr><tr><td>Policy Engine</td><td>License the policy evaluation engine (multi-dimensional rule sets, encrypted policy storage, per-session evaluation)</td></tr><tr><td>Credential Verifier</td><td>License the real-time credential validation module (signature, revocation, expiration, Merkle root, delegation chain checks)</td></tr><tr><td>Protocol Adapters</td><td>License individual adapters (MCP, x402/APF, ERC-8004, OIDC4VP, W3C VC/DID, PASETO v4) or the full adapter suite</td></tr><tr><td>Session Management</td><td>License the 8-step session lifecycle pipeline (OAuth2/PKCE authentication through audit logging)</td></tr><tr><td>Audit Logging</td><td>License the append-only cryptographic logging system with decentralized ledger anchoring</td></tr><tr><td>Human-in-the-Loop</td><td>License the configurable approval workflow engine with push notification integration</td></tr></tbody></table>

{% hint style="success" %}
All modules support flexible engagement models including technology licensing for self-hosted deployment, managed service with pay-as-you-go or committed-use pricing, and full white-label solutions. Contact the zkMe team at <contact@zk.me>.
{% endhint %}


---

# Agent Instructions: 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/agent-trust-gateway.md?ask=<question>
```

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.