> For the complete documentation index, see [llms.txt](https://axon-finance.gitbook.io/axon-finance-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://axon-finance.gitbook.io/axon-finance-docs/yellowpaper-c-account-abstraction-and-ai-authorization/c2-session-keys.md).

# C.2 Session Keys & the Authorization Model

Formalized authorization for AI-agent payments

> **Design status**: proposed design. This is the protocol core of AXON's "controlled payment execution" (the formalization of whitepaper [5.2](/axon-finance-docs/part-v-ai-native/part5-ai/5-2-controlled-execution.md)).

## C.2.1 Goal

Enable an automated principal (an AI agent) to initiate payments autonomously, while its spending power is **enforced by the chain** within a precise, revocable boundary—"**can pay, but can't run off or overspend**". The core is to turn "authorization" from "one all-powerful private key" into "a programmable, bounded, revocable policy".

## C.2.2 Session Keys and Policies

The account owner (master key $sk\_{\text{owner}}$) issues a **session key** $sk\_a$ to the agent, binding it to an **authorization policy** $P$:

$$\mathsf{Grant}(sk\_{\text{owner}}) \to (sk\_a,\ P), \qquad P = {,c\_1, c\_2, \dots, c\_k,}$$

The policy $P$ is a set of **constraint predicates**. The commitment to the constraints $\mathsf{policy\_root} = \mathsf{root}(P)$ is written into the account ([B.3.1](/axon-finance-docs/yellowpaper-b-consensus-and-ledger/b3-state.md)), making the policy an authenticated piece of on-chain state.

Supported constraint types (each constraint is a predicate over a transaction $c : \mathsf{Tx} \times \mathsf{Ctx} \to {0,1}$):

| Constraint  | Notation            | Semantics                                         |
| ----------- | ------------------- | ------------------------------------------------- |
| Total cap   | $c\_{\text{cap}}$   | Cumulative session spend $\leq L\_{\text{total}}$ |
| Per-tx cap  | $c\_{\text{tx}}$    | Per-transaction amount $\leq L\_{\text{tx}}$      |
| Time window | $c\_{\text{time}}$  | $t \in \[t\_0, t\_1]$                             |
| Allowlist   | $c\_{\text{allow}}$ | Recipient $\in W$                                 |
| Asset scope | $c\_{\text{asset}}$ | Asset $\in \mathcal{S}$                           |
| Rate limit  | $c\_{\text{rate}}$  | Transactions per unit time $\leq \rho$            |
| Call scope  | $c\_{\text{call}}$  | Target/method $\in \mathcal{F}$                   |

## C.2.3 The Authorization Predicate

A transaction $\mathsf{tx}$ signed by a session key is authorized **if and only if all constraints are simultaneously satisfied**—the authorization predicate is the conjunction of the constraints:

$$\mathsf{Auth}*P(\mathsf{tx}, \mathsf{ctx}) ;=; \bigwedge*{c \in P} c(\mathsf{tx}, \mathsf{ctx})$$

where the context $\mathsf{ctx} = (\text{now},\ \mathsf{spent},\ \mathsf{count},\ \dots)$ carries the **session state**: cumulative spend $\mathsf{spent}$, count of transactions within the window $\mathsf{count}$, etc. These states are updated as the session is used, and are the key to enforcing the "cumulative cap" and "rate limit"—they are authenticated on-chain state that the agent cannot bypass or forge.

Unfolded into a decidable check:

```
Auth_P(tx, ctx):
  assert verify(session_pubkey, tx)                     # session-key signature valid
  assert not revoked(session_id)                        # not revoked (C.2.5)
  assert t0 ≤ ctx.now ≤ t1                              # c_time
  assert tx.amount ≤ L_tx                               # c_tx
  assert ctx.spent + tx.amount ≤ L_total                # c_cap (cumulative)
  assert tx.recipient ∈ W                               # c_allow
  assert tx.asset ∈ S                                   # c_asset
  assert ctx.count_in_window + 1 ≤ ρ                    # c_rate
  assert tx.call ∈ F                                    # c_call
  return true    # any failed assert → false (that tx is rejected, key stays valid)
```

## C.2.4 The Session State Machine

The lifecycle of a session key is a strict state machine. **Going out of bounds does not disable the key, it only blocks that one transaction**—this is the essence of a "controlled" rather than "all-or-nothing" design:

```mermaid
stateDiagram-v2
    [*] --> Granted: Grant(owner) sets policy P
    Granted --> Active: agent's first use
    Active --> Active: in-bounds payment (Auth_P = true) → update spent/count
    Active --> Rejected: out of bounds (Auth_P = false) → reject that tx
    Rejected --> Active: key still valid, continues working within bounds
    Active --> Exhausted: spent reaches L_total
    Active --> Expired: now > t1
    Active --> Revoked: owner revokes (C.2.5)
    Exhausted --> [*]
    Expired --> [*]
    Revoked --> [*]
```

`Rejected` is a **return state**: an out-of-bounds transaction is rejected, but the session key remains `Active`, and the agent can keep working normally within bounds. Only exhausting the cap, timing out, or being revoked terminates the session.

## C.2.5 Revocation

Revocation must be **immediate and enforced at the chain layer**—this is the last valve for stopping losses. Revocation writes a session marker into account state:

$$\mathsf{Revoke}(sk\_{\text{owner}}, \mathsf{session\_id}) \Rightarrow \mathsf{revoked}\[\mathsf{session\_id}] \gets \top$$

Once `Finalized` ([B.5](/axon-finance-docs/yellowpaper-b-consensus-and-ledger/b5-finality.md)), any subsequent transaction from that session fails immediately at the `not revoked` check in $\mathsf{Auth}\_P$. Even if the agent is completely compromised, the owner can cut off its spending power within a single block.

## C.2.6 Security Properties

The session-key authorization model provides three provable properties (corresponding to the three sub-problems of whitepaper [5.1](/axon-finance-docs/part-v-ai-native/part5-ai/5-1-agentic-payments.md)):

* **Boundedness**: cumulative session spend always satisfies $\mathsf{spent} \leq L\_{\text{total}}$, and per-transaction $\leq L\_{\text{tx}}$. Enforced at the chain layer by $c\_{\text{cap}}, c\_{\text{tx}}$—**compromise the agent, and the loss is still locked within bounds**.

$$\text{For any execution sequence}\ \sum\_{\text{confirmed tx}} \mathsf{amount} \leq L\_{\text{total}}$$

* **Directedness (Confinement)**: funds can only flow to the allowlist $W$, limited to assets $\mathcal{S}$—**the agent can't get to places you don't want it to go**.
* **Revocability**: the owner can irreversibly terminate the authorization within a single block—**take it back anytime**.

These are **enforced by the chain**, not dependent on the agent's own honesty or off-chain components—which is precisely the fundamental value of "native account abstraction" ([C.1.1](/axon-finance-docs/yellowpaper-c-account-abstraction-and-ai-authorization/c1-account-abstraction.md)) over relay-based approaches.

## C.2.7 Integration with x402 / M2M

Session keys are the authorization foundation for x402 (HTTP 402 pay-per-call) and M2M micropayments: within its session bounds, an agent initiates a constrained on-chain micropayment for each service call (whitepaper [5.3](/axon-finance-docs/part-v-ai-native/part5-ai/5-3-x402-m2m.md)). $c\_{\text{rate}}$ prevents runaway loops from burning funds, $c\_{\text{cap}}$ caps total risk, and $c\_{\text{allow}}$ restricts the service counterparties—the security of machine payments thus shifts from "trust the agent" to "trust the constraints".

The same model is also used for **one-click copy-trading with a session key** ([E.3.6](/axon-finance-docs/yellowpaper-e-payfi-protocol-mechanisms/e3-copy-trading.md)): the copy-trading session key's $L\_{\text{tx}}$ corresponds to the per-round quota, $L\_{\text{total}}$ to the cumulative cap, and $c\_{\text{allow}}$ restricts funds to only enter the escrow/settlement contracts—authorization for human users shares the same bounded, directed, revocable predicates as authorization for AI agents.

***

*Next:* [*C.3 Policy Sandbox & Paymaster*](/axon-finance-docs/yellowpaper-c-account-abstraction-and-ai-authorization/c3-policy-paymaster.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://axon-finance.gitbook.io/axon-finance-docs/yellowpaper-c-account-abstraction-and-ai-authorization/c2-session-keys.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.