Updated September 20, 2026
The dangerous moment in an AI project is not the first clever answer. It is the day someone connects the system to real email, files, customer records or payment tools and assumes the model will “be careful.” Care is a control, not a personality trait.
Use this AI agent security checklist before company data or real actions enter the workflow. It is a practical starting point, not a substitute for a security, privacy or legal review where the stakes require one.
1. Name one owner
One person should know why the agent exists, which systems it touches, who can change it and when it should be disabled. “The innovation team” is not an owner. Put a name and review date on the workflow.
2. Define the allowed goal
Write the task in one sentence with a finish line. “Draft replies for billing questions from the approved policy and send uncertain cases to a person” is bounded. “Handle customer service” is not.
3. Map every data source
List what the agent can read: prompts, files, webpages, messages, databases and tool responses. Mark confidential, personal and regulated data. If a source is not needed, do not connect it.
4. Give least privilege
Prefer read-only access. Restrict folders, records, domains, time windows and transaction values. Use a dedicated service account where possible. Do not give administrator rights because setup is easier.
5. Separate reading from acting
An agent that reads an email should not automatically be allowed to send one. Split high-impact actions into a separate step with approval. This creates a visible boundary between recommendation and commitment.
6. Protect secrets
Store API keys and passwords in a credential manager or the platform’s protected credential system. Never paste secrets into prompts, workflow descriptions, screenshots or normal variables. Rotate credentials after accidental exposure.
7. Treat external content as untrusted
Webpages, attachments and emails may contain malicious instructions aimed at the model. Tell the agent that retrieved content is data, not authority. Restrict which tools can be called after untrusted content is read.
8. Require approval for high-impact actions
- sending messages to external recipients;
- publishing or changing public content;
- deleting or overwriting information;
- moving money or changing payment details;
- granting access or changing permissions;
- making employment, legal, medical or eligibility decisions.
The approval should show the proposed action and relevant context. A generic “continue?” button is weak if the reviewer cannot see what will happen.
9. Set limits and stop conditions
Cap tool calls, runtime, spending and retry attempts. Define when the agent must stop: missing data, conflicting instructions, repeated failure, unexpected domain, low confidence or a request outside scope.
10. Log decisions and tool calls
Record the initiating user, important inputs, model or workflow version, tools called, approvals, results and errors. Logs need their own access controls and retention policy because they may contain sensitive data.
11. Test abuse cases before launch
Normal examples are not enough. Try a document that says “ignore previous instructions,” an ambiguous customer request, a failed API call, a duplicated message, an unusually large transaction and a user asking for a forbidden action. Confirm that the workflow stops safely.
12. Create a kill switch and review cycle
Know how to disable the agent quickly, revoke credentials and preserve logs. Review access and performance on a schedule. Remove unused tools. Re-test after model, prompt, integration or policy changes.
A one-page launch gate
| Gate | Pass when… |
|---|---|
| Purpose | The task and owner are documented |
| Access | Permissions are minimal and tested |
| Approval | High-impact actions pause with context |
| Testing | Normal and hostile cases have been run |
| Monitoring | Logs, alerts and review responsibilities exist |
| Recovery | The team can stop access and investigate |
If one gate fails, keep the agent in a draft or read-only mode. There is no prize for giving a prototype production access early.
For the concept behind the tools, read AI agents in 2026. If the connection uses an emerging standard, see MCP explained without jargon. Browser-based workflows also need the boundaries in our AI browser agents guide.
Add an incident-response rehearsal
Controls look good on paper until something fails. Run a tabletop exercise: the agent sent an incorrect external message, a credential may have leaked, or a connected server began calling an unexpected tool. Ask the team to disable the workflow, revoke access, preserve logs, identify affected records and notify the right owner.
Time the exercise. If nobody knows where the credential lives or which system contains the logs, fix that before launch. The recovery path should be written beside the workflow, not buried in a security document nobody can find.
Vendor questions that belong in the review
- Is customer data used to train shared models?
- Which regions process and store prompts, files and logs?
- Can administrators control retention and delete data?
- Does the product support single sign-on, role controls and audit logs?
- How are subprocessors and security incidents communicated?
- Can we export configuration and logs if we leave?
Answers depend on the product and plan. Save the documentation or contract version used for the decision, then review it when the service changes.
Frequently asked questions
Is human approval enough?
No. Reviewers can become tired and approve by habit. Approval works best with narrow permissions, clear context, risk-based routing and periodic sampling of approved actions.
How often should access be reviewed?
Review after material changes and on a regular schedule based on risk. High-impact tools deserve more frequent checks than a read-only knowledge source. Remove access immediately when the owner, purpose or system changes.
The uncomfortable question
If the agent makes the wrong decision at 2 a.m., who notices and what can they undo? If the answer is vague, the system is not ready for more access. Capability gets attention. Recovery is what keeps a business running.
Further reading
- OWASP Cheat Sheet Series: AI Agent, MCP, Prompt Injection and Secrets guidance
- Privacy Commissioner for Personal Data: AI resources
Which control is missing from your current pilot? Who owns the kill switch? And what is the one action the agent should never take without you?
