The Gateway That Keeps AI Agents in Check

The Problem

When AI agents access production systems, three questions have no good answer:

1. Who is this agent?

API keys can be stolen. JWTs can be leaked. There's no cryptographic proof tying an action to a specific agent identity.

2. Should this be allowed?

Static RBAC doesn't adapt. Either agents get full access (dangerous) or humans approve everything (slow). No middle ground.

3. Can we prove what happened?

When something goes wrong, logs can be tampered with. You need cryptographic proof of who did what, when, and why.

Know Your Agent (KYA)

The same principles banks use for Know Your Customer (KYC), applied to AI agents. The core loop is the same: identify → assess → authorize → monitor → enforce. Just swapped "customer" for "agent."

Use Cases

Where autonomous agents meet real consequences.

1. DevOps / SRE -- 3am Incident Response

Agent reads logs.......... [AUTO-ALLOW]
Scales up service......... [AUTO-ALLOW]
Deploys hotfix............ [HITL] -- 1 human tap

4 minutes total. Full audit trail. No 3am pages.

2. Finance / Banking -- Automated Transfers

$50 transfer............. [AUTO-ALLOW]
$300 transfer............ [HITL] -- manager approves
$6,000 transfer.......... [AUTO-DENY]

Hard limits enforced. Cryptographic audit for compliance.

3. Healthcare / Pharma -- PHI Access Control

Query public data........ [AUTO-ALLOW]
Access patient records... [HITL]
Bulk data export......... [AUTO-DENY]

HIPAA compliant. PHI access audit with proofs.

Who Benefits

How It Works

Four layers decide every agent action in milliseconds:

Integrates with Any Major Agentic AI

eyeVesa supports seamless integration with top LLM providers and agent frameworks to ensure any autonomous agent can operate securely:

• Claude (Anthropic) — Support via Claude Computer Use + custom MCP tool calling
• OpenAI — Support via OpenAI Agents + function calling to eyeVesa MCP endpoint
• Grok (xAI) — Native support via our Rust SDK
• Gemini, Llama, LangGraph, CrewAI, AutoGen — Supported via standard HTTP/MCP tool calling

Agents interact via our Rust SDK (for native performance), standard MCP Protocol (/v1/mcp), or REST APIs, providing every agent with verified identity, policy enforcement, behavioral monitoring, and auditability.

Core Capabilities

Every agent request passes through decision layers before reaching your production systems.

Quick Start

Get running in under 5 minutes.

Start Infrastructure

docker-compose up -d

Start Gateway

# Terminal 1: Gateway core (Rust proxy)
cd gateway/core && cargo run

# Terminal 2: Control plane (Go API)
cd gateway/control-plane && go run cmd/api/main.go

Register an Agent

curl -X POST http://localhost:8080/v1/agents/register \
  -H "Content-Type: application/json" \
  -d '{"name":"hermes-ops","owner":"org:devops",
       "capabilities":["infrastructure_read","deployment"],
       "allowed_tools":["k8s_deploy","log_search"]}'

Verify Services

curl http://localhost:8080/health     # Control plane
curl http://localhost:9443/health     # Gateway core
curl http://localhost:8181/v1/data/agentid/authz/allow  # OPA

Install

Install the latest CLI from main:

curl -fsSL https://raw.githubusercontent.com/Hafizaljohari/eyeVesa/main/scripts/install.sh | bash

Install from a specific release tag:

VERSION=v0.1.1 curl -fsSL https://raw.githubusercontent.com/Hafizaljohari/eyeVesa/main/scripts/install.sh | bash

Install via Bun:

bunx --bun bash -c "$(curl -fsSL https://raw.githubusercontent.com/Hafizaljohari/eyeVesa/main/scripts/install.sh)"

Install via Homebrew tap:

brew tap Hafizaljohari/eyevesa https://github.com/Hafizaljohari/eyeVesa
brew install eyevesa

Run via Docker:

docker build -t eyevesa-cli -f cli/Dockerfile .
docker run --rm eyevesa-cli --help

Agent-Native Setup

You can let your AI agent (like Hermes, OpenClaw, Claude, Codex, or any terminal-capable assistant) install and verify eyeVesa for you.

Install and run eyeVesa from https://github.com/HafizalJohari/eyeVesa-community.git.
Use the local community sandbox only. Do not request production credentials.
Clone the repo, run ./start.sh, verify health endpoints, and report the local URLs back to me.

Expected Local URLs

Once the agent succeeds, it should verify and report these endpoints:

Safety Boundaries Enforced

The agent is trained to operate with absolute safety. During local community installation, it is instructed to:

• Never ask for GCP/AWS credentials or Terraform state files.
• Never connect to the production environment or the official International Airport.
• Keep database, JWT secrets, and gateway private keys local-only (never commit them to git).

For more details, see the complete Agent-Native Install Guide on GitHub.

SDK

Agent SDKs for Python, Rust, and TypeScript. Every SDK provides cryptographic identity (Ed25519), MCP tool invocation, policy-based authorization, HITL approvals, PTV attestation, agent delegation, skills management, and a transaction protocol with signed capability tokens and receipts.

SDK Comparison

Python SDK

Package: agentid-sdk · Dependencies: httpx, pydantic, PyNaCl

import asyncio
from agentid_sdk import AgentClient, AgentConfig

async def main():
    config = AgentConfig(
        agent_id="my-agent-001",
        name="my-agent",
        owner="my-team",
        gateway_endpoint="http://localhost:9443",
    )
    async with AgentClient(config) as client:
        await client.connect()
        print(f"Trust score: {client.trust_score}")
        tools = await client.discover("mcp")
        result = await client.invoke(
            resource_id="d4385f9f-bcf8-47b9-90f4-b1fce91def59",
            tool="read",
            params={"location": "Kuala Lumpur"},
        )
        print(f"Result: {result.data}")

asyncio.run(main())
        

Rust SDK

Crate: agentid-sdk · Dependencies: tokio, reqwest, ed25519-dalek, serde

use agentid_sdk::{AgentClient, AgentConfig};
use ed25519_dalek::SigningKey;
use rand::rngs::OsRng;

#[tokio::main]
async fn main() {
    let config = AgentConfig {
        agent_id: "my-agent-001".into(),
        name: "my-agent".into(),
        owner: "my-team".into(),
        gateway_endpoint: "http://localhost:9443".into(),
        capabilities: vec!["read".into(), "write".into()],
        allowed_tools: vec!["log_search".into()],
    };
    let signing_key = SigningKey::generate(&mut OsRng);
    let client = AgentClient::connect(config, signing_key).await.unwrap();
    println!("Trust score: {}", client.trust_score());
    let result = client.invoke(
        "d4385f9f-bcf8-47b9-90f4-b1fce91def59",
        "read",
        serde_json::json!({"location": "Kuala Lumpur"}),
    ).await.unwrap();
    println!("Result: {}", result.data);
}
        

TypeScript SDK

Package: agentid-sdk · Dependencies: tweetnacl

import { AgentClient, AgentConfig } from "agentid-sdk";

const config: AgentConfig = {
    agentId: "my-agent-001",
    name: "my-agent",
    owner: "my-team",
    gatewayEndpoint: "http://localhost:9443",
};
const client = new AgentClient(config);
await client.connect();
console.log(`Trust score: ${client.trustScore}`);
const tools = await client.discover("mcp");
const result = await client.invoke(
    "d4385f9f-bcf8-47b9-90f4-b1fce91def59",
    "read",
    { location: "Kuala Lumpur" },
);
console.log(`Result: ${result.data}`);
        

Framework Integrations

Python and TypeScript SDKs include ready-made integrations for popular agent frameworks:

Configuration

All three SDKs read from environment variables or constructor arguments:

SDK API Endpoints

Connect with Hermes Agent

Hermes is a self-improving autonomous AI agent by Nous Research. It features 70+ built-in tools, MCP client/server support, persistent memory, and runs on 20+ messaging platforms. Here's how to connect it to eyeVesa for identity, authorization, and audit.

Install Hermes

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

Register Hermes as an Agent

curl -X POST http://localhost:8080/v1/agents/register \
  -H "Content-Type: application/json" \
  -d '{
    "name": "hermes-ops",
    "owner": "org:devops",
    "capabilities": ["infrastructure_read", "infrastructure_write", "deployment"],
    "allowed_tools": ["k8s_deploy", "k8s_scale", "log_search", "incident_create"],
    "max_budget_usd": 500.0,
    "delegation_policy": "single_level",
    "behavioral_tags": ["production", "sre", "high_autonomy"]
  }'

Configure Hermes MCP to Use Gateway

mcp_servers:
  agentid-gateway:
    url: "http://localhost:9443/v1/mcp"
    headers:
      X-Agent-ID: "YOUR-AGENT-ID"
    tools:
      include: [tools/list, tools/call, resources/list, prompts/list]

Set Environment Variables

EYEVESA_AGENT_ID=your-agent-id-here
EYEVESA_AGENT_NAME=hermes-ops
EYEVESA_AGENT_OWNER=org:devops
EYEVESA_GATEWAY=https://gateway.yourcompany.com:9443
EYEVESA_KEY_PATH=/run/secrets/hermes.key

Two-Layer Security

Decision Flow

User sends message to Hermes (Telegram/Discord/CLI)
  |
  +-- Hermes LLM reasons about the request
  |
  +-- Is it an enterprise resource? (via eyeVesa Gateway MCP)
        |
        +-- Gateway verifies Ed25519 identity
        |
        +-- Gateway evaluates OPA policy
        |     +-- AUTO-DENY  (trust < 0.1, budget exceeded, never event)
        |     +-- AUTO-ALLOW (trust > 0.8, low-risk, tool in allowed_tools)
        |     +-- HITL       (production deploy, bank transfer > $100)
        |
        +-- Gateway signs audit log entry
        |
        +-- Gateway returns result + trust delta to Hermes
        

[Full Hermes Setup Guide]

Architecture

Dual-protocol gateway: Rust core proxies to Go control plane for auth, registration, and crypto.

+-------------------------------------------------------+
|                     ENTERPRISE                        |
|                                                       |
|  +-------------+  +-------------+  +--------------+   |
|  | K8s Adapter |  |  DB Adapter |  | Slack Adapter |   |
|  |  (Go :8443) |  |  (Go :8443) |  |  (Go :8443)   |   |
|  +------+------+  +------+------+  +------+-------+   |
|         |                 |                |           |
|         +--------+--------+----------------+           |
|                  |                                     |
|                  v                                     |
|       +----------------------+                        |
|       |   eyeVesa Gateway    |                        |
|       |                      |                        |
|       |  +----------------+ |                        |
|       |  | Gateway Core   | |                        |
|       |  | (Rust :9443)   | |                        |
|       |  | mTLS, proxy,  | |                        |
|       |  | crypto, MCP    | |                        |
|       |  +----------------+ |                        |
|       |                      |                        |
|       |  +----------------+ |                        |
|       |  | Control Plane  | |                        |
|       |  | (Go :8080)     | |                        |
|       |  | REST, gRPC,    | |                        |
|       |  | HITL, audit    | |                        |
|       |  +--------+-------+ |                        |
|       +----------+----------+                        |
|                  |                                     |
|    +-------------+-------------+                     |
|    |             |             |                     |
|    v             v             v                     |
| +----------+ +---------+ +---------+               |
| |PostgreSQL| |  SPIRE  | |   OPA   |               |
| |+pgvector | |Identity | | Policy  |               |
| | :5432    | |:8081/90 | | :8181   |               |
| +----------+ +---------+ +---------+               |
|                                                       |
| +-----------------------------------------------+   |
| | Agent SDK (Rust)                               |   |
| | connect() -> discover() -> invoke() -> delegate()|   |
| +-----------------------------------------------+   |
+-------------------------------------------------------+
        

Request Flow

From agent action to audit log in 12 steps:

 1. Agent registers            -> POST /v1/agents/register  -> PostgreSQL
 2. Resource registers         -> POST /v1/resources/register -> PostgreSQL
 3. Agent connects via SDK     -> mTLS to Gateway Core (:9443)
 4. Agent discovers tools      -> GET /v1/agents/{id}
 5. Agent invokes a tool       -> Ed25519-signed MCP request
 6. Gateway verifies signature
 7. Gateway checks policy       -> OPA evaluates Rego rules
 8. If HITL required            -> Write to hitl_approvals, notify human
 9. If allowed                  -> Proxy MCP request to Resource Adapter
10. Result returns              -> Agent gets response + trust score
11. Audit log written           -> Ed25519-signed entry
12. Trust score updated         -> +0.01 or -0.05
        

PTV: Prove-Transform-Verify

Hardware-rooted identity attestation. Agents prove their platform identity, the gateway transforms it into a binding, and any party can verify.

Prove:
  Agent generates hardware attestation (TPM / Secure Enclave)
  Signs with Ed25519 identity key
  Submits to /v1/ptv/attest

Transform:
  Gateway verifies TPM signature
  Creates identity binding (attestation + public key + expiry)
  Stores binding in identity_bindings table
  /v1/ptv/bind

Verify:
  Any party checks binding expiry and signature
  Confirms agent is who it claims to be
  /v1/ptv/verify/{bindingID}
        

Three-step protocol. No shared secrets. No API keys. Cryptographic proof that the agent ran on specific hardware at a specific time.

3-Tier Policy Engine

Never blocked on policy. Three fallback layers ensure authorization always returns an answer.

Policy decisions return four fields: allow, requires_hitl, reason, trust_delta. The gateway updates the agent's trust score based on trust_delta after every call.

Human-in-the-Loop

When policy is uncertain, humans decide. And they get notified everywhere.

Approval Flow

Request enters HITL:
  1. Write to hitl_approvals table (persistent, won't disappear)
  2. Notify primary approver (Slack DM / push notification / webhook)
  3. Start expiry timer (default: 30 minutes)
  4. Start escalation timer (5 min -> secondary -> 15 min -> team channel)

Minute 0:    Notify primary approver
Minute 5:    No response? Escalate to secondary approver
Minute 15:   No response? Escalate to team channel (anyone can approve)
Minute 30:   No response? EXPIRED (never auto-approve)
             Trust -= 0.01 for expired approval

For Layer 4 (escalation):
  Requires 2 separate approvals (e.g., VP Engineering + CTO)
  First approval: marks 1/2 approved, still pending
  Second approval: marks 2/2 approved, request executes
        

Notification Backends

Trust Scoring

Trust is earned, not given. Agents start at 1.0 and adapt based on behavior.

Trust Thresholds:

• >= 0.8 -- Auto-allow for low-risk
• >= 0.5 -- Normal operation, HITL for risky
• >= 0.1 -- Restricted, HITL for everything
• < 0.1 -- BLOCKED, cannot operate

Agent Delegation

Agents can delegate scoped authority to sub-agents. But not forever, and not without limits.

Hermes (level 0, trust: 0.92)
  +-- Worker Agent (level 1, delegated by Hermes)
        scope: ["log_search"] only
        max_depth: 1 (cannot delegate further)
        expires: 1 hour

        +-- NOT ALLOWED -- delegation_policy prevents depth > 1
        

CLI

The eyevesa CLI covers agent management, authorization, HITL, audit, skills, SPIRE federation, airport discovery, budget, keys, tenants, push notifications, and more. 22 parent commands, 85+ subcommands, all working.

# Agent operations
eyevesa agent register --name hermes-ops --owner org:devops --capabilities "read,write" --tools "k8s_deploy,log_search"
eyevesa agent list
eyevesa agent get <agent-id>
eyevesa agent trust <agent-id>

# Authorization
eyevesa authorize --agent-id <id> --action read --resource-id <rid>

# HITL approvals
eyevesa hitl list
eyevesa hitl approve <approval-id>
eyevesa hitl deny <approval-id>
eyevesa hitl status <approval-id>
eyevesa hitl request --action deploy --reason "prod deploy" --risk-level high
eyevesa hitl escalate <approval-id>

# Delegation
eyevesa delegate create --parent <id> --child <id> --scope "log_search" --max-depth 1
eyevesa delegate list <agent-id>
eyevesa delegate revoke <delegation-id>
eyevesa delegate validate <delegation-id>

# Audit
eyevesa audit --agent-id <id> --limit 50

# Resources
eyevesa resource register --name k8s-api --type mcp_server --endpoint https://k8s:8443
eyevesa resource list
eyevesa resource get <resource-id>

# MCP
eyevesa mcp initialize
eyevesa mcp tools-list
eyevesa mcp call <tool> --params '{"key":"val"}'

# Skills (11 subcommands)
eyevesa skills list --category monitoring
eyevesa skills search --query "kubernetes"
eyevesa skills create --name k8s-deploy --description "Deploy to K8s" --category ops --risk-level medium
eyevesa skills assign --agent-id <id> --skill-id <sid> --proficiency expert
eyevesa skills endorse --agent-id <id> --skill-id <sid>
eyevesa skills trust <agent-id>

# Transaction Protocol
eyevesa tx issue --subject <agent-id> --scope '{"read":true}' --ttl 3600
eyevesa tx verify <token-id>
eyevesa tx revoke <token-id> --reason "compromised"
eyevesa tx receipt --token-id <tid> --action purchase --value 50

# SPIRE Federation (13 subcommands)
eyevesa spire create-bundle --name prod-cluster --domain prod.example.org
eyevesa spire list-bundles
eyevesa spire fetch-bundle --endpoint https://spire.other-cluster:8081
eyevesa spire register-workload --spiffe-id spiffe://prod/k8s/my-svc --selectors "k8s:pod-label:app=myapp"
eyevesa spire attest-workload <workload-id>
eyevesa spire status

# Airport (Agent Discovery)
eyevesa airport search --capability "database"
eyevesa airport online
eyevesa airport profile <agent-id>
eyevesa airport heartbeat
eyevesa airport connections

# Budget & Rate Limits
eyevesa budget check --agent-id <id>
eyevesa budget record --agent-id <id> --amount 10 --resource "api-call"

# Key Rotation
eyevesa keys rotate
eyevesa keys status
eyevesa keys clear-previous

# Tenants
eyevesa tenants create --name acme-corp --domain acme.com
eyevesa tenants list
eyevesa tenants get <tenant-id>

# Push Notifications
eyevesa push register --token <device-token> --platform ios
eyevesa push list
eyevesa push deactivate <token-id>

# PTV Attestation
eyevesa ptv attest --platform tpm2.0 --firmware-version 2.1
eyevesa ptv verify <binding-id>

# Other CLI Commands
eyevesa init                       # Interactive agent registration wizard
eyevesa config show                # Show current config
eyevesa doctor                     # Diagnostic checks
eyevesa ready                      # Readiness check
eyevesa discover                   # Explore resources + MCP tools
eyevesa verify-signature <agent-id> <message> <signature>
eyevesa tui                        # Full terminal dashboard

# Authentication
eyevesa auth api-key create --label "ci-cd"
eyevesa auth api-key list
eyevesa auth api-key revoke <key-id>
        

API Endpoints

Control Plane (HTTP :8080)

Core Proxy (HTTP/TLS/mTLS :9443)

Total: 86+ API endpoints across all services.

Gateway Modes

FAQ

What is eyeVesa?

An identity and trust layer for autonomous AI agents. It gives agents cryptographic identity (Ed25519), enforces real-time authorization via OPA, and produces non-repudiable audit trails — so enterprises can trust what their agents do.

How does eyeVesa authorize agent actions?

A 3-tier OPA policy engine evaluates each request: auto-allow (routine actions under threshold), human-in-the-loop (risky actions require approval), or deny (unauthorized). Policies are Rego rules evaluated against agent identity, action, resource, environment, and trust score.

What is PTV attestation?

Process Trait Verification detects whether an agent process has been tampered with — code injection, binary replacement, or memory manipulation. Runtime measurements are compared against a registered baseline hash at every request.

What happens when HITL is triggered?

The action is paused. A notification is sent to the configured channel (Slack, PagerDuty, webhook, APNs, FCM, Telegram, or Discord). A human reviews and approves or rejects via button, API, or callback. If approved, the action proceeds; if rejected, it is denied and logged.

How does agent delegation work?

An agent can delegate authority to a sub-agent via a signed delegation token specifying scope (actions, resources, max depth). The sub-agent presents the chain when making requests. eyeVesa verifies all signatures, scope coverage, and chain integrity before allowing the action.

What gateway modes are available?

Three modes: plaintext (local development), tls (server-side TLS for staging/internal networks), and mtls (mutual TLS for production with client certificate verification).

How is the audit log tamper-proof?

Every audit entry is signed with Ed25519. The signature covers agent ID, action, resource, decision, and timestamp. Re-computing the signature on read instantly detects any modification.

What protocols does eyeVesa support?

eyeVesa is built around the Model Context Protocol (MCP) for agent-tool communication. It also provides REST/gRPC APIs for management, and supports SPIRE/X.509 SVID for workload identity.