An agent that can pay for things is useful precisely because nobody has to approve each payment. That is also what makes it a risk. A loop that retries forever, a prompt that redirects the agent's goal, a credential that leaks: each turns into money spent, and the spending continues until someone notices and finds a way to stop it.
Risk frameworks already say what should be in place. The NIST AI Risk Management Framework asks for accountability structures "so that the appropriate teams and individuals are empowered, responsible, and trained" for managing AI risks (GOVERN 2), and for mechanisms, with assigned responsibilities, "to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use" (MANAGE 2.4). The OWASP Top 10 for Agentic Applications catalogues the risks of autonomous AI systems for security teams. Tenzro, the open settlement and coordination layer for AI work, puts those mechanisms in the payment path itself: every agent spends under limits set by a responsible party, and revoking it stops its spending at once.
For an agent that pays, those principles translate into three concrete requirements: a responsible party behind every agent, limits the agent cannot exceed, and a revocation that actually reaches everywhere the agent can spend.
A responsible party behind every agent
The first question after any incident is who answers for this agent. That question is easy to lose. An agent's credentials are often an API key in an environment variable, issued by a developer who has since moved on, and paid for by a corporate card that serves twenty other systems.
Accountability holds when the agent's identity is derived from a responsible party's own identity, and every grant of authority to the agent is approved by that party. The responsible party can be a person or a machine. What matters is that it holds its key in hardware, so the approval cannot be produced by anyone who merely copied a file, and that anyone checking the agent can see who the root is.
Limits the agent cannot raise
Limits are only limits if the agent cannot change them. A spending cap held in the agent's own configuration, or in a policy file on the host it runs on, is one prompt injection or one compromised dependency away from being raised.
That puts two requirements on where limits live. They must be held by a party the agent does not control, and checked at the point where the payment is made, not at the point where the agent decides to make it. And because agents increasingly pay through several rails, an HTTP 402 gate here, a channel there, a mandate somewhere else, the same limits must be checked by every rail. Separate limits per rail add up to no limit at all.
Useful limits are numbers and lists: most per payment, most per hour, most per day, which assets, which counterparties, which models, during which hours, until which date. For actions that carry more risk, a limit can also hold the action until the responsible party approves it.
Revocation that reaches everywhere
Revocation is the hardest of the three, because spending authority spreads. An agent that has opened a payment channel can keep paying through it with vouchers. An agent with accounts on several networks can pay on each. An agent whose signed requests are accepted by servers can keep being served.
A revocation that only disables the agent's API key leaves all of those in place. A revocation that works has to end the agent's ability to authorise new payments on every rail, and has to be visible to every payee that might accept one, without each payee being told separately. The simplest way to achieve that is for the revocation to be a single record that every payment check consults.
Evidence after the fact
Accountability also needs a record that someone outside the system can check. When a regulator, an auditor or a customer asks what an agent spent, the answer should not depend on trusting the agent's developer, its operator or a vendor dashboard. AP2 makes this point for consent, describing an audit trail of mandates; the same standard should apply to the payments themselves.
What this means for agent builders and policy makers
For builders: keep authority outside the agent, express it as numbers and lists, enforce it where the payment happens, and test that revocation stops every rail the agent uses, including channels it opened before revocation. For policy makers and risk owners: ask, for any agent that spends, who its responsible party is, where its limits are enforced, how long a revocation takes to reach every payee, and what record an outsider can verify.
Where Tenzro fits
Tenzro is the settlement layer for AI work, and every agent that pays through it answers to a responsible party. What is built, per the Tenzro repository documentation:
A root behind every agent. A delegated agent has exactly one root, and its identity derives from it. The root is a person, through a passkey, or an autonomous machine, through its TPM or Secure Enclave key registered on the network. Every approval the root gives, creating, changing or revoking the agent's terms, is a challenge it signs with that hardware-held key, and validators check it.
No key for the agent. An agent holds no key of its own. Its authority is its terms in consensus state and nothing else. The serving node checks each action against the terms before signing it on the agent's behalf, and the ledger checks it again at execution; the ledger's verdict is final. There is no node-side spending policy or mandate store beside the terms.
Limits as numbers and lists. Terms hold the most one action may move, the most in any 60 minutes and any 24 hours, action counts per hour and per day, permitted hours, allowed operations, chains, payment protocols, models and counterparties, per-asset limits, an optional minimum verification tier for counterparties, a cap on the fees a settlement plan may take, and an expiry. Spend is counted in consensus state, so every node sees the same running totals. Particular actions can be held for the root's passkey approval.
One check on every rail. Every payment entry point, the gateway behind x402 and the HTTP 402 gates, paid registry calls, routed inference and agent steps, asks the same check: the agent must be live, not paused, quarantined or revoked, and within its terms.
Revocation that reaches channels and requests. A payment channel opened by an agent counts against its limits when it opens. The ledger honours a voucher on it only if the voucher was signed before the agent's revocation, quarantine or expiry, and a payee accepting vouchers off the ledger runs the same check, so a revoked agent's channels stop paying everywhere at once. Serving nodes sign an agent's requests under RFC 9421 in the web bot authentication profile, and a revoked, quarantined or expired agent's key directory is empty from the next block. An agent's accounts on other chains pay only under a live grant from its terms.
Evidence an outsider can check. An agent's payments can be exported as an evidence pack and verified offline against a certified state root; the verifier refuses a record made by an agent the pack does not cover. Anyone can read an agent's terms, its root kind, its status and its spend against each limit.
