Fifteen controls to prove an agent stays inside the authority it was actually given.
The short answer. Valid credentials do not prove an action is authorized. This checklist gives 15 controls to verify before an AI agent is allowed to buy, book, send, delete or change anything, grouped into identity, transaction limits, tool and prompt-injection safety, monitoring and testing.
Depending on its integrations, an agent can pick products, prepare purchases, book services, change subscriptions and edit business records. That raises one question: can you show that every action it takes is authorized, appropriate and within the user's intended limits?
An agent can hold valid credentials to a payment-enabled app and still exceed a budget, act on malicious instructions hidden in a document, send data to an unapproved recipient or repeat an order after a workflow error. Access controls stay essential. Agents that can transact also need action boundaries, independent authorization checks, approvals where they matter and reliable monitoring.
This page complements AI agent token security, which covers the threat landscape, and AI agent credential security, which covers storing and scoping the keys themselves. Here the focus is the action.
For each control, ask whether it is implemented, tested and backed by evidence. A written policy is not evidence. Score each control with one of three statuses:
Evidence can be a configuration review, logs, a controlled test case or a documented approval workflow. This is a practical starting point, not a certification and not a guarantee that an agent is secure.
Question: can the system tell which agent acted, on whose behalf, and which identity authorized the operation?
Agent identity and user identity are not the same. You need to separate the agent executing an action from the person or business that granted the authority.
Verify:
Risk if missing: investigators cannot tell an authorized request from a workflow glitch or a compromised integration.
Question: can the agent do only what its task needs?
A price-comparison agent may need to read product data. It does not need to place orders or change account settings. Separate read, prepare, approve and execute rights where practical.
Verify:
Risk if missing: a manipulated agent inherits excessive authority across connected systems.
Question: can access be cut quickly if the agent, a credential or an integration is compromised?
Prefer short-lived, narrowly scoped credentials where supported.
Verify:
Risk if missing: unauthorized access outlasts the incident. Details are in credential security.
Question: can the agent exceed its approved spending, quantity, frequency or operation limits?
Trusted application logic should enforce limits. Do not rely on the model to remember them. A purchasing agent might have a maximum total, a quantity cap and a ban on recurring purchases. A records agent might have a cap on changes per period.
Verify:
Risk if missing: a small instruction error or a manipulated workflow causes large or repeated actions.
Question: does the system check where money, data or an operation is going before it runs?
A prompt or tool output recommending a new recipient is not a reason to accept it. Destinations include merchants, payees, bank accounts, email addresses, export endpoints and business systems.
Verify:
Risk if missing: a legitimate workflow sends funds or confidential data to the wrong place.
Question: does the approval cover what will actually execute?
A user approves a product, amount or recipient. If the total or destination changes before execution, the approval may no longer apply. Re-check material details immediately before the action and ask again when it falls outside what was approved.
Verify:
Risk if missing: the agent executes something materially different from what the user agreed to.
Question: do the right actions need human confirmation or a higher authorization?
Not every step needs a person. Too many prompts make a system unusable and push people toward workarounds. High-value purchases, transfers, irreversible deletions, sensitive exports and major account changes are the usual candidates.
Verify:
Risk if missing: consequential actions run without meaningful authorization.
Question: does a trusted component independently confirm the action is allowed?
Prompts help steer behaviour. They should not be the only barrier. Put policy in application code, API gateways, tool servers or a policy layer. OWASP's Excessive Agency guidance (LLM06:2025) makes the same point: enforce authorization in downstream systems instead of leaving the decision to the model.
Verify:
Risk if missing: an unexpected model decision becomes an action that should have been blocked.
Question: are the agent's tool requests checked before they reach a connected system?
A model-generated request is not automatically safe. Validate parameters, resource IDs and operation types, and let the downstream service enforce its own permissions.
Verify:
Risk if missing: the agent calls a tool in an unexpected way or exploits a gap between the agent and the service. See AI agent tool security: MCP and function calling and, for tokenizer-level bypasses, token smuggling.
Question: can malicious content push the agent past its authority?
Agents process web pages, emails, files, tickets and tool output, and any of them can carry hostile instructions.
Verify:
Risk if missing: an attacker turns the agent's access into an operation. HexTyx saw this in its own test apps: in the Vault app (synthetic data, live LLM agent) an injected fake confirmation led the agent to move $5,000, and in the Mercury app an agent sent a zero-click exfiltration email. See AI agent credentials and API-key abuse and what prompt injection is.
Question: can a retry, a repeated tool call or a replayed request run a transaction twice?
Agent workflows retry after timeouts and unclear responses. Without safeguards that can mean duplicate orders or payments.
Verify:
Risk if missing: a transient fault creates repeated financial or operational effects.
Question: can you reconstruct what the agent tried, why it was allowed and what happened?
Logs should help an investigation without becoming a new leak.
Verify:
Risk if missing: suspicious activity is hard to detect, investigate or explain.
Question: can you spot suspicious patterns and stop an agent before impact grows?
Watch for odd transaction frequency, repeated authorization failures, unexpected destinations, abnormal tool use and activity outside normal scope.
Verify:
Risk if missing: unauthorized actions continue without timely intervention. See circuit breakers for rogue AI agents.
Question: can you safely stop the agent, revoke access and recover?
Switching off the model is not enough if credentials stay valid or queued operations keep running.
Verify:
Risk if missing: you cannot contain an incident quickly or confirm the threat is gone. See the AI agent kill switch and dead man's switch guide.
Question: has the agent been tested against realistic misuse, and were fixes verified?
Test the complete workflow, not only model replies. Depending on the agent, cover:
Testing must be authorized, scoped and done in a safe environment. Use test environments for payment and financial flows so no real transactions occur.
Verify:
Risk if missing: the system looks safe in routine use while staying open to predictable misuse. For wider ideas see AI API attack vectors and agentic AI red teaming.
Rank by impact, likelihood, the agent's authority and the strength of existing safeguards. This table is an illustration, not a universal severity scale.
| Priority | Example finding | Response |
|---|---|---|
| Critical | Financial actions can run without enforced limits or required approval | Restrict or disable the capability until an effective safeguard is verified |
| High | Excess permissions or destination changes can expose data or allow unauthorized actions | Reduce permissions, enforce independent authorization |
| Medium | Monitoring, duplicate handling or audit evidence is incomplete | Add and test the missing safeguards |
| Lower | Documentation needs work, technical controls already verified | Assign an owner and schedule it |
An agent that can transact sits where AI behaviour, credentials, tools, APIs and business authorization meet. HexTyx tests the behaviour side: the scanner's 33 attack modules include indirect prompt injection and agentic tool abuse against agents that hold real tools, and the Aegis Runtime Shield checks traffic at five points (input, retrieval, tools, output and audit). It does not replace payment-network controls, and it cannot confirm your approval workflow or limit logic exists. Use this checklist to find what needs review, then scope an authorized test around your architecture. Start in the free playground.
Run the free playground scanner against your AI application and see what an attacker could make it do.