Kite Passport: A Technical Deep Dive

AI agents are officially in production – booking flights, spinning up compute, executing API calls – but one question keeps surfacing: who authorized that?

Traditionally, auth systems are designed for humans. You log in, get a session token, and go on your merry way. But AI agents aren't human. They're constantly on, can spawn sub-agents, spend money on your behalf, and more – all autonomously. Traditional auth systems just aren't cut out.

Kite Passport provides the necessary infrastructure from scratch, and this post breaks down how it actually works: the identity architecture, the onchain machinery, the delegation model, and the privacy guarantees.

---

The Three-Layer Identity Model

Kite Passport thrives on a three-tiered identity architecture, where each tier has a distinct authority scope:

1. User (Root Authority)

   The source-of-truth: your wallet. It never participates in transactions directly and is used to cryptographically derive all downstream identities. The User layer anchors the chain of delegated authority.

2. Agent (Delegated Authority)

   Each AI agent gets its own deterministic onchain address, derived from the first layer using BIP-32 hierarchical deterministic key (HDK) derivation. Anyone can confirm that an agent address belongs to a given user wallet, but the agent can't reconstruct the parent key. This means we can prove an agent's relationship to its human principal without giving the agent any elevated access.

   What Is an HDK Architecture?

   An HDK architecture essentially acts as an account manager – it maintains many derived keys from one protected root key or phrase and enables the authentication of a user and/or agent.

3. Session (Ephemeral Authority)

   When an agent needs to perform a specific task (e.g., booking a flight), it receives a Session key that's precisely scoped for that task: who it's valid for, exact spending amounts, etc. Unlike agents' onchain addresses, Sessions are randomly generated (not derived). They also expire automatically after use or on timeout and become cryptographically useless once their scope is exhausted.

TL;DR: An agent never needs access to the user's root key, a Session never needs the full capabilities of its parent agent, and compromise at any layer is contained.

---

The Passport

A Kite Passport isn't just an identifying document — it gives verifiers the information needed to trust an agent's actions. It contains:

• Identity binding: Cryptographic proofs are used to confirm that an agent is backed by a real, verified human identity without learning which identity that is.
• Capability declarations: The services that the agent is authorized to interact with and the actions it can take.
• Spending parameters: Maximum spend, allowed merchant categories, and time constraints.
• Onchain record: Ownership, operational purpose, and permission state are recorded on Kite's Avalanche L1, making the passport's current state auditable and tamper-evident.

The Trust Chain

---

Delegations

Just because an agent has a passport doesn't mean it can go off and spend freely. Its action relies on two primitives: Sessions (discussed previously) and Delegations.

While a Session is essentially a budget declaration, a Delegation is a specific, signed payment intent linked to a parent Session.

Note: Sub-delegation is allowed, meaning an agent can further delegate to a specialized sub-agent, whose authority is bound by both the original session and the parent delegation.

---

X402 and the Agent Payment Protocol

Kite's Avalanche L1 is purposely designed for agent-native transaction semantics, bringing together several components:

1. Account Abstraction Wallets

Users are represented onchain through smart contract accounts versus externally owned accounts, allowing the programmable, multi-party authorization logic that session keys and delegations need. The Kite MCP server exposes two dev-facing tools for working with this:

1. Get AA wallet address
2. Create signed X-payment payload

2. The X402 Protocol

Kite is natively supported by X402, an open HTTP-native payment standard. The flow works by repurposing the HTTP 402 Payment Required status code as a machine-readable payment demand. When an agent hits a paywalled API endpoint:

1. The server returns 402 with a structured payment requirements header specifying the amount, accepted tokens, and settlement address.
2. The agent (via its session key) constructs and signs an X-Payment header containing the authorization.
3. The agent retries the request with the signed header.
4. The server verifies the payment authorization, settles onchain, and returns the resource.

This is designed to be stateless. The payment authorization is self-contained in the HTTP request.

3. Agent Payment Protocol (APP)

Kite's Agent Payment Protocol specializes the flow for stablecoin settlement on Kite's L1. APP handles the translation between signed payment intent (produced by the Kite MCP tools) and the actual onchain settlement transaction.

For high-frequency micropayments, Kite uses state channels to avoid per-transaction L1 overhead. Two parties open a channel with an initial funding transaction, exchange signed state updates off-chain for the duration of their interaction, and settle the final state onchain. This delivers sub-100ms latency and transaction costs in the range of $0.000001.

---

The SPACE Framework

Kite's full payment stack is designed around the SPACE framework:

Letter	Principle
S	Stablecoin-native payments with sub-cent fees and instant finality
P	Programmable constraints cryptographically enforced through smart contracts
A	Agent-first authentication via hierarchical identity with mathematical delegation
C	Compliance-ready immutable audit trails
E	Economically viable micropayments enabling pay-per-request pricing at scale

---

Privacy Model: Selective Disclosure

One of the more interesting design choices in Kite Passport is how it handles the tension between accountability and privacy.

The system needs agents to be accountable. If an agent misbehaves, there should be a verifiable chain of responsibility back to a human principal. But it also shouldn't require agents to broadcast their user's identity with every transaction.

The solution: selective disclosure, enabled by the cryptographic identity binding in the passport.

When a service provider receives a request from an agent, it can verify:

• This agent has a valid, active passport
• The passport is backed by a real, verified human identity (e.g., someone with a legitimate Gmail account versus a bot farm)
• The agent is operating within its declared spending constraints

What the service provider cannot learn from this verification alone is which specific human backs this agent. The cryptographic proof is structured to be one-way – it asserts membership in the set of "verified humans" without identifying the specific member.

This is the selective disclosure property: an agent can prove relevant facts about its user (they're a verified human, they have sufficient backing, and they've been vouched for) without revealing the user's identity.

For use cases where full attribution is required (like compliance or regulated transactions), the passport supports disclosure of additional identity claims, but this is opt-in per session, not the default.

---

Protocol Interoperability

Kite Passport doesn't exist in isolation. It's designed to compose with the broader emerging stack for agent infrastructure:

• Anthropic MCP: The Kite MCP server integrates directly, surfacing passport and payment tools to any MCP-compatible agent.
• Google A2A: An agent-to-agent communication protocol that enables Kite-identified agents to interact with the broader A2A ecosystem.
• OAuth 2.1: The identity binding for human credentials uses OAuth 2.1 flows as the entry point before cryptographic commitment.
• X402: The HTTP-native payment layer.

Positioning this as an execution and settlement layer compatible with multiple agent runtimes and identity protocols is deliberately broad. Instead of betting on a single agentic framework winning, Kite aims to be the trust and payment substrate underneath all of them.

---

What This Means in Practice

If you're building agent-powered apps, Kite Passport is the answer to a set of questions you'll have to answer eventually, anyway:

• How does my agent authenticate to third-party services? Via its passport, without you managing per-service API keys.
• How do I audit what my agent did? Immutable onchain transaction records with a complete delegation chain.
• How do I build multi-agent pipelines without sharing full credentials? Sub-delegation with scoped authority at each step.

---

Sources

• Kite Whitepaper
• Kite Developer Guide
• Kite Agent Passport Introduction