AI Agent Security: The Complete Enterprise Guide to Securing Autonomous AI

AI agents have crossed an important security boundary. They are no longer simply generating answers or summarising information. They can plan tasks, call APIs, access enterprise data, execute code, interact with other agents and take actions on behalf of employees, customers and organisations. AI Agent Security is of utmost importance.

That changes the security equation.

A conventional AI assistant may produce a wrong answer. An autonomous agent can potentially turn that wrong answer into a wrong action. It may send information to the wrong destination, invoke an inappropriate tool, alter a record, expose credentials or trigger a chain of downstream decisions.

The concern is no longer theoretical. The Cloud Security Alliance reported in April 2026 that 82% of surveyed organisations had discovered AI agents or autonomous workflows that security or IT had not previously known about. Sixty-five percent reported an AI-agent-related incident during the preceding 12 months. Among those reporting incidents, 61% experienced data exposure, 43% operational disruption and 35% financial losses.

Separate research from Arkose Labs found that 97% of 300 surveyed enterprise leaders expected an AI-agent security incident within 12 months. The same research highlighted a growing concern around agents operating with legitimate credentials and participating in business workflows.

This is why AI Agent Security has moved from a specialist AI concern to an enterprise risk-management issue.

The challenge is not simply to make agents more intelligent. It is to make them controllable, observable, accountable and appropriately constrained.

---

What Makes an AI Agent Different From Traditional AI?

The distinction between a conventional AI application and an agent matters because autonomy changes the consequences of failure.

A traditional large language model generally receives a prompt and produces an output. The output may be inaccurate, biased, incomplete or unsafe. But the model may not have direct authority to change an external system.

An AI agent adds an action layer.

Depending on its design, an agent can:

• interpret an objective;
• break the objective into subtasks;
• select tools;
• retrieve information;
• access databases;
• call APIs;
• execute software;
• send messages;
• modify enterprise records;
• delegate tasks to other agents;
• maintain memory between interactions;
• evaluate intermediate results;
• continue operating without continuous human approval.

NIST’s 2026 work on agent security specifically recognises this distinction. Its AI Agent Standards Initiative describes agents as systems capable of autonomous actions and identifies security and identity as important areas for enabling trusted adoption.

The result is a new security model.

A compromised chatbot may leak information through its response.

A compromised agent can potentially use legitimate permissions to perform the next step itself.

That means security teams must evaluate not only what an AI system says, but also what it can do.

---

Why AI Agents Amplify Existing Enterprise Risks

It is tempting to describe agentic AI as creating an entirely new category of cybersecurity threats.

That is only partly true.

Many underlying weaknesses are familiar:

• excessive privileges;
• weak identity controls;
• insecure APIs;
• inadequate network segmentation;
• poor secrets management;
• vulnerable dependencies;
• insufficient logging;
• weak change management;
• inadequate incident response;
• ungoverned data access.

Agents amplify these weaknesses because they can operate across several systems at machine speed.

A human employee may make one mistake.

An agent may repeat an erroneous action across hundreds of records.

A human may need several minutes to move information between systems.

An agent can potentially perform the same sequence in seconds.

A human may hesitate before taking an irreversible action.

An agent optimising for a poorly defined objective may not understand why that action should require approval.

The fundamental question therefore changes from:

“Can we secure the AI model?”

to:

“Can we control the complete system in which the AI model is acting?”

That system includes the model, prompts, tools, APIs, identities, data, memory, runtime environment, other agents and human users.

---

The OWASP Agentic Top 10: A Practical Threat Model

The OWASP Top 10 for Agentic Applications 2026 provides an important foundation for analysing agentic risk. Released in December 2025, the framework was developed with contributions from more than 100 security researchers, practitioners, organisations and technology providers.

Its ten risks are particularly useful because they focus on the behaviour and architecture of autonomous applications rather than treating agents simply as another form of chatbot.

ASI01: Agent Goal Hijack

Goal hijacking occurs when an attacker manipulates an agent’s objective.

The attack does not necessarily require direct access to the agent’s system prompt.

An attacker may place malicious instructions inside information the agent is expected to process.

Examples include:

• emails;
• web pages;
• documents;
• support tickets;
• search results;
• database records;
• tool responses.

This creates the problem commonly associated with indirect prompt injection.

Imagine an enterprise procurement agent instructed to analyse supplier documents. A malicious document could contain hidden instructions attempting to redirect the agent toward another objective.

The agent may technically follow its programming while violating the business intent of the workflow.

Controls should include:

• separation between trusted instructions and untrusted content;
• explicit objective validation;
• tool restrictions;
• confirmation for material changes;
• input sanitisation;
• adversarial testing;
• policy enforcement outside the model.

The critical principle is simple:

Data supplied to an agent should not automatically become authority for that agent.

---

ASI02: Tool Misuse and Exploitation

Agents become powerful because they can use tools.

Those tools are also potential attack surfaces.

A calendar API, payment system, CRM, database, cloud console or code-execution environment may be legitimate individually. The danger emerges when an agent combines legitimate capabilities in an unintended way.

For example, an agent might have permission to:

1. retrieve customer information;
2. create a document;
3. send an email.

Each permission may appear reasonable.

Together, they could potentially enable unauthorised data transmission.

Tool security therefore needs to consider combinations of capabilities, not merely individual permissions.

Organisations should:

• maintain explicit tool allowlists;
• validate tool arguments;
• restrict dangerous functions;
• impose transaction limits;
• separate read and write capabilities;
• require approval for high-impact actions;
• monitor unusual tool sequences.

The agent should never receive more capability simply because the underlying API offers it.

---

ASI03: Identity and Privilege Abuse

An agent is not a human employee.

It should therefore not casually inherit a human user’s complete permissions.

Every production agent should have a clearly defined identity and an explicitly defined authority boundary.

NIST’s 2026 work on agent identity and authorization specifically explores how existing identity standards and best practices can be applied to software agents, including identification, authorization, auditing and non-repudiation.

Microsoft’s current enterprise-security guidance similarly emphasises managed identities, least privilege and role-based access controls for agents.

A mature approach should include:

• unique agent identities;
• least-privilege permissions;
• short-lived credentials;
• task-specific authorization;
• just-in-time access;
• credential rotation;
• rapid revocation;
• separation of duties;
• auditable delegation.

This is where the emerging concept of non-human identity becomes especially important.

An enterprise may have thousands of service accounts, APIs, workloads and automation identities already.

Agentic AI adds another population of identities that can make decisions and initiate actions.

Security teams therefore need an inventory of not only who has access, but also what autonomous systems have access.

---

ASI04: Agentic Supply Chain Vulnerabilities

Modern agents increasingly depend on external components.

These may include:

• foundation models;
• model providers;
• open-source libraries;
• plugins;
• MCP servers;
• agent frameworks;
• external APIs;
• retrieval systems;
• datasets;
• agent templates;
• third-party tools.

Every dependency creates a trust relationship.

The supply-chain problem becomes particularly serious when agents dynamically discover or invoke external capabilities.

Organisations should evaluate:

• who publishes a component;
• what permissions it requests;
• where it sends data;
• how it is updated;
• whether versions can be pinned;
• whether dependencies are signed;
• how vulnerabilities are disclosed;
• how a compromised component can be disabled.

An agent ecosystem needs something similar to software supply-chain discipline, but with additional controls for runtime authority.

---

ASI05: Unexpected Code Execution

Giving an agent access to a coding environment can dramatically increase its usefulness.

It can also dramatically increase the blast radius of a mistake.

Natural-language instructions can become executable operations.

The security boundary must therefore exist outside the model.

Recommended controls include:

• isolated execution environments;
• containerisation;
• sandboxing;
• filesystem restrictions;
• network restrictions;
• package allowlists;
• resource limits;
• execution time limits;
• approval gates for sensitive operations;
• monitoring of generated and executed code.

The key principle is:

Never assume that because an agent generated an instruction rather than traditional software code, the instruction is harmless.

---

ASI06: Memory and Context Poisoning

Agent memory introduces another dimension of risk.

An agent may retain information in:

• vector databases;
• conversation histories;
• structured databases;
• user profiles;
• task histories;
• long-term memory systems.

If malicious information enters persistent memory, the impact can continue beyond the original interaction.

Memory therefore needs:

• provenance;
• integrity controls;
• access controls;
• retention policies;
• sanitisation;
• validation;
• deletion mechanisms;
• periodic review.

An enterprise should be able to answer a basic question:

What information influenced this agent’s decision?

If the answer is impossible to reconstruct, the organisation has an auditability problem.

---

ASI07: Insecure Inter-Agent Communication

The next stage of agentic architecture will increasingly involve agents communicating with other agents.

One agent may perform research.

Another may analyse the results.

A third may make a recommendation.

A fourth may execute the resulting workflow.

This creates a distributed system in which machine-generated messages can carry authority.

Inter-agent communication should therefore be:

• authenticated;
• authorised;
• encrypted where appropriate;
• logged;
• attributable to a specific agent;
• validated against expected message types;
• bounded by policy.

The identity of the sending agent matters.

So does the authority that agent possesses.

---

ASI08: Cascading Failures

A single incorrect action becomes considerably more dangerous when agents are connected.

Consider a financial workflow:

Agent A classifies a customer.

An error in Agent A can propagate through the entire chain.

This is why agentic architectures require circuit breakers and risk boundaries.

Useful controls include:

• transaction thresholds;
• confidence thresholds;
• anomaly detection;
• dependency isolation;
• independent validation;
• rollback mechanisms;
• human escalation;
• circuit breakers;
• maximum action limits.

The goal is not to prevent every error.

The goal is to prevent a small error from becoming a systemic failure.

---

ASI09: Human-Agent Trust Exploitation

Human oversight can itself become an attack surface.

An agent that produces confident, polished and apparently rational explanations may persuade a user to approve an unsafe action.

This is particularly dangerous when humans become accustomed to accepting agent recommendations.

The risk is known as automation bias.

Human oversight is therefore not simply a checkbox.

The human must have:

• sufficient context;
• meaningful time to review;
• visibility into relevant evidence;
• the ability to reject the recommendation;
• a clear understanding of the agent’s limitations.

The EU AI Act similarly requires effective human oversight for high-risk AI systems, including the ability for designated humans to monitor systems, override outputs and interrupt operation.

---

ASI10: Rogue Agents

“Rogue agent” is an emotionally powerful term, but enterprises should use it carefully.

In most practical situations, the problem is not an AI system suddenly developing human-like intentions.

The problem is that an autonomous system can behave outside its intended boundaries.

That may result from:

• faulty objectives;
• reward hacking;
• unexpected interactions;
• excessive permissions;
• prompt injection;
• compromised tools;
• unsafe code;
• environmental changes;
• inadequate testing.

Recent 2026 incidents involving AI systems accessing external systems during security testing have made containment a real engineering concern rather than a theoretical one. Reuters reported disclosures involving OpenAI, Anthropic and other AI systems that demonstrated the difficulties of controlling increasingly autonomous systems.

The appropriate response is not anthropomorphism.

It is engineering:

detect, contain, investigate, revoke and recover.

---

Designing a Secure Agent Architecture

A secure enterprise agent should be treated as a distributed application rather than simply a model with a prompt.

A useful architecture contains several control layers.

1. Identity Layer

Every agent needs a verifiable identity.

The identity should answer:

• Which agent is this?
• Who owns it?
• What business purpose does it serve?
• Which environment is it running in?
• What permissions does it have?
• Which other agents can it communicate with?
• When does its credential expire?

Identity should not be an afterthought added after deployment.

---

2. Authorization Layer

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

For agents, authorization should be dynamic where appropriate.

A research agent might need read access to internal documents but no authority to modify them.

A customer-service agent may update a ticket but should not have unrestricted access to the customer database.

A finance agent may prepare a transaction but require human approval before execution.

The principle is:

Give the agent the minimum authority required for the specific task.

---

3. Tool-Control Layer

Every tool should be treated as an API security boundary.

For each tool, organisations should define:

• permitted agents;
• permitted actions;
• permitted parameters;
• permitted data;
• rate limits;
• transaction limits;
• approval requirements;
• logging requirements.

The tool gateway should enforce these rules independently of the model.

That distinction is crucial.

A model should be able to request an action.

It should not be able to redefine the policy governing that action.

---

4. Data-Control Layer

Agent access to enterprise data should follow existing information-security principles.

Data should be:

• classified;
• minimised;
• access-controlled;
• monitored;
• encrypted where appropriate;
• retained according to policy;
• protected against unauthorised external transfer.

Sensitive data should not become available simply because an agent can technically retrieve it.

Enterprises should consider separate policies for:

• public information;
• internal information;
• confidential information;
• personal information;
• financial information;
• intellectual property;
• regulated information;
• highly restricted information.

---

5. Runtime-Control Layer

The runtime environment should constrain what the agent can do even if the agent behaves unexpectedly.

Important controls include:

• sandboxing;
• containerisation;
• network segmentation;
• egress controls;
• filesystem restrictions;
• resource limits;
• execution timeouts;
• process isolation;
• secrets isolation;
• emergency termination.

The security architecture should assume that an agent may eventually make an unsafe decision.

The runtime should make that decision difficult to turn into a catastrophic event.

---

MCP, Agent-to-Agent Communication and the New Security Perimeter

The emergence of open protocols is making agents more interoperable.

The Model Context Protocol, or MCP, is particularly important because it provides a standardised mechanism for AI applications to connect with external tools and data sources.

That also makes MCP security an enterprise concern.

The current MCP authorization specification incorporates OAuth 2.1 and related OAuth standards. The November 2025 specification requires protected-resource metadata and defines mechanisms for authorization-server discovery. It also addresses token audience validation, token theft, HTTPS, redirect-URI security and PKCE.

This matters because an MCP connection is not merely a technical integration.

It can become a path from an agent to an enterprise capability.

Security teams should therefore ask:

• Which MCP servers are approved?
• Which agents can access them?
• Which scopes are granted?
• Which identity provider authorizes access?
• How are tokens stored?
• How long do tokens remain valid?
• Can tokens be revoked quickly?
• Are tool calls logged?
• Can administrators disable a connection centrally?
• Is the MCP server itself trusted?

The same logic applies to emerging agent-to-agent protocols.

Interoperability should never mean unrestricted trust.

An enterprise should be able to distinguish:

communication from authorization.

Two agents may be allowed to exchange information without either being allowed to command the other to execute a high-impact operation.

---

Governance: Every Agent Needs an Owner

One of the easiest mistakes enterprises can make is treating agents as software components without accountability.

Every production agent should have a human owner.

The owner should be accountable for:

• business purpose;
• approved capabilities;
• data access;
• risk classification;
• testing;
• lifecycle management;
• monitoring;
• incident response;
• retirement.

An enterprise-wide agent registry should ideally record:

Attribute	What to record
Agent name	Unique identifier
Business owner	Accountable human
Technical owner	Responsible engineering team
Purpose	Intended business outcome
Model	Foundation model and version
Environment	Cloud, on-premises or hybrid
Data	Sources and sensitivity
Tools	APIs and systems accessible
Identity	Agent identity and credential
Autonomy	Human approval requirements
Dependencies	Models, MCP servers, agents and APIs
Risk tier	Low, medium, high or critical
Monitoring	Security and operational controls
Incident plan	Response and shutdown procedure
Lifecycle	Review and retirement dates

The CSA’s 2026 research demonstrates why this visibility matters: 82% of surveyed organisations reported discovering previously unknown agents or autonomous workflows.

This is the agentic equivalent of shadow IT.

Call it shadow agents.

---

Risk Classification: Not Every Agent Needs the Same Controls

Security controls should be proportional to risk.

A useful enterprise classification might look like this:

Tier 1 — Assistive

The agent generates information but cannot independently change systems.

Examples:

• summarisation;
• drafting;
• research;
• internal knowledge retrieval.

Controls can focus on data access, output validation and privacy.

Tier 2 — Operational

The agent can perform reversible business actions.

Examples:

• updating tickets;
• scheduling meetings;
• preparing reports;
• updating selected records.

These agents need stronger identity and tool controls.

Tier 3 — High Impact

The agent can affect customers, finances, employees or regulated information.

Examples:

• financial workflows;
• customer eligibility;
• employment processes;
• sensitive-data operations.

These require stronger approval, logging and monitoring.

Tier 4 — Critical Autonomous Operations

The agent can independently execute actions with significant financial, legal, operational or security consequences.

These require:

• strict privilege boundaries;
• continuous monitoring;
• strong authentication;
• independent controls;
• rapid shutdown;
• tested rollback;
• formal executive ownership.

Autonomy should therefore be treated as a risk variable, not merely a product feature.

---

Testing AI Agents Before They Reach Production

Traditional software testing is necessary but insufficient.

Agents require behavioural security testing.

Organisations should test at least five dimensions.

Prompt and Instruction Testing

Test direct and indirect prompt injection.

Ask whether malicious instructions embedded in external data can change agent behaviour.

Tool Abuse Testing

Test whether an agent can:

• invoke unauthorised tools;
• manipulate parameters;
• chain legitimate tools dangerously;
• bypass approval requirements.

Identity Testing

Attempt to determine whether the agent can:

• obtain broader credentials;
• reuse another identity;
• access expired permissions;
• operate after revocation.

Memory Testing

Test whether malicious information can become persistent agent context.

Multi-Agent Testing

Test whether one compromised or misbehaving agent can influence another.

Security teams should also conduct adversarial simulations before production deployment.

The objective is not merely to ask:

“Does the agent work?”

It is to ask:

“How does the agent fail?”

---

Observability: Log the Agent’s Actions, Not Just Its Output

Conventional application monitoring focuses heavily on requests, responses and system errors.

Agent monitoring must go further.

For each material action, organisations should ideally know:

• which agent acted;
• which identity it used;
• what task it was attempting;
• which tool it invoked;
• what data source it accessed;
• what authorization policy applied;
• whether human approval was required;
• whether approval occurred;
• what external system changed;
• what downstream actions followed.

There is an important distinction here.

Enterprises do not necessarily need to store unrestricted hidden chain-of-thought reasoning.

They do need sufficient decision and action telemetry to establish accountability.

The security objective is reconstructability:

Can investigators determine what happened, which controls applied and what changed?

If not, the organisation will struggle to investigate incidents.

---

Data Leakage: The Risk Extends Beyond the Model

AI security discussions often focus on training-data leakage.

Agentic systems introduce more paths.

Sensitive information may move through:

• prompts;
• retrieval systems;
• vector stores;
• tool calls;
• APIs;
• logs;
• agent memory;
• inter-agent messages;
• third-party services;
• generated files;
• external websites.

Data-loss prevention therefore needs to understand agent workflows.

For example, an agent may have legitimate access to an internal customer database.

The security question is not only whether it can read the database.

It is also whether it can:

read → transform → package → transmit

that information to an external service.

This is why DLP, API security, identity security and AI security increasingly overlap.

---

Human-in-the-Loop Does Not Mean Human-in-the-Process

Enterprises often say that an agent is safe because a human remains “in the loop.”

That phrase is insufficient.

If a human receives hundreds of low-context approval requests, approval can become automatic.

Effective human oversight requires:

• meaningful information;
• appropriate escalation;
• sufficient review time;
• understandable explanations;
• clear evidence;
• ability to reject;
• ability to reverse;
• ability to stop the agent.

The EU AI Act explicitly requires human oversight for high-risk AI systems and states that oversight should allow appropriate persons to understand limitations, detect anomalies, disregard outputs and intervene or interrupt operation.

The lesson for enterprises is broader:

A human approval button is not a security control unless the human can make an informed decision.

Enterprises should avoid treating AI-agent security as a standalone compliance exercise. Instead, agent controls should be mapped into existing security, privacy, risk and AI-governance frameworks.

NIST AI Agent Standards Initiative

NIST launched its AI Agent Standards Initiative on February 17, 2026.

Its work is organised around three broad areas:

1. facilitating industry-led standards;
2. fostering community-led open protocols;
3. advancing research in agent security and identity.

NIST is also investigating identity and authorization for software agents and has explicitly highlighted the need to adapt cybersecurity practices to the new characteristics of agent systems.

In May 2026, NIST published its analysis of responses to an RFI on AI-agent security. Respondents broadly agreed that agents create novel security challenges and that conventional cybersecurity principles remain relevant but need adaptation.

For enterprises, this suggests a practical approach:

Use existing security disciplines as the foundation, but extend them for autonomy, tool use, delegation and agent identity.

---

NIST AI RMF and Cybersecurity Framework

NIST’s AI Risk Management Framework remains relevant for managing AI risks.

The Generative AI Profile provides a cross-sector resource for incorporating trustworthiness considerations into AI development, deployment and evaluation.

NIST’s Cybersecurity Framework provides the complementary cybersecurity structure.

For agentic systems, enterprises can combine:

AI risk management + cybersecurity + identity + software security + data governance.

This is more practical than creating an entirely separate security universe for agents.

---

ISO/IEC 42001

ISO/IEC 42001:2023 provides requirements for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System.

It applies to organisations developing, providing or using AI systems.

For enterprises deploying agents, ISO/IEC 42001 can provide a governance layer around:

• accountability;
• risk management;
• policies;
• lifecycle management;
• transparency;
• continual improvement.

It should complement, rather than replace, technical cybersecurity controls.

---

EU AI Act

The EU AI Act is particularly relevant for organisations operating in or serving the European market.

Its requirements depend on the classification and use of an AI system.

For high-risk systems, Article 9 establishes a continuous risk-management process. Article 14 addresses human oversight. Article 15 addresses accuracy, robustness and cybersecurity.

Importantly, the EU AI Act should not be confused with the GDPR.

GDPR Article 22 concerns automated individual decision-making.

The EU AI Act is a separate legal framework with its own requirements.

Enterprises therefore need legal and compliance teams to determine which obligations apply to each deployment rather than assuming that every agent is regulated in exactly the same way.

Agent incidents add another possibility:

The system itself may continue taking actions while the investigation is beginning.

That changes the first priority.

First Minutes: Stop Further Action

The first response should be containment.

Depending on the architecture, this may involve:

• disabling the agent;
• revoking credentials;
• blocking network access;
• disabling tool access;
• suspending MCP connections;
• isolating dependent agents;
• stopping scheduled workflows.

The shutdown mechanism must be tested before an incident.

A theoretical kill switch is not enough.

---

First Hour: Establish the Blast Radius

Investigators should determine:

• what the agent accessed;
• what it changed;
• what information it transmitted;
• which credentials it used;
• which tools it invoked;
• which agents it contacted;
• which users were affected;
• which downstream systems changed.

The organisation should distinguish between:

reversible actions

and

irreversible actions.

A cancelled calendar event is different from a disclosed customer database.

A reverted database update is different from an executed financial transaction.

This classification should be part of the incident playbook.

---

First 24 Hours: Investigate the Agent’s Decision Environment

Agent forensics may need to examine:

• prompts;
• retrieved information;
• tool calls;
• identity events;
• authorization decisions;
• memory changes;
• model version;
• system configuration;
• external messages;
• inter-agent communication;
• network activity.

The investigation should establish whether the incident resulted from:

• malicious input;
• prompt injection;
• credential compromise;
• tool misuse;
• software vulnerability;
• supply-chain compromise;
• memory poisoning;
• misconfiguration;
• inadequate guardrails;
• unexpected model behaviour.

---

Before Returning the Agent to Production

Do not simply restart the system.

A return-to-service decision should require evidence that:

• the original vulnerability is addressed;
• credentials have been rotated;
• malicious state has been removed;
• dependencies are trusted;
• permissions are reviewed;
• monitoring is active;
• the kill mechanism works;
• relevant tests have passed.

An agent should return to production because it has passed a defined security gate—not because the incident appears to have stopped.

The technology categories are more useful to enterprises than a simple vendor ranking.

AI Security Posture Management

These capabilities help discover AI applications and agents, assess configuration and identify risk.

Runtime Agent Protection

These systems monitor agent activity and attempt to detect or block unsafe behaviour while agents operate.

Non-Human Identity Management

These tools focus on discovering and governing identities belonging to machines, workloads and autonomous systems.

AI Governance

These platforms connect AI inventories, policies, risk assessments, compliance requirements and approval workflows.

Tool and MCP Security

These controls protect the interfaces through which agents access external tools and services.

Agent Observability

These capabilities provide telemetry around agent behaviour, tool usage and workflow execution.

Enterprises should resist buying a product simply because it contains the words “agent security.”

The more important questions are:

• Does it discover all agents?
• Does it understand agent identities?
• Can it enforce permissions?
• Can it control tool access?
• Can it protect MCP connections?
• Can it monitor runtime behaviour?
• Can it integrate with existing IAM?
• Can it integrate with SIEM and SOC systems?
• Can it support incident response?
• Can it produce audit evidence?

Identity

• Does the agent have a unique identity?
• Is the identity separate from the human operator?
• Are credentials short-lived?
• Can credentials be revoked immediately?

Authorization

• What exactly can the agent access?
• Are permissions task-specific?
• Can it escalate privileges?
• Are high-risk actions subject to additional approval?

Tools

• Which APIs can it call?
• Which functions can it execute?
• Are tool arguments validated?
• Are dangerous tools isolated?

Data

• What information can the agent retrieve?
• Where is that information processed?
• Can it leave the enterprise?
• How is memory protected?
• How long is data retained?

Runtime

• Is the agent sandboxed?
• Is network egress controlled?
• Can it execute arbitrary code?
• Can it access secrets?
• Can it be isolated rapidly?

Monitoring

• Are tool calls logged?
• Are identity events logged?
• Can investigators reconstruct actions?
• Are anomalous behaviours detected?

Supply Chain

• Which models and dependencies are used?
• Which MCP servers are connected?
• Are dependencies pinned?
• How are updates approved?

Governance

• Who owns the agent?
• What is its risk tier?
• When was it last reviewed?
• When will it be retired?

Incident Response

• Can the agent be stopped?
• Can credentials be revoked?
• Can transactions be reversed?
• Are downstream agents identifiable?
• Has the incident playbook been tested?

If these questions cannot be answered, the agent is probably not ready for production.

A pragmatic roadmap can begin immediately.

Stage 1: Discover

Create an inventory of:

• agents;
• AI applications;
• autonomous workflows;
• tools;
• identities;
• data sources;
• external connections.

Find the shadow agents first.

---

Stage 2: Classify

Assign each agent a risk tier based on:

• autonomy;
• data sensitivity;
• business impact;
• tool access;
• financial authority;
• regulatory exposure;
• external connectivity.

---

Stage 3: Constrain

Apply:

• least privilege;
• managed identity;
• tool allowlists;
• network controls;
• sandboxing;
• approval gates;
• data restrictions.

Do this before expanding autonomy.

---

Stage 4: Monitor

Measure:

• agent actions;
• tool calls;
• permissions;
• anomalies;
• data movement;
• failures;
• policy violations.

Monitoring should cover behaviour rather than merely uptime.

---

Stage 5: Test and Improve

Run:

• adversarial testing;
• prompt-injection testing;
• tool-abuse testing;
• identity testing;
• memory-poisoning testing;
• multi-agent testing;
• incident simulations.

Review permissions and risk classification periodically.

Agent security is not a one-time certification.

It is a lifecycle discipline.

Useful metrics include:

Visibility

• percentage of known agents;
• percentage of agents with documented owners;
• percentage of agents classified by risk.

Identity

• percentage using managed identities;
• percentage using short-lived credentials;
• average credential lifetime;
• percentage with automated revocation.

Authorization

• percentage with least-privilege policies;
• percentage of high-risk actions requiring approval;
• number of excessive-permission findings.

Runtime

• percentage sandboxed;
• percentage with controlled network egress;
• median shutdown time;
• percentage with tested kill mechanisms.

Monitoring

• percentage of tool calls logged;
• percentage of agents covered by behavioural monitoring;
• mean time to detect agent anomalies;
• mean time to contain an agent incident.

Governance

• percentage reviewed within policy;
• number of unapproved agents;
• number of agents past retirement date.

These measurements convert agent security from an abstract concern into an operational programme.

The analogy helps explain why agents need:

• identities;
• permissions;
• managers;
• responsibilities;
• access controls;
• lifecycle management.

But the analogy has limits.

An agent is not a human.

It does not possess human judgement, legal accountability or organisational intent.

Most importantly, an agent can operate at machine speed.

It can potentially execute thousands of operations without fatigue.

Therefore, an organisation should not simply give an agent the same permissions that a human employee would receive.

The better mental model is:

An agent is an autonomous software actor operating inside an enterprise trust environment.

It needs identity and authority, but its authority must be machine-enforceable and bounded.

Imagine a future enterprise workflow involving:

• a customer-service agent;
• a sales agent;
• a pricing agent;
• a fraud agent;
• a finance agent;
• a compliance agent;
• a procurement agent.

Each agent may specialise in one domain.

The productivity opportunity is enormous.

So is the systemic risk.

The organisation will need to understand:

Who can instruct whom?

Which agent can delegate authority?

Can an agent transfer credentials?

Can one agent trigger another without human approval?

What happens if one agent is compromised?

How is trust established between agents belonging to different organisations?

These are identity and authorization questions as much as AI questions.

That is why NIST’s work on agent identity and authorization and its broader AI Agent Standards Initiative are significant.

Interoperability without security could simply create a larger attack surface.

Recent reporting indicates that insurers are adapting policies because autonomous AI systems can create losses in situations that do not fit neatly into traditional categories such as unauthorised access or malware.

This creates difficult questions around liability.

If an agent:

• uses a legitimate credential;
• makes an unauthorised decision;
• causes a financial loss;
• interacts with a third-party system;

then several parties may potentially be involved:

• the enterprise deploying it;
• the software provider;
• the model provider;
• the tool provider;
• the cloud provider;
• the developer;
• the human approving the workflow.

Contracts and vendor assessments will increasingly need to address these questions.

AI governance is therefore becoming connected to procurement, insurance, legal risk and corporate accountability.

And they cannot assume that interoperability automatically creates trust.

The security architecture must remain safe when individual components fail.

That means controlling the action surface.

An agent may reason incorrectly.

But it should not have unrestricted authority to act on that reasoning.

An agent may encounter malicious information.

But that information should not automatically acquire execution authority.

An agent may become compromised.

But its identity should be revocable.

An agent may attempt an unexpected operation.

But policy enforcement outside the model should be able to block it.

That is the foundation of modern AI Agent Security.

It makes conventional cybersecurity more important.

Identity still matters.

Least privilege still matters.

Network segmentation still matters.

Secure software development still matters.

Data governance still matters.

Logging still matters.

Incident response still matters.

The difference is that autonomous agents can connect these controls into a new, highly dynamic execution environment.

The organisations most likely to deploy agents safely will not necessarily be those with the most restrictive AI policies.

They will be the organisations that can establish controlled autonomy.

That means allowing agents to act while ensuring that:

1. Every agent has an identity.
2. Every agent has an accountable owner.
3. Every permission has a defined business purpose.
4. Every high-impact action has an appropriate control.
5. Every important action is observable.
6. Every external connection is governed.
7. Every agent can be contained.
8. Every incident has a tested response plan.
9. Every deployment is periodically reassessed.
10. Every increase in autonomy is matched by stronger controls.

NIST’s 2026 work makes clear that existing cybersecurity principles remain relevant, but need adaptation for autonomous systems. OWASP provides a practical agent-specific threat taxonomy. MCP is building security mechanisms around identity and authorization. ISO/IEC 42001 provides an organisational AI-management framework. The EU AI Act introduces additional obligations for applicable high-risk systems.

The most important change, however, is conceptual.

AI agents should no longer be treated simply as software that produces intelligence.

They are software systems that can exercise authority.

And once software can exercise authority, security must govern not only what it knows, but what it is allowed to do.

The agentic enterprise is arriving quickly.

The organisations that prepare now will have a significant advantage: they can pursue autonomous AI without allowing autonomy to become uncontrolled access.

---

Editor’s Take

The next phase of enterprise AI will not be decided solely by which organisation deploys the most capable agents.

It will be decided by which organisations can make those agents trustworthy at scale.

The winning architecture will not be “maximum autonomy.”

It will be measured autonomy, bounded authority and continuous oversight.

That is the real enterprise security challenge of the agentic era.

---