Your agent can only move money inside a token that says so.

An AI agent with a signing key has all of that key’s authority. Nothing in the key says which human asked, what they approved, how much, for what, or until when — and nothing in the transaction afterwards says why it was permitted.

SPT‑Txn narrows that. Authority exists only inside a short‑lived token bound to one declared action, and that token carries a commitment to the accountable person all the way down.

How authority narrows

• A compliance attestation is issued once, against your existing identity provider, and carries a privacy‑preserving anchor to the authorizing human.
• It is delegated into capability tokens that can only ever narrow — in amount, in counterparty, in purpose, in time — and never widen, with the delegation depth bounded.
• At the moment of action a transaction token is minted: short‑lived, bound to that one transaction, and sender‑constrained (DPoP, RFC 9449) so a stolen token is not a usable token.

The anchor to the human is carried unchanged through every hop, so a decision three delegations deep still traces to the person who authorized it — without that person’s identity appearing anywhere on the wire.

What “can only narrow” looks like

Three real tokens, minted by the reference implementation while this page was written. The chain is human → agent → sub‑agent, and these are the decoded capability_scope claims exactly as they appear in each token. Nothing below is illustrative. go run ./cmd/agentdemo reproduces it offline, with no network and no keys of ours.

The ceiling falls at every hop, the depth counter falls with it, and the human_anchor claim is byte‑identical in all three: the same accountable person, carried unchanged to the last delegate. Widening is not rejected at spend time; it is refused at mint, so a token granting more than its parent never exists. In the same demo, sub‑agent B asking for 6,000 against its 5,000 ceiling is refused before any token is issued, and revoking agent A’s delegation key kills B’s authority while leaving A’s own capability working.

One decision engine, wherever the agent acts

The same enforcement point sits in front of an HTTP payment endpoint or an agent tool call. It computes a fixed‑width binding over the exact action being requested and returns one of three outcomes — ALLOW, DENY (violation), or DENY (unavailable) — so an attack and an outage are never confused for one another, and neither is ever silently permitted.

A compromised or prompt‑injected agent cannot exceed or re‑widen what it was granted. That is containment at the point of action, not detection afterwards.

Records, and the oversight question

Every decision produces a signed receipt, hash‑chained and Merkle‑committed, verifiable offline and containing no personal data. Where supervisors expect a demonstrable human‑oversight and record‑keeping mechanism for agentic systems — the EU AI Act’s Article 14 expectations among them — this is a technical mechanism you can point at and test. It is a building block, not a compliance certification, and we do not claim it makes any deployment compliant.

You run it. That is the point.

The control plane belongs with the regulated entity that already carries the obligation. We publish the software under Apache‑2.0; you deploy it, you hold the keys, you set the policy, and no transaction detail reaches us or anyone else. We do not operate a service in your money path and we take no fee per transaction.

Honest boundaries

If this is useful to you

Everything is public and reproducible — the reference implementation, the specification work, and the tests behind each claim above.

Reference implementation on GitHub →
Framework paper and IETF Internet‑Draft →
rudi@violetskysecurity.com