AI Agent Security Checklist: 15 Controls Before You Connect an Agent to Business Systems

An AI assistant drafts an answer. An AI agent can take the next step.

Depending on its configuration, an agent may search files, read email, update a CRM, call an API or trigger a workflow. That ability can remove repetitive work. It also changes the risk: an inaccurate action can alter data, contact a customer or disrupt a process.

This practical deployment gate applies to vendor-built agents, low-code automations and custom systems.

Important: This is educational guidance, not a security certification or legal opinion. Adapt it to your architecture, obligations and risk tolerance. High-impact systems require qualified review.

Why AI Agents Need More Control Than Chatbots

A chatbot normally waits for a person to ask a question and returns text for review. An agent may combine five capabilities:

Goal: It receives an outcome rather than one simple instruction.
Planning: It selects intermediate steps.
Memory or context: It retains information across a task or session.
Tools: It connects to search, email, documents, databases, APIs or code.
Action: It changes something outside the model.

Each capability expands what can go wrong. A vague goal may produce an unintended plan, a malicious instruction hidden in a document may influence the agent, and an over-privileged connector may expose unrelated records.

This is why “the model has safety controls” is not an adequate security answer. The surrounding identity, permissions, workflow, monitoring and recovery controls determine the business impact.

What Current Authoritative Guidance Says

The following points are verified facts. The 15-control checklist later in this article is AIXYZ’s practical interpretation for organizations.

On August 20, 2026, the UK National Cyber Security Centre published interim advice on managing the cyber risk of agentic AI. It recommends matching controls to autonomy, conducting threat modelling, maintaining human oversight for consequential activity, isolating agent environments, logging activity and preserving an emergency shutdown capability. The NCSC explicitly notes that its formal guidance is still evolving and will eventually supersede the interim blog.

Earlier joint guidance summarized by the NCSC on May 15, 2026 recommends that organizations start with tightly bounded, low-risk pilots, apply least privilege, avoid long-lived credentials, monitor behaviour and include agent failures in incident-response planning.

Australia’s cyber security authority reinforced those principles on July 24, 2026, recommending minimum permissions, human approval for sensitive actions, continuous monitoring, validation of third-party tools, progressive deployment and isolation between systems. See the Australian Signals Directorate’s secure-adoption guidance.

The OWASP Top 10 for Agentic Applications 2026 provides an industry framework for risks affecting agents that plan, act and make decisions. OWASP’s prompt-injection guidance also recommends least privilege, comprehensive logging, monitoring, incident-response procedures and emergency controls.

AIXYZ analysis

These sources converge on a simple rule: do not treat an AI agent as an intelligent employee. Treat it as a powerful software identity operating under uncertainty.

Controls should become stricter as the agent gains sensitive data, broader permissions, higher volume or greater autonomy. A read-only knowledge agent is not equivalent to one that can send email, change financial records or run production code.

Start With an Autonomy and Impact Rating

Classify whether the agent only recommends, prepares an action for approval, executes a defined reversible action or operates broadly across systems. Begin with the least autonomy that still produces useful evidence. Broad, consequential activity requires the strongest oversight and should not be the starting point.

Use AIXYZ’s AI Use Case Prioritization Matrix to test business value and implementation readiness before approving a pilot.

The 15-Point AI Agent Security Checklist

Score each control as Ready, Partially Ready or Not Ready. A “Not Ready” answer in access, approval, logging or shutdown should block production deployment.

1. Define One Bounded Business Task

Write exactly what the agent may accomplish, for whom and in which systems. “Help with customer service” is not a boundary.

A scoreable definition is:

For support representatives, the agent may search the approved warranty knowledge base and prepare a response to routine questions. It may not access billing records or send the response.

Document the allowed inputs, outputs, tools, users and operating hours. If the team cannot define the boundary, it cannot enforce it.

2. Prove That an Agent Is Actually Necessary

An autonomous agent is not always the right solution. A search tool, deterministic workflow, form validation rule or human-approved automation may solve the problem with less uncertainty.

Ask:

Does the task genuinely require flexible reasoning or planning?
Could a normal business rule handle the critical action?
Can AI recommend while conventional software executes?
What benefit disappears if a person must approve the result?

Complexity is not value. Choose the lowest-risk architecture that meets the outcome.

3. Assign a Named Business and Technical Owner

One person must own the business outcome, and one must own technical operation. The same person may fill both roles in a small company, but the responsibilities must be explicit.

Ownership includes approving access, reviewing exceptions, coordinating incidents and deciding whether to pause the agent. A vendor cannot own your accountability.

4. Give the Agent Its Own Identity

Do not let an agent operate through a shared employee account. Use a distinct service identity where the platform supports it so actions are attributable, access can be reviewed and credentials can be revoked without disabling a person’s account.

Record who approved the identity, which environments it can enter and when access expires.

5. Apply Least Privilege

Grant only the minimum data and actions required for the defined task.

An invoice-classification agent may need to read one intake folder and write a status. It does not need the entire finance drive, vendor master data, payment functions and email.

Prefer:

Read-only access before write access
One folder or object type before an entire repository
Named API operations before broad administrator roles
Temporary credentials before permanent secrets
Test environments before production

6. Separate Reading From Acting

Content an agent reads may contain instructions it should not follow. This is the central danger of indirect prompt injection: a webpage, email or document can attempt to influence the agent’s behaviour.

Architecturally separate untrusted content from privileged actions. Treat retrieved content as data, not authority. Use allowlisted tools, validate parameters and require approval before consequential actions.

Prompts alone are not a security boundary.

7. Classify and Minimize Data Access

List every data source the agent can read, create, retain or transmit. Classify the information as public, internal, confidential, personal or regulated.

Remove anything unnecessary. Test first with synthetic, de-identified or approved low-sensitivity data. Confirm retention, training, residency and deletion terms for the exact plan and features used.

Your AI acceptable-use policy should define the organization-wide rules; the agent record should document the narrower rules for this deployment.

8. Approve Every Tool and Integration

Create an inventory of models, plugins, MCP servers, APIs, connectors, libraries and external services in the agent’s path. Record the publisher, version, permissions, data exchanged and business owner.

A connector expands both access and supply-chain dependency. Treat tool or permission changes as new deployment events.

For background on the connection mechanism, see AIXYZ’s guide to adding an MCP server to ChatGPT.

9. Put Human Approval Before Consequential Actions

Identify actions that must never occur without a qualified person’s approval. Common examples include:

Sending external communications
Creating or changing payments
Modifying customer, employee or citizen records
Deleting files or records
Publishing content
Changing access rights
Running code or commands in production
Making employment, eligibility, legal or safety decisions

The approval must be technically enforced. “Ask first” is weaker than a workflow that blocks execution until a named approver authorizes it.

10. Set Volume, Time and Cost Limits

An agent can create harm through scale even when each individual action appears normal. Define maximum records, messages, API calls, spending, duration and retries per run.

Enforce limits outside the model and stop the run when thresholds are exceeded. A 20-record pilot should not be capable of changing 20,000 records.

11. Threat-Model Failure and Misuse

Hold a short workshop and ask what happens if the agent:

Misunderstands the goal
Receives a malicious instruction in retrieved content
Uses the wrong record or customer
Repeats an action
Exposes confidential information
Calls the wrong tool
Loses network or model access midway
Is manipulated by an authorized user
Produces harmful, biased or fabricated output

For each scenario, record prevention, detection, containment and recovery controls. Test failures, not only successful demonstrations.

12. Log Actions in Business Terms

Logs should allow a reviewer to reconstruct what happened. Capture, where lawful and appropriate:

Agent and user identity
Task and approved scope
Data sources and tools used
Actions attempted, approved, completed or rejected
Timestamps and relevant configuration or version
Errors, retries and overrides
Result and affected records

Protect logs from alteration and sensitive-data leakage, with retention based on operational, contractual and legal needs.

13. Monitor Behaviour and Define Alerts

Do not collect logs that nobody reviews. Establish alerts for unusual access, new tools, repeated failures, volume spikes, denied actions, unexpected destinations and activity outside approved hours.

During an early pilot, run the agent only when responsible staff are available. Expand operating hours and autonomy only after the controls work under realistic conditions.

The 30-day AI pilot guide provides a baseline, measurement plan and decision gates for controlled testing.

14. Create a Kill Switch and Recovery Plan

The team must be able to stop more than the visible chat window. Define how to:

Halt the agent process and queued actions.
Revoke credentials and tokens.
Block network, API and tool access.
Preserve logs and evidence.
Identify affected records and people.
Reverse or correct actions where possible.
Notify internal and external parties when required.

Test this procedure before production. A shutdown plan that has never been rehearsed is an assumption.

15. Reassess Every Material Change

Approval applies to a defined configuration—not to “AI” forever. Reassess when the model, prompt, data, connector, permission, workflow, vendor term or autonomy changes. Track near-misses and feed lessons into controls and training.

Copyable Deployment Gate

Use this condensed checklist at a go/no-go meeting.

Gate	Evidence required	Go condition
Business scope	One bounded task and measurable outcome	Scope is specific and owned
Architecture	Data-flow and tool diagram	Every connection is known
Identity	Dedicated identity and access record	Actions are attributable
Permissions	Access matrix	Least privilege is enforced
Data	Classification and vendor-term review	Only approved data is used
Actions	Approval matrix and limits	Consequential actions are gated
Testing	Normal, adversarial and failure tests	Critical tests pass
Monitoring	Logs, alerts and review owner	Abnormal behaviour is detectable
Response	Kill switch and recovery exercise	Team can stop and recover
Governance	Change and periodic review schedule	Approval can be withdrawn

Stop conditions

Block production deployment if any of these statements is true:

Nobody can clearly explain every system and data source it can access.
The agent uses an employee’s broad personal account.
High-impact actions rely only on the agent remembering to ask permission.
Activity cannot be attributed and reconstructed.
The team cannot immediately revoke access and halt queued actions.
The pilot has no owner, baseline, test cases or decision date.
The business case depends on eliminating all human oversight before reliability is proven.

Practical Example: Customer-Service Agent

A small manufacturer wants an agent to answer warranty questions.

A risky design gives the agent the full CRM, shared drive and outbound email. A safer pilot narrows the task:

The agent searches only an approved warranty knowledge base.
Customer questions are copied into a controlled queue without payment or identity data.
The agent prepares a draft and cites the source passages used.
A representative reviews and sends every response.
The agent cannot edit the CRM, issue refunds or email customers.
Logs record the question, sources, draft, reviewer and final outcome.
The team measures response time, correction rate and unsupported claims for 30 days.

If accuracy and controls meet agreed thresholds, the organization can consider a carefully bounded next step.

Frequently Asked Questions

What is an AI agent security checklist?

It is a deployment control list for systems that can plan, use tools or take actions, covering scope, identity, permissions, data, approval, testing, monitoring and response.

Is an AI agent more dangerous than a chatbot?

Risk depends on context. Potential impact increases with broader access, autonomy, sensitive data, irreversible actions or high volume. A constrained read-only agent may be lower-risk than a poorly governed chatbot handling confidential information.

Can prompt instructions secure an AI agent?

No. Enforce permissions, isolation, validation, approval gates, rate limits, monitoring and shutdown outside the model where possible.

Should every agent require human approval?

The level of oversight should match impact. Low-risk, reversible and well-tested actions may use human monitoring instead of approval for every step. Sensitive, consequential or irreversible actions should retain technically enforced human approval unless the organization has unusually strong evidence and controls.

Who should approve an AI agent?

At minimum, business and technical owners should approve it. Security, privacy, legal, records, accessibility or procurement review may also be necessary.

How often should agent access be reviewed?

Review it periodically and whenever there is a material change to the model, tools, connectors, data, permissions, workflow or vendor terms. Temporary access should expire automatically wherever possible.

The Rule: Increase Autonomy Only After Evidence

Prevent an experiment from quietly becoming an over-privileged production system. Start with one bounded task, a distinct identity and minimum permissions. Separate untrusted content from privileged actions. Gate consequential decisions, keep reconstructable logs, set limits and prove the team can stop and recover.

Then increase autonomy only when measured performance and operational controls justify it.

Before selecting a product, use AIXYZ’s 15-point AI vendor evaluation checklist to examine security, data use, integrations, reliability and total cost. If employees are already connecting unapproved AI tools, begin with a shadow AI audit.

Call to Action

Bring the condensed deployment gate to your next AI-agent demonstration. Ask the vendor or project team to produce evidence for every row before requesting production access.

If four or more controls are only “Partially Ready,” keep the system in a bounded pilot. If identity, least privilege, human approval, logging or shutdown is “Not Ready,” stop the deployment and fix the control first.