ArchitectureAI Studio

Bounding what an AI agent can sign and spend on Hedera

An agent that can move tokens needs limits it cannot talk its way around. On Hedera that means keys out of the model's reach, a dedicated account or allowance instead of treasury access, deterministic policy checks on every proposed transaction, and threshold keys or scheduled co-signatures for actions that are expensive to undo. Below are the architecture, a risk-tier table and the monitoring that lets you stop an agent quickly.

Reviewed 10 October 2026 8 min read

On this page

Four ways a transacting agent goes wrong
Reference architecture: propose, authorise, sign
Choosing an Agent Kit execution mode per action
Give the agent a wallet, not the treasury
Key structures for shared control
Policy checks to run before any signature
Monitoring, revocation and the stop button
Risk tiers and the controls each one needs
Hypothetical: a procurement agent with a weekly budget
Questions and answers
Sources

Four ways a transacting agent goes wrong

A better system prompt fixes none of these; each needs a control outside the model.

Prompt injection

Early signalA proposed payee or amount appears nowhere in the task, often right after the agent read external content.

MitigationPayees come from an allow-list keyed by account ID, never from model text, and the policy layer rejects anything else.

Tool misuse

Early signalA read-only task triggers a write tool, or a token tool receives the wrong token ID.

MitigationLoad only the plugins a task needs and give each tool a narrow, typed signature validated on the server side.

Runaway loops

Early signalNear-identical transactions repeat after a timeout or an ambiguous error.

MitigationIdempotency keys per task step, frequency caps in policy, and uncertain outcomes routed to a person instead of a retry.

Wrong amounts or units

Early signalAmounts off by orders of magnitude, from confusing HBAR with tinybars or ignoring a token's decimals.

MitigationThe tool accepts one stated unit, and policy converts to base units and checks the result against caps before approval.

Reference architecture: propose, authorise, sign

Each layer can refuse the one above it. Only the lower layers touch keys or the network.

Agent and model
Plans the task and drafts a typed intent; holds no credentials.
Narrow tools
Accept structured parameters only, such as a listed payee ID and an amount in base units.
Policy service
Deterministic checks on payee, token, amount, frequency and time window, with every decision logged.
Human approval
Receives unsigned bytes or a pending schedule for actions above the autonomous tier.
Signing service
Keys live in a KMS, HSM or custodian and sign only requests that carry a policy approval.
Hedera network
Enforces balances, allowances, key lists and threshold keys whatever the software above it does.
Independent monitoring
Mirror-node watchers that alert on unexpected transactions and can trigger revocation.

Conceptual layering for bounded agent authority. Layers may share infrastructure; what matters is that each can refuse independently.

Choosing an Agent Kit execution mode per action

The Agent Kit's execution mode decides who signs¹. Different tools in the same system can run in different modes.

If
The action only reads data: balances, topic messages, token details.
Then
Run query tools without approval, logging what was read.
Queries cannot move value; a rate limit on cost is enough.
If
The action is a small, repeatable payment to a known payee within an agreed budget.
Then
Autonomous execution is acceptable only from a dedicated agent account with a capped balance or allowance, with a policy check wrapping the tool.
The ledger caps the worst case even if every software check fails.
If
The action moves meaningful value, pays a new counterparty or changes token supply.
Then
Use return-bytes mode, so the agent hands back unsigned transaction bytes for a person or approval system to inspect and sign.
The approver sees the exact transaction, not the agent's description of it.
If
Keys must stay in an HSM, KMS or MPC service, or approvals already run through an existing console.
Then
Use a custom execution strategy that forwards each transaction to that service after your policy check.
Custody stays with systems your security team already governs, and the kit still returns a full receipt¹.

Give the agent a wallet, not the treasury

The simplest limit the ledger itself enforces is an account that cannot hold much. A dedicated agent account, topped up on a schedule by a treasury process the agent does not control, caps what a compromised agent can lose at the current balance, and isolates its activity on a mirror node.

Allowances suit cases where funds should stay in a central account. The owner approves a spender account to transfer up to a set amount of HBAR, a fungible token or specific NFTs; the spender then moves funds with an ordinary transfer and pays the fee itself². Reducing an allowance is a new approval for the smaller amount, so revocation is one signed transaction away².

Neither mechanism understands time. An allowance is a ceiling on the total, not a weekly budget, and a balance says nothing about how many payments leave it. Rate, frequency and per-payee limits live in the policy service, with the ledger as backstop if that service is bypassed.

Key structures for shared control

Hedera supports compound keys and delayed signing natively, so the actions that matter most can require more than one party.

Key list: A key made of several keys that must all sign: for example, the signing service and a separate control service, so neither can act alone.
Threshold key: A key needing a minimum number of signatures from a set, such as any two of three. It suits administrative keys on agent accounts or tokens, where one compromised holder should not be enough.
Scheduled transaction: A transaction wrapped in a schedule that executes once the required signatures arrive, or at its expiry if wait-for-expiry is set³. The agent can create the schedule while a person adds the final signature; the network caps expiry at 62 days³.
Schedule admin key: Needed to cancel a pending schedule, since a submitted schedule cannot be edited, only deleted and recreated³.

Policy checks to run before any signature

Write these as tested code in the policy service, not as prompt instructions.

0 of 8 checked

Payee is on the allow-listMatch on account ID, and require a separate, human-approved change to add a payee.
Token is permitted for this taskCheck the token ID, never its symbol or name, which anyone can copy.
Amount is within the per-transaction capCompare in base units, using the token's decimals from a trusted lookup.
Rolling totals stay within budgetSum approved spend per agent, payee and period from your own records.
Frequency matches the taskReject bursts beyond the expected cadence and flag them for review.
The request is not a repeatRequire an idempotency key per task step and refuse duplicates.
A maximum fee is setCap the transaction fee so an unexpected fee cannot drain the payer account.
The memo holds a reference onlyMemos are public: an internal task reference, never personal or commercial detail.

Monitoring, revocation and the stop button

Watch agent accounts from outside the agent. A mirror-node subscriber that matches each transaction to a policy approval will catch anything signed by another route: the sign of a leaked key or a bypassed control.

Prepare three stops and rehearse them before go-live: disabling the signing service's approval path, which halts the agent at once; reducing allowances to zero with a fresh approval; and rotating the agent account's key with an update signed as its key structure requires. Name who may trigger each stop.

Risk tiers and the controls each one needs

Assign every tool to a tier before build; moving a tool up a tier is a design change.

Control	Read-only queries	Low-value payments to known payees	Token transfers or new payees	Administrative actions
Execution route	Query tools, no signature needed	Autonomous or custom strategy from a dedicated account	Returned bytes signed by a person	Scheduled transaction with threshold co-signers
Ledger backstop	Not needed	Capped balance or allowance	Allowance sized to the single transfer	Threshold key or key list on admin keys
Policy checks	Rate limits to control query cost	Allow-list, caps, frequency and time window	All of those plus out-of-band payee verification	Change ticket reference and a second approver
Examples	Balances, topic reads	Metered API usage	Invoices, first-time suppliers	Key rotation, minting

Tiers are illustrative. Your risk team should set the thresholds in your own currency and context.

Hypothetical: a procurement agent with a weekly budget

Questions and answers

Should an AI agent ever hold a private key?

Not in its context, its memory or any file it can read. The agent may operate an account that a key controls, but the key should sit in a signing service, KMS, HSM or custodian that signs only requests carrying a policy approval. If a model can print or pass on a key, prompt injection can extract it, so apply this rule on testnet too.

How do we audit what an agent signed?

Keep three records for each transaction and reconcile them: the policy service's decision with the proposed parameters, the signing service's log, and the transaction as it appears on a mirror node. Anything on the mirror node without a matching approval is an incident. For what a complete action record should hold beyond the transaction itself, see verifiable audit trails for agent actions.

Can agent spending limits be enforced on-chain rather than in software?

Partly. Balances, allowances, key lists, threshold keys and scheduled transactions are enforced by the network, so they hold even if your software is compromised. Rolling budgets, per-payee caps and time windows are not native account features; they need a policy service or a smart contract that holds funds and applies the rules. Contracts add audit and upgrade work, so most designs pair native limits with off-chain policy.

What should the agent do if the policy service is unavailable?

Stop moving value. Design the signing service to refuse anything without a fresh approval, so an outage fails closed rather than open. Read-only tools can keep working, and the agent should report that payments are paused instead of retrying. Queue the intents with their idempotency keys so they are re-evaluated, not replayed, when the service returns.

Sources

Hedera Agent Kit (JavaScript) repository and README — Hashgraph on GitHub · checked 10 October 2026
Approve an allowance — Hedera documentation · checked 10 October 2026
Scheduled transactions — Hedera documentation · checked 10 October 2026

Have your agent's authority design reviewed before it reaches mainnet

Send us the agent's task, the tools it calls and how its keys are held today. We will map each tool to a risk tier and show where limits, approvals and stop controls should sit.

Request an authority review