ATH (Agent Trust Handshake Protocol) is an open, lightweight protocol for establishing trusted connections between AI agents and external services. It builds on OAuth 2.0 with a trusted handshake — both the service and the user must approve before an agent can access anything. ATH is not tied to any specific platform, vendor, or technology stack. Anyone can implement it.

​
The Problem

When AI agents access services on behalf of users, a single question is usually asked:
“Did the user consent?” (OAuth)
But a second question is equally important:
“Did the service approve this agent?”
Without both checks, any agent — including malicious ones — can access any service as long as it tricks a user into consenting.

​
The Solution: Trusted Handshake

ATH adds app-side authorization (the service approves the agent) on top of user-side authorization (the user consents via OAuth): 
                App-side: Is this agent approved?
                           │
    Agent ───── ATH ────► Service
                           │
                User-side: Did the user consent? (OAuth 2.0)
An agent can access a service only when both conditions are met. The effective permission is the intersection: 
Effective Scope = Agent Approved ∩ User Consented ∩ Requested

​
What can ATH enable?

Secure Agent Access

Agents can access services like email, calendars, and databases — only after both the service operator and the user have approved.

Zero-Change Deployment

In Gateway Mode, service providers need zero changes. The ATH Gateway handles the trusted handshake on their behalf.

Scope Intersection

Even if a user consents to broad permissions, the agent only gets the scopes the service has pre-approved for that agent.

Complements MCP & A2A

ATH provides the trust layer that agent-to-tool (MCP) and agent-to-agent (A2A) protocols currently lack.

​
Why does ATH matter?

Depending on where you sit in the ecosystem, ATH provides different benefits:
RoleBenefit
Agent DevelopersRegister once, get approved scopes, build with confidence that your agent has verified access
Service OperatorsControl which agents can access your service, at what scope level, without changing your OAuth setup
End UsersKnow that the agent accessing your account has been vetted by the service — not just that you clicked “Allow”
EnterprisesAudit trail of every agent’s approved capabilities and access patterns

​
Protocol Positioning

ATH operates at the application layer, complementing existing protocols: 
┌─────────────────────────────────────┐
│  User Operations (CLI, UI, Skills)  │  User interacts with agent
├─────────────────────────────────────┤
│  ATH (Trust & Authorization)        │  Agent identity + trusted handshake
├─────────────────────────────────────┤
│  A2A / MCP (Collaboration)          │  Agent-to-agent / agent-to-tool
├─────────────────────────────────────┤
│  HTTPS / TLS (Transport)            │  Secure transport
└─────────────────────────────────────┘
ATH does not compete with MCP or A2A. It complements them by providing the trust layer that these protocols currently lack.

​
Start Building

Quickstart

Run the reference implementation in 5 minutes

Core Concepts

Understand the architecture and design principles

Build an Agent

Use the ATH Client SDK to connect your agent

Specification

Read the full protocol specification