Session keys that can only do less

The fastest way to give an agent access to money is to hand it the owner’s key. It is also the most dangerous. A bug, a prompt injection or a leaked environment variable then has the full authority of the account behind it.

LayerX takes a different approach. Every activity is authorized by a grant, and a grant says exactly what the holding key may do. A session key is a strict subset of its owner’s authority, with an expiry attached.

What a grant specifies

A grant is precise. It can narrow a key’s authority along every dimension that matters for spending:

• which modules the key may touch
• which activity types within those modules
• which asset it may move
• how much per activity, per period and in total
• the two timestamps between which it is valid

For each activity, the kernel resolves one grant, checks that it is live against the grantor’s revocation sequence and the batch timestamp, and rolls the spend period forward from the period start. If the activity falls outside the grant, it fails with an error that names the reason: expired, revoked, out of scope, or over its allowance.

The eight authority kinds

Not every authority looks like a session key. LayerX defines eight kinds of grant, each for a distinct job.

• Owner. The identity’s own full authority.
• Session key. A narrowed, expiring key for an agent process. An authentication-only variant carries an empty scope, so it can sign in without any spending authority at all.
• Delegated capability. Authority passed to another party for a stated purpose, with a named asset and caps.
• Budget allowance. Spending authority tied to a budget, with a per-activity maximum and either a total cap or a per-period cap.
• Escrow. Authority scoped to an escrow hold, which owner keys and session keys cannot spend.
• Protocol module. Authority exercised by a module itself, such as the stream module paying out a stream account.
• Multisig. A threshold of up to eight distinct signers. Below the threshold, the grant does not resolve.
• Timelock. Authority that matures only after an earliest sequence number or timestamp.

Scope only ever narrows

A grant’s identifier is the hash of the grant’s own encoding. Change any field and it becomes a different grant. A grant cannot be quietly edited in place.

Amendment is one-directional by design. The kernel accepts an amended grant only if it is strictly narrower than the original: the same grantor, grantee, key, asset and purpose, a subset of the modules, a narrower activity range, a validity window inside the old one, and caps that only shrink. Any widening is refused. The narrowed grant receives a new identifier.

In practice, authority can be reduced at any time but never silently expanded. Anyone reviewing a key’s history can see that each step gave it less.

Revocation without moving funds

Revocation works two ways. A single grant can be marked revoked. Or the owner can bump the identity’s revocation sequence. A grant is live only when its recorded sequence equals the identity’s current one, so bumping the sequence invalidates every grant issued under the old value in one step.

Neither path moves funds. Balances stay where they are. The agent’s next activity simply fails its authority check.

Key rotation follows a related pattern at the identity level. A new key is announced, a challenge window opens, and the rotation is committed inside that window. The old key remains valid for activities below the rotation’s effective sequence, so work already in flight does not break.

Both sides sign a pull payment

Payer-funded calls, where a provider pulls payment for each request, use a separate payer grant. The payer signs an allowance for one recipient, one asset and one purpose, with a per-draw ceiling and an optional recurring window. The recipient then draws against it with a receive that both parties have signed.

The payer’s signature covers the recipient, asset, ceiling, allowance, window, expiry and purpose. The recipient’s signature covers the draw itself. A draw that names the wrong purpose is refused. A grant carrying a reference settles once, and a second draw returns an already-settled error.

Where the daemon fits

Many teams run agents beside layerx-agentd, a local daemon that evaluates each request against a versioned policy before it is signed. Policy rules can match on counterparty, asset, amount, purpose and more, and each decision returns an allow or deny with the rule that decided it.

The daemon is explicit about its role. Its capabilities are checked against the authority the agent domain granted, and its own restrictions are labeled as daemon-enforced. The hard boundary is the protocol grant. The daemon adds an operator’s mandate on top.

Why it matters

A compromised agent process cannot exceed what its grant allowed and cannot outlive its window. Shutting an agent down is a revocation, not a fund transfer. Delegation, multisig approval and timelocks all use the same grant structure, so one audit model covers them.

Give the agent a key that can only do less, and the worst case is bounded before anything goes wrong.

The documentation covers grant formats, error codes and the session API.