AI Agent Security: Risks, Controls and a Practical Business Checklist

An AI assistant becomes a different kind of business risk when it can move from answering a question to choosing a tool, retrieving sensitive context or changing a system. At that point, the security question is no longer only, “Can the model produce a bad answer?” It is also, “What authority can this workflow exercise, and what happens when it is wrong?”

For this guide, AI agent security means controlling the identities, data, tools, memory and actions used by an AI agent across its full workflow. It combines established cybersecurity controls with safeguards for systems that can interpret context, plan steps and act with varying degrees of autonomy.

This guide translates current technical guidance into decisions a business can make: which risks to map, how much authority to allow, which evidence to collect and what to check before an agent moves into production.

What AI agent security changes

A conventional chatbot usually produces content for a person to review. OWASP describes AI agents as systems that can reason, plan, use tools, maintain memory and take actions. In a business workflow, those actions could include calling an API, updating a record or sending a message. The model is only one part of that chain.

A useful way to map the system is:

Data → Context → AI → Tools → Action → Human oversight

Treat each arrow as a potential trust boundary, then document where trust or authority actually changes. Treat data and context as potentially hostile, because prompt injection can arrive through retrieved material rather than a direct user request. The agent can select the wrong tool. A legitimate tool can have excessive permissions. A correct action can still be inappropriate for the customer, account or moment.

The NIST summary of responses on AI-agent security says foundational cybersecurity remains relevant but needs adaptation for agent-specific risks. That is an important starting point: agentic AI security does not replace identity management, data protection, secure development or incident response. It extends them across a workflow that can make decisions and act.

This is why a secure AI system should be assessed as a business process, not as an isolated model demo.

Six business risks to map before launch

OWASP's current agent guidance treats prompt injection, tool misuse, data exfiltration, memory poisoning, excessive autonomy and cascading failures as distinct risks. The business task is to connect those technical categories to a plausible decision or action.

1. Untrusted instructions and manipulated context

An agent may read a webpage, email, document, support ticket or retrieved knowledge item that contains instructions written by an attacker—or simply content that conflicts with the agent's real objective. If the workflow treats retrieved text as trusted direction, the agent can be steered away from its assigned task.

The control is not a longer system prompt. Separate instructions from untrusted content, restrict which data sources can influence planning, validate important outputs and make consequential actions pass through an external policy gate.

2. Excessive identity and permissions

An agent that inherits a broad employee account, shared service credential or permanent token may be able to reach much more than its use case requires. One mistake then has the blast radius of that identity.

Give each production agent or workflow an attributable identity. Scope access by tool, data set, action and environment. Prefer short-lived credentials and make revocation part of the operating plan.

3. Tool misuse and unsafe actions

The risk is not limited to a malicious tool. An approved tool can be used with the wrong parameters, in the wrong sequence or for the wrong customer. OWASP's Model Context Protocol (MCP) security guidance also highlights tool poisoning, tool shadowing, excessive permissions and data exfiltration through legitimate channels.

Keep an allowlist of tools and permitted operations. Validate tool inputs, constrain transaction values and require explicit approval when an action changes money, access, customer communication, production data or legal status.

4. Sensitive-data exposure

For this guide, test four possible leakage routes: the visible answer, a tool call, a memory write and a connected service. A workflow can expose data through any of those routes even when the underlying model behaves as designed.

Classify the data used by the workflow. Minimise the fields the agent can retrieve, redact where possible, prevent secrets from entering prompts or memory and apply outbound controls to tool calls as well as visible responses.

5. Poisoned memory, skills or dependencies

Persistent memory can preserve a harmful instruction beyond one session. A changed connector, skill or package can also alter behaviour without a visible change to the agent's headline purpose. These are separate review cases: OWASP's taxonomy calls out memory poisoning, while dependency changes belong in the supply-chain review.

Treat memory and agent components as controlled assets. Limit what may be stored, define retention and deletion, verify tool and skill integrity, pin approved versions where practical and re-evaluate the workflow after a material dependency change.

6. Cascading failures and weak recovery

OWASP defines cascading failures more narrowly as compromised agents in multi-agent systems propagating attacks to other agents. A broader operational extension is also worth testing: an ordinary classification error can trigger messages, record changes or follow-on decisions before a person notices.

Design for interruption. Set rate and value limits, make high-impact actions reversible where possible, record the chain of decisions and test the stop, revoke and recover procedures before production.

Shadow AI makes inventory the first control

In this guide, shadow AI means agents, automations or AI-enabled workflows being used outside the organisation's approved inventory and control process. It can begin with a useful experiment: a team connects a model to documents, CRM data or a browser tool and the workflow quietly becomes operational.

You cannot govern an agent you cannot identify. Microsoft's current agent-security guidance identifies agent sprawl, excessive privileges, tool misuse, misconfiguration, prompt injection and data leakage as operational concerns. Its recommended operating model emphasises visibility, sponsorship, distinct identities, least privilege, auditing and threat detection.

An inventory should answer six questions:

1. Who is the accountable business sponsor?
2. What decision or outcome is the agent meant to support?
3. Which identity does it use?
4. Which data, memory and tools can it access?
5. Which actions can it take without approval?
6. How can the organisation pause it and review what happened?

Discovery is only the first step. Every discovered agent needs an owner, a risk classification and a decision: approve, narrow, isolate, replace or retire.

Choose authority before choosing controls

Not every valuable agent needs the right to execute. Use the lowest level of authority that still delivers the business outcome.

The four levels below are an operating model for this article, not an external standard:

Authority should increase only as controls and evidence become stronger.

Before moving up a level, retain progressively stronger evidence. For read, verify source scope and data access. For recommend, evaluate decision quality and failure cases. For prepare, test the exact approval preview and parameters. For execute, prove that external policy enforcement, monitoring, stop and rollback procedures work.

AWS recommends deterministic controls outside the model and says autonomy should be earned through workflow-level evidence. It also warns against approval fatigue. The implication is practical: do not ask a person to click “approve” on every harmless step, but never hide a consequential action inside a generic approval queue.

The progression should be deliberate. Start with read or recommend, measure failure modes, then graduate only the specific action that has adequate controls. The same principle sits behind a bounded agentic AI pilot.

Use an Agent Security Control Card

Before launch, create one short control card for each agent workflow. It should fit on a page and name five things:

1. Owner: the sponsor, system owner and security contact.
2. Data and context: approved sources, sensitivity, retention and prohibited inputs.
3. Identity and tools: the agent identity, credentials, tool allowlist and permissions.
4. Action boundary: allowed actions, transaction or rate limits, and approval triggers.
5. Monitoring and recovery: logs, alerts, evaluation results, kill switch, rollback and review date.

The card turns “we have guardrails” into evidence that another person can inspect. The control matrix below shows the level of specificity to aim for.

These decisions should be part of the organisation's wider AI, automation and digital strategy, not left inside a model configuration screen.

A practical AI agent security checklist

Use this AI agent security checklist as an operating baseline. A “yes” should mean the evidence exists—not that the team expects to add it later.

Inventory and ownership

☐ The agent has a named business sponsor, system owner and security contact.
☐ Its purpose, users, environment and lifecycle state appear in a current inventory.
☐ The team has identified shadow AI touching the same data, tools or process.

Identity and access

☐ The agent uses an attributable identity rather than a shared human account.
☐ Permissions are limited by data, tool, operation and environment.
☐ Credentials are short-lived where practical, stored securely and revocable without redesigning the workflow.

Data, context and memory

☐ Approved and prohibited data sources are documented by sensitivity.
☐ Untrusted content is separated from system instructions and tested for indirect prompt injection.
☐ Memory has defined write rules, retention, review and deletion controls.

Tools and actions

☐ Tools and operations are allowlisted; parameters and destinations are validated.
☐ Consequential actions have explicit approval rules, rate or value limits and segregation where needed.
☐ External policy checks—not the model alone—enforce hard boundaries.

Monitoring and recovery

☐ Logs connect the request, identity, context, tool call, approval and result.
☐ Alerts cover denied actions, unusual access, repeated failures and material configuration changes.
☐ Stop, revoke, rollback and incident-review procedures have been exercised.

This is not a compliance certificate. It is a way to expose missing decisions before an agent receives production authority.

Put the checklist inside an AI governance framework

An AI governance framework defines how an organisation makes and reviews decisions; the checklist supplies evidence for one agent workflow. Keep those levels connected.

The NIST Generative AI Profile is a voluntary, cross-sector companion to the AI Risk Management Framework. It can help structure governance, but it is not an agent-security certification. Meanwhile, the NIST AI Agent Standards Initiative is producing voluntary guidance and researching agent identity, authentication and security evaluation.

That evolving landscape is a reason to maintain a clear control record, not a reason to wait for one universal checklist. Sector rules, privacy obligations, contractual commitments and the consequences of the agent's actions may require additional controls and qualified legal or compliance review.

A 30-day implementation plan

Days 1–7: inventory and classify

Choose one real workflow. Record its owner, users, data, memory, identity, tools and current action rights. Place it on the read–recommend–prepare–execute ladder. If the team cannot explain the workflow on one page, it is not ready for more autonomy.

Days 8–14: reduce and bind authority

Remove unnecessary data sources, tools and permissions. Give the workflow an attributable identity. Convert broad tool access into allowed operations and define the events that require human approval. Add transaction, rate and destination limits where relevant.

Days 15–21: test failure paths and recovery

Test hostile instructions in retrieved content, requests outside the agent's purpose, denied tool calls, malformed parameters, sensitive-data handling, memory writes and loss of a dependency. Confirm that monitoring explains what happened.

A MITRE investigation of OpenClaw documented a path in which web search results, messages and third-party skills injected instructions that the agent executed. The report concerns that specific system and is not evidence of prevalence across all agents, but it is a useful reminder to test the whole chain rather than the model alone.

Days 22–30: make an evidence-based decision

Review the control card, failed tests, approvals, logs and recovery exercise. Then choose one outcome: approve the current authority, narrow it, keep the workflow in a supervised pilot, or stop it. Record the decision and the next review trigger.

Frequently asked questions

What is AI agent security?

AI agent security is the protection of an agent's identity, data, context, memory, tools and actions across the complete workflow. It combines established cybersecurity practices with controls for systems that can plan and act with some autonomy; OWASP's agent guidance provides a current technical starting point.

How is agentic AI security different from ordinary AI security?

This guide puts additional emphasis on action authority and connected tools when assessing agentic AI security. A model that only drafts text still needs data and output controls, but an agent that can update a system also needs a scoped identity, tool restrictions, approval rules, action logs and recovery procedures.

How can a business detect and reduce shadow AI?

A practical detection process combines discovery with a simple registration and approval path. Review identity-provider activity, connected applications, API credentials, procurement records and major data flows; then give each discovered workflow an owner and an approve, narrow, isolate, replace or retire decision. Discovery methods vary by technology stack, so treat this as an operating recommendation that complements security monitoring and staff reporting.

What regulations apply to AI agents?

This article does not determine which laws apply to a particular AI agent. That requires a jurisdiction-, sector- and use-case-specific assessment by qualified legal, privacy and compliance advisers. A practical scoping exercise is to list the relevant jurisdictions, sector, data categories and whether the agent recommends or executes decisions affecting people, money or access; then map those facts to AI-specific, privacy, cybersecurity, consumer and sector obligations with those advisers. The NIST initiative is a US standards effort producing voluntary guidance and researching agent identity and security evaluation; it is not a universal compliance rule.

Make authority visible before you automate it

The most useful security question is not, “Is this model safe?” It is, “What can this workflow see, decide and do—and how will we know when those boundaries fail?”

Start with one agent, one control card and the lowest useful authority. If you want to map the decision rights and controls for a live workflow, get in touch.