Key takeaways
- Five controls do most of the work: least-privilege access, human approval, hard limits held outside the model, simulation, and logs with a stop switch.
- A confirmed on-chain transfer generally cannot be undone, so a control has to act before the transfer, not after it.
- A portfolio tracker needs read access only: a read-only API key or a public wallet address, never a private key or a seed phrase.
- OWASP's 2025 list of ten risks for LLM applications names prompt injection (LLM01:2025) and excessive agency (LLM06:2025). The same controls limit both.
- The NIST AI Risk Management Framework, released on January 26, 2023, is voluntary. Neither NIST nor OWASP certifies a product.
This guide is part of the AMBR guides to AI agents in finance and covers controls only. For the basics, start with the guide to what an AI finance agent is.
Terms used in this guide
- AI agent: software that uses a language model to plan steps and call tools, such as an exchange API.
- Guardrail: a rule or check that limits what an agent may do.
- Least privilege: giving a program only the access its job needs.
- API key: a credential that lets software use an account within set permissions.
- Human in the loop: a person approves an action before it happens.
The glossary has prompt injection, guardrails and other terms defined.
Why digital assets raise the stakes for AI agents
Three facts of the setting turn an agent's mistake into a loss: transfers are final, access is by keys, and markets never close.
- Transfers are final. A confirmed transfer on a public blockchain generally cannot be undone. Bitcoin.org tells new users that a transaction cannot be reversed, only refunded by whoever received it (source 7).
- Access is by keys. Whoever holds a private key controls the wallet, and an API key can do whatever its permissions allow. No bank fraud desk reads the instruction first.
- Markets never close. Public blockchains process transactions around the clock, so an agent can act at an hour when nobody is watching the account.
That is why every control in this guide sits in front of the transfer.
Not financial advice. Crypto is highly volatile and may drop in value significantly. You may lose the amounts you invest and your investments do not benefit from any form of financial protection.
This article is for information only and is not investment, legal or tax advice. The risk disclosure for AI agents and virtual assets covers model error and market risk.
Six ways an agent can cause a loss
An agent can lose you money in six ways, and two of them are on OWASP's 2025 list of ten risks for LLM applications (source 1). The other four come from how exchange accounts and wallets work.
Prompt injection
Prompt injection is text that changes what the model does. OWASP lists it first, as LLM01:2025, and separates direct injection, typed in by a user, from indirect injection, carried in content the model reads, such as a web page or a file (source 2). It adds that it is unclear whether fool-proof prevention exists. Example: an agent summarising news reads a page that contains a line addressed to the agent itself. If that agent can also transfer, the page's author has a say in your account.
Excessive agency
Excessive agency means the agent can do more than its job needs. OWASP lists it as LLM06:2025 with three root causes: excessive functionality, excessive permissions and excessive autonomy (source 3). Example: a tool built to show balances is connected with a key that can also trade and withdraw. Any model error or injected instruction now reaches further than the task required.
Wrong or stale data
A model can state a wrong figure with confidence, or act on a price that is minutes old. Example: the agent reads an outdated balance and sizes an order on the wrong number. Every figure an agent shows should carry its time and its source.
Over-broad keys and wallet permissions
A key or wallet permission that allows more than the job needs turns a small fault into a large one. Example: a monitoring key is left with trading and withdrawal rights on, or a wallet is connected with the power to sign when the tool only needs to look. A standing token allowance, which lets another program spend a token up to a set amount, belongs in the same group.
Irreversible transactions
A transfer sent to the wrong address, on the wrong network or for the wrong amount usually stays sent. Example: an address is copied with one character changed. Getting the assets back depends on the recipient choosing to return them, which is what makes every other risk expensive.
Over-reliance by the person
The last risk is the person: approving without reading. Example: after twenty correct prompts in a row, the twenty-first gets a tap without a look. An approval step protects you only if the screen can be read in seconds and you do read it.
Control 1: least-privilege access
Least privilege means the agent gets only the access its task needs, and a portfolio tracker needs one permission level out of three: read. OWASP's guidance on both risks above says the same: restrict access to the minimum necessary (sources 2 and 3).
| Level | What it allows | Which tool needs it |
|---|---|---|
| Read | View balances, open orders and history | A tracker or a reporting tool |
| Trade | Place and cancel orders inside the account | A tool that carries out orders you have approved |
| Withdraw | Send assets out of the account | Almost no agent; keep it off unless a transfer is the service |
Source 6 is one public API reference that separates querying, order and withdrawal permissions. Naming it does not mean Ambre supports that venue. Last reviewed .
Read-only API keys
A read-only key can view balances, open orders and past trades, and nothing else. That covers what a tracker does. Create a separate key for each tool, so one can be revoked without breaking the others. The page on an AI portfolio tracker that reads brokerages, exchanges and wallets sets out what AMBR has and has not published about the access Ambre asks for.
Check
If a tool that only reports asks for trading or withdrawal rights, ask why before you create the key.
Withdrawals off and address allow-lists
Keep withdrawal permission off for any key an agent holds, unless moving assets out is the service you signed up for. Where it is, an address allow-list means the venue sends only to addresses you approved in advance. Check whether your venue also makes a newly added address wait before it can be used.
Watch-only wallet addresses
To watch a self-custody wallet, a tool needs the public address and nothing more. On a public blockchain such as Bitcoin, anyone can see the balance and transactions of an address (source 7). Refuse any tool, person or message that asks for a private key or a seed phrase in order to track a wallet.
Control 2: human approval
Human approval means a person confirms an action before it runs, and OWASP names it as a mitigation for both LLM01:2025 and LLM06:2025. For digital assets the working rule is short: anything that moves value waits for you.
In the loop, on the loop, out of the loop
- In the loop: the agent prepares an action and a person must approve it before it happens.
- On the loop: the agent acts by itself while a person watches and can step in or stop it.
- Out of the loop: the agent acts and no person reviews the action before or while it happens.
For transfers and orders, ask for in the loop. On the loop suits low-stakes work such as alerts and reports.
What a good approval screen shows
A good approval screen shows six things on one screen.
what an approval screen should show before you confirm
- asset
- which asset, and on which network
- amount
- the exact quantity, and its value in your currency
- destination
- the full address or venue, and whether you have used it before
- fee
- network and service fees, shown before you confirm
- reason
- why the agent proposes the action, in one sentence
- if you do nothing
- the request expires and nothing is sent
If it shows less, you are approving a summary, not a transaction.
Control 3: hard limits the model cannot change
A hard limit is a cap enforced outside the model, in code or in the venue's settings, so no prompt can raise it. OWASP calls the principle complete mediation: the downstream system, not the model, decides whether an action is allowed (source 3).
A limit written into a prompt is a request. A limit enforced in code is a control.
Control 3: hard limits
Per-transaction and daily caps
A per-transaction cap bounds a single mistake, and a daily cap bounds a run of them. If the agent can raise a cap, it is not a limit. The worked example uses invented numbers.
worked example: illustrative figures, not a real account
- balance
- assets worth US$10,000 in one exchange account
- limit
- US$250 per transfer, US$1,000 per day, approved addresses only
- request
- a manipulated agent asks to send US$9,000 to a new address
- result
- refused: the address is not on the list, and the amount is 36 times the cap
- worst case
- if an approved address were misused, US$1,000 in one day (10% of the balance) instead of US$9,000 (90%)
The numbers are invented to show how caps bound a loss. They are not suggested settings.
Asset and venue allow-lists
An allow-list names what the agent may touch: assets, trading pairs, venues and destination addresses. Everything else is refused by default, which shrinks the space in which an error or an injected instruction can act.
Delays and cancel windows
A delay puts time between approval and execution for large or unusual actions, and a cancel window lets you withdraw the instruction meanwhile. Since an on-chain transfer cannot be recalled, this is the last chance to catch an error. OWASP makes a related point about rate limits: they reduce how much can go wrong before monitoring notices (source 3).
Control 4: simulate before you execute
Simulation runs the exact transaction as a preview and shows the expected result before anything is signed or sent. Ethereum's JSON-RPC interface, for example, documents a call that executes a message without creating a transaction on the chain (source 8).
A preview should state what leaves the account, what arrives, the fee and the destination. If the simulated result differs from what you asked for, or from the approval screen, the action stops. A preview is an estimate, not a promise: prices and fees can move before execution, so the caps in control 3 still apply.
Control 5: logs, alerts and a stop switch
Logs, alerts and a stop switch do not prevent an error; they limit how long it runs. OWASP lists logging and monitoring for that purpose (source 3). Four things belong here.
- A record of every action: time, input, decision and outcome, in a form you can export.
- Alerts on unusual behaviour: a new destination, an amount near a cap or repeated failed attempts.
- A stop switch: one place to pause the agent, and a tested way to revoke its keys at the venue, which works even if the agent's own app does not respond.
- An incident notice with a time limit: within how many hours the provider will tell you that something went wrong, stated in writing.
Control matrix: risk, control and the question to ask
The matrix maps each of the six risks to the control that addresses it, the evidence to ask for and one warning sign. The AMBR Research Team drew it up for this guide as a working aid, not a standard. Figure 1 shows why the controls are stacked: each layer assumes the one before it can fail.
| Risk | Control to use | Evidence to ask for | Warning sign |
|---|---|---|---|
| Prompt injection | Limits held outside the model; approval for every transfer | Where each limit is enforced, and the latest adversarial test | "The model is told not to" is the only defence offered |
| Excessive agency | Least-privilege keys; a short list of permitted actions | Each permission requested, with the reason for it | Trade or withdrawal rights requested for a reporting job |
| Wrong or stale data | Preview and simulation; time and source on every figure | A sample output showing data time and source | Figures shown without a time or a source |
| Over-broad keys and wallet permissions | Read-only keys, withdrawals off, watch-only addresses | Setup steps showing that withdrawal rights are not needed | A request for a private key or seed phrase |
| Irreversible transactions | Caps, address allow-list, delay and cancel window | The default caps, and who can change them | No cap, or a cap the agent can raise when asked |
| Over-reliance by the person | A clear approval screen, alerts, regular log review | A sample approval screen and an exported log | Many approvals bundled into one tap; no log to export |
Source: AMBR Research Team, drafted for this guide. Last reviewed .
What the frameworks expect
Two public frameworks describe these controls, and neither certifies a product: the NIST AI Risk Management Framework and the OWASP Top 10 for LLM Applications.
NIST AI Risk Management Framework
The US National Institute of Standards and Technology released the AI Risk Management Framework (AI RMF 1.0) on January 26, 2023. It is intended for voluntary use, to help organisations build trustworthiness into the design, development, use and evaluation of AI systems (source 4). A generative AI profile, NIST-AI-600-1, followed on July 26, 2024, and NIST says AI RMF 1.0 is being revised. A vendor that says it follows the framework is describing its own process, so ask for the evidence.
OWASP Top 10 for LLM Applications
The OWASP Top 10 for LLM Applications 2025 is a community list of ten risks with mitigations, numbered LLM01:2025 to LLM10:2025 (source 1). Its mitigations for prompt injection and excessive agency include least-privilege access, human approval for high-impact actions, authorisation enforced in downstream systems, and logging: the controls in this guide. It is guidance for builders, not an audit scheme.
Financial regulators set their own expectations for AI in financial services. The rules by jurisdiction, with dates and primary sources, are in the guide on AI agent liability and the rules in each jurisdiction.
A twelve-point checklist before an agent goes near your assets
Run these twelve checks before you connect an agent to an exchange account or a wallet. Each one is something you can see or test, not a promise.
- Key scope. Read-only unless the task needs more, with a reason for each extra permission.
- Withdrawal off. The key cannot move assets out of the account.
- Address allow-list. Any transfer goes only to addresses you approved in advance.
- Caps. A per-transaction cap and a daily cap are set, and you know both numbers.
- Approval for every transfer. Nothing that moves value runs without your confirmation.
- Preview before approval. You see the simulated result of the exact transaction first.
- Limits held outside the model. Caps and lists are enforced in code or at the venue; the agent cannot change them.
- Logs you can export. Every action is recorded with time, input and outcome.
- Alerts on unusual activity. New destinations, amounts near a cap and failed attempts reach you.
- Revoke path tested. You have revoked a test key at the venue and seen the agent lose access.
- Incident notice period. The provider states in writing how fast it will tell you.
- Exit and deletion. You know how to disconnect and what happens to your data and keys.
Who the legal entity is, which licence covers execution and where to complain are separate questions, answered in the guide to responsibility and liability for AI agents.
How AMBR describes the controls in Ambre
AMBR has published two statements about control in Ambre, its AI agent for personal finance, and no technical detail yet. The live Ambre page, read on 6 October 2026, says: "AI leads the experience while you remain in control." It adds that human expertise is available when judgment or execution is required. The agents overview page says Ambre works with users remaining in control of consequential decisions and actions.
Both statements bear on point 5 of the checklist, approval, in general terms. On the other eleven points nothing was found on www.ambr.io when it was read: no key scopes, caps, previews, exportable logs, alerts, revocation steps, incident notice period or exit terms. Until those answers are public, ask for them in writing before you connect an account.
Ambre is an AI system. Its outputs can be wrong, and it does not give personal investment advice. The dated security and controls page for AMBR agents records what AMBR has published and what is still open, and the Ambre page sets out what Ambre can and cannot do.
Frequently asked questions
What are AI agent guardrails?
AI agent guardrails are the rules and checks that limit what an agent may do. Some sit in the prompt. The ones that hold under pressure sit outside the model: API permissions, caps, allow-lists and approval steps enforced in code or by the venue. A guardrail the model can be talked out of is weaker than one it cannot reach.
Should an AI agent ever hold my private keys?
No, not for monitoring. A tracker needs only a public address, because balances and transactions can be read from the network. A private key or seed phrase gives full control of the wallet, including the power to send everything out. If an agent must transact on-chain, give it a separate wallet with a small balance, never the keys to your main holdings.
What does human in the loop mean for an AI agent?
Human in the loop means the agent prepares an action and a person must approve it before it happens. It differs from human on the loop, where the agent acts while a person watches and can stop it, and from out of the loop, where no person reviews the action. For anything that moves value, ask for in the loop.
Can a read-only API key lose me money?
Not directly: a read-only key cannot place orders or move assets. It can still expose your balances and trading history to whoever holds it, which helps scammers target you. It can also feed an agent stale data that you then act on yourself. Treat it as sensitive and revoke it when a tool is no longer in use.
What should happen after an AI agent incident?
First the agent is paused and its keys are revoked at the venue. Then the logs are reviewed to establish what happened. The provider should notify you within the period it committed to in writing, explain the cause and say what has changed. Keep your own exported copy of the logs.
Sources
The eight linked pages were opened and read for this guide in October 2026. They are paraphrased, not quoted at length.
- OWASP Gen AI Security Project, "2025 Top 10 Risk & Mitigations for LLMs and Gen AI Apps" (the OWASP Top 10 for LLM Applications 2025), genai.owasp.org/llm-top-10.
- OWASP Gen AI Security Project, "LLM01:2025 Prompt Injection", genai.owasp.org, LLM01:2025.
- OWASP Gen AI Security Project, "LLM06:2025 Excessive Agency", genai.owasp.org, LLM06:2025.
- National Institute of Standards and Technology, "AI Risk Management Framework", nist.gov.
- Virtual Assets Regulatory Authority, public register entry for Amber Premium FZE, VASP Licence VL/26/03/003, vara.ae. Amber Premium FZE is permitted to serve Institutional Investors and Qualified Investors. The entry gives www.ambr.io/uae as the licensee's website, which is why this guide carries the risk statement for virtual assets.
- Kraken, "API key permissions", developer documentation, docs.kraken.com. Cited as one public example of how an exchange separates API permissions. AMBR has not published which venues Ambre supports; no venue is presented here as supported.
- Bitcoin.org, "Some things you need to know", bitcoin.org.
- ethereum.org, "JSON-RPC API", developer documentation, entry eth_call, ethereum.org.
- AMBR, Ambre product page at www.ambr.io/agents/ambre, read 6 October 2026. Source of the quoted control statement.
- AMBR, agents overview page at www.ambr.io/agents, read 6 October 2026. Source of the statement that users remain in control of consequential decisions and actions.