Bruce Lynn

AI agents can already plan multi-step work. They can call tools, compare options, and coordinate tasks. The moment a task requires payment, many workflows stop. Existing payment systems were built for humans who log in, enter card details, and approve transactions. Agents cannot reliably perform these steps. They also cannot be trusted with unrestricted access to a user’s funds or credentials. This mismatch is a core constraint on the agent economy.
Kite addresses this constraint by treating payment authority as infrastructure rather than an instruction. Authority is granted for a defined task, bounded by rules, and enforced outside the agent’s own reasoning. The result is a system in which an agent can complete paid work while the user retains cryptographic control over what can be spent, where, and for how long.
The Problem of Unbounded or Unenforceable Authority
Most current approaches to agent payments create one of two failures.
The first is over-permission. A user shares a credit card, API key, or wallet private key. The agent then holds standing access that extends far beyond any single task. If the agent misbehaves, the workflow changes, or credentials are compromised, the exposure is not limited by design.
The second failure is constant interruption. The agent stops for human approval on every payment. Autonomy collapses into a series of prompts.
Instructions written in natural language do not solve either problem. A prompt that says "do not spend more than $20" is not enforceable. The agent may ignore it, misinterpret it, or operate in a context where the constraint is no longer visible. Authority that lives only inside the model’s context window cannot be verified or revoked by the underlying system.
Kite's design starts from the opposite premise. Limits must be represented and checked at the point of action.
Identity Is Not Authority
Kite uses a three-layer identity model. The user holds root authority. Each agent receives a deterministic address derived from the user’s key material through hierarchical deterministic derivation. The agent cannot reconstruct the parent key.
Sessions are ephemeral. They receive short-lived credentials that expire by time or by exhaustion of their permitted scope. Compromise at any layer is contained. The user never hands an agent the root key. The session never receives the full capabilities of the parent agent.
This creates an important distinction:
An agent can have a persistent identity without having persistent spending authority.
When an agent needs to make payments, it requests a session. The user reviews the request and approves it with a passkey. The approval defines a concrete envelope: a total budget, a per-transaction limit, a time window, and often an allowed set of services or merchants.
Once the session is active, the agent can discover services, request payments, and complete transactions without further human approval, provided every action stays inside the approved envelope.
Requests that exceed the budget, fall outside the scope, or arrive after expiry can be rejected by the system. The user can revoke the session. Grants and expenditures are recorded, producing an auditable trail of what authority was given and what was done with it.
The key idea is that identity and authority are separate. The agent can remain identifiable while its economic permissions remain temporary and task-specific.
From “Trust the Agent” to “Constrain the Capability”
This distinction changes the security model.
In a simple credential-based model, the agent receives a capability and is expected to use it correctly. The safety boundary therefore depends heavily on the agent’s behavior.
A scoped-session model moves part of that boundary outside the model. The user defines what the agent is allowed to do, and the payment infrastructure checks whether an action remains within those limits.
That does not make the agent infallible. It does something more specific.
It limits the economic consequences of an agent operating outside its intended instructions.
This is why a rule such as “spend no more than $20” is fundamentally different when represented as an enforceable session constraint rather than left as text inside a prompt.
Settlement and Micropayment Rails
Payments settle in stablecoins on Kite’s purpose-built Layer 1. The chain is EVM-compatible and optimized for high-frequency, low-value transfers.
State channels allow an agent to open a channel once on-chain, stream many signed updates off-chain, and settle once. This pattern supports pay-per-request or pay-per-inference economics while reducing the need for an on-chain transaction for every individual interaction.
Users do not need to expose bank details or card numbers to the agent. The agent spends only from funds made available within the approved session.
The same rails support multiple emerging standards. Kite is designed to act as an execution layer compatible with protocols such as x402 and Google’s AP2 rather than requiring developers to choose a single proprietary interface.
A service that already emits an HTTP 402 payment requirement can be paid by an agent operating under a Passport session. The payment request and the authority governing the transaction can therefore fit into the same agent workflow.
What the System Actually Enforces
The practical effect is that several classes of risk become mechanically limited.
An agent cannot continue spending after its session expires. It cannot exceed the per-transaction or total budget defined for the session. It cannot silently expand its own permissions. If a workflow requires more authority, a new session can be requested and approved.
These properties do not depend solely on the agent correctly interpreting a prompt. They are checked by the payment and identity system before value moves.
For builders, this changes how agent capabilities can be composed.
An agent can be given a skill that discovers and pays for catalog services or that initiates direct stablecoin transfers. The skill operates only inside the session the user has already approved.
Developers therefore do not need to treat every agent as a fully trusted economic actor. They can integrate capabilities around a defined authority envelope instead.
A Simple Example
Consider a research task that requires paid data.
The user approves a session with a $10 total budget and a $2 per-request limit. The session is valid for two hours and restricted to a specific data provider.
The agent purchases access, retrieves the needed records, and stops when either the budget or the time window is exhausted. The user can inspect the payments and revoke the session if the results are no longer useful.
No API key or card needs to be shared with the agent.
The same pattern can apply to booking a service, renting temporary compute, or triggering a conditional on-chain action. In each case, the important step happens before execution: the user defines the economic authority the agent will have.
What This Does Not Solve
Bounded payment authority does not eliminate the need for human judgment.
Users still need to decide what budget and scope are appropriate for a task. A correctly bounded payment can still purchase a poor service. An agent can still make a bad decision inside the authority it has been given.
The value of the model is narrower and more concrete.
It reduces the need for the user to approve every individual payment while reducing the need to trust the agent with unrestricted authority.
That distinction matters because autonomous payments require more than a way to move money. They require a way to delegate economic authority without turning delegation into permanent access.
Open Questions
The infrastructure makes bounded agent spending practical, but several design and operational questions remain open for users and builders.
How should session parameters be chosen for different classes of tasks so that agents can complete work without frequent re-approval?What additional visibility or alerting would make real-time monitoring of active sessions useful rather than burdensome?When multiple agents or services interact under separate sessions, which rules should govern the composition of their authorities?How should users evaluate the trustworthiness of services being paid for when the payment itself is properly constrained?
These questions sit downstream of the basic mechanism.
The mechanism itself is straightforward: authority is requested, bounded, enforced through the payment flow, and revocable.
The broader significance of Kite Agent Passport is not simply that agents can pay. It is that identity can remain persistent while economic authority becomes temporary, scoped, and enforceable.
That separation gives builders a more structured way to think about autonomous payments: not as handing an agent unrestricted access to money, and not as interrupting the agent for every transaction, but as giving the agent a defined capability envelope within which it can act.
$KITE #KiteBBW @KITE AI 中文