Agentic AI security is the practice of governing AI systems that take actions, not just produce text. It covers the identities an agent uses, the tools and systems it can reach, the approvals around consequential steps, and the evidence needed to reconstruct, contain and reverse what it did. It is an operational security problem, not a model problem.
What is agentic AI security?
That last sentence is the one most pages get wrong, so it is worth separating three things that sound alike.
- LLM security and AI application security ask whether a model or the app around it can be tricked, leaked from, or abused. Important, but it stops at the model boundary.
- AI for security is the opposite direction: using AI to do security work, such as triage and investigation. That is a different job, covered on /ai-for-security.
- Agentic AI security starts where the agent acts. A prompt injection that produces rude text is an embarrassment. The same injection routed into a tool that has a write token against your source control, your CRM or your cloud console is an incident with a blast radius.
The difference is consequence. Once software can call tools, the security question moves from "what did it say" to "what did it change, under whose authority, and can you undo it".
What can AI agents actually do inside an enterprise?
Start with capability, because controls that do not match capability are theatre. The agents already inside most enterprises are not research prototypes; they are developer tools and platform SDKs with real credentials.
Code agents that run commands. Claude Code edits files and runs shell commands, with a permission system, a working-directory boundary and an optional sandbox with filesystem and network isolation. Cursor runs shell commands directly in the terminal, with a run mode that decides when a command executes, when the user is asked, and when it goes to a sandbox. GitHub Copilot's coding agent runs in an ephemeral environment powered by GitHub Actions, explores a repository, changes code on a branch, runs tests and opens a pull request.
Agent frameworks that hand off and delegate. The OpenAI Agents SDK is built on agents, tools, handoffs to other agents, and guardrails, with built-in tracing. Handoffs matter to security: an approval given to one agent can be exercised by another one downstream.
A standard tool interface. The Model Context Protocol, announced by Anthropic in November 2024, is now the common way to connect assistants to content repositories, business tools and development environments. The MCP specification is explicit about the risk it carries: tools "represent arbitrary code execution and must be treated with appropriate caution", tool descriptions "should be considered untrusted" unless the server is trusted, and hosts must get explicit consent before invoking a tool. It also says plainly that MCP itself cannot enforce those principles at the protocol level. That enforcement is your job.
Browsers and business systems. Agents drive headless browsers, read email and files, and call SaaS APIs. The credential is usually an OAuth grant or a long-lived token, and it is usually broader than the task.
Identity. This is the newest layer. Okta for AI Agents treats agents as first-class identities with a named human owner, discovers unknown agents by surfacing OAuth consent grants, and enforces short-lived credentials. TechRadar covered the launch. The direction of travel is clear: an agent without an identity cannot be governed, audited or revoked.
The practical exercise is to write down, for each agent in use, the tools it can call, the identity it acts as, the systems that identity can change, and who owns it. Most teams cannot complete that table today. Our AI supply chain map walks the same chain hop by hop.
What are the security risks of AI agents?
The two reference sets worth mapping to are the OWASP Top 10 for LLM Applications and the OWASP Top 10 for Agentic Applications, published on 9 December 2025 by the OWASP GenAI Security Project. Adversary behaviour against AI systems is catalogued separately in MITRE ATLAS.
| Risk | What it looks like | Framework reference |
|---|---|---|
| Prompt injection via tool output | A web page, ticket, README or MCP tool result contains instructions the agent follows as if you wrote them | LLM01 Prompt Injection; ASI01 Agent Goal Hijack |
| Excessive agency | The agent holds a token that can do far more than the task requires, so one bad step is unbounded | LLM06 Excessive Agency; ASI02 Tool Misuse |
| Credential and token sprawl | Agents share a service account, or hold long-lived OAuth grants nobody reviews or maps to an owner | ASI03 Identity and Privilege Abuse |
| Tool poisoning and supply chain | Hidden instructions in a tool description, or a server changing behaviour after approval | LLM03 Supply Chain; ASI04 Agentic Supply Chain Vulnerabilities |
| Unexpected code execution | Generated or fetched code runs in an environment with production reach | ASI05 Unexpected Code Execution |
| Memory and context poisoning | Earlier poisoned content persists and steers later, unrelated sessions | ASI06 Memory and Context Poisoning |
| Data exfiltration through tools | Sensitive data leaves inside a legitimate-looking tool call parameter | LLM02 Sensitive Information Disclosure |
| Shadow AI | Unapproved agents and MCP servers connected to corporate data without review | ASI10 Rogue Agents |
| Unlogged consequential actions | The action happened; no record ties it to a decision-maker, an approval or a reversal | Not a vulnerability class. An evidence gap |
Tool poisoning deserves a note, because it is specific to this architecture. Invariant Labs demonstrated in April 2025 that instructions hidden in an MCP tool description are invisible to the user but read by the model, and that a malicious server can shadow a trusted one or change a description after approval. The user approves a summary; the model reads the whole thing. OWASP's Agentic AI Threats and Mitigations guide, published February 2025, is the fuller threat model.
The last row is the one boards run into. It is not a vulnerability; it is the absence of the evidence you need when one of the rows above happens.
How do you secure AI agents?
Controls by layer, in the order they pay back.
Identity and least privilege. Every agent gets its own identity with a named human owner. No shared service accounts. Short-lived credentials, scoped to the task, with an inventory that maps identity to owner to tool scope. Revocation must be testable, not theoretical.
Tool allow-lists and MCP governance. Approve MCP servers explicitly and pin them. Treat a change to a tool description as a change requiring re-approval, because the MCP specification does not stop a server changing it. Keep the allow-list in version control alongside the agent configuration, so it reviews like code.
Sandboxing. Run agent commands with filesystem and network isolation by default, as Claude Code's sandbox and Cursor's run modes both allow, and as Copilot's ephemeral GitHub Actions environment provides. Assume every fetched document is hostile input.
Human approval for consequential actions. Define "consequential" in advance: writes to production, financial movement, access changes, external communication, anything irreversible. Everything else can run without a prompt. Approval fatigue is a real control failure, because prompting on everything trains people to click yes.
Logging that reconstructs the whole chain. Covered in the next section, because it is where most programmes are thinnest.
Reversal and rollback. For each consequential action, know in advance whether it can be undone, by whom, and how long that takes. An agent that can act faster than you can reverse is an agent operating outside your risk appetite.
Detection of shadow AI on the network. Discovery cannot rely on asking people.
Two of our guides go deeper on the governance side: what a board AI risk assessment should cover and how to evaluate an AI security vendor's claims. If you are considering AI-driven offensive testing as part of assurance, does AI pentesting work sets out what to measure first.
How do you monitor and prove what an AI agent did?
Here is the constraint that shapes everything else: provider logs only record their own world. Every provider records its own side: prompts, tokens, tool calls it initiated, sometimes an output. That is real telemetry and worth collecting. It stops at the provider's boundary. It does not show which system the output touched, who approved the next step, whether the write could be undone, or how long it took a human to notice. We set out what each tool records, and what nobody records, in what Claude Code, Cursor, OpenAI, Copilot and MCP actually log.
Reconstruction needs five kinds of evidence joined on one chain: provider (the session and the tool call), identity (which principal, which token, which scope), tool (which MCP server or API, which parameters), network (where the traffic actually went), and target system (what changed, and whether it was reversed).
A worked example. A developer asks a coding agent to triage a bug from a customer-submitted issue. The issue body contains hidden text instructing the agent to read a credentials file and post it to an external endpoint.
- Provider evidence shows the session, the prompt, and a sequence of tool calls, one of which is an HTTP request.
- Identity evidence shows the agent acted as a CI service principal whose token also carries write access to two unrelated repositories. That is excessive agency, and it is visible only from the identity side.
- Tool evidence shows which MCP server served the request and what parameters were passed, which is where exfiltrated data typically travels.
- Network evidence shows the destination the provider log never names, and whether the connection succeeded.
- Target-system evidence shows the file read, the branch created, and whether the credential was rotated afterwards.
No single one of those five answers "what happened". Joined, they answer it in order, with times. That is the whole argument on /security-for-ai: connect provider, identity, tool, network and target-system evidence so a team can find missing authority, contain access and prove whether the result was reversed. SenseOn's Decision Trace records the task, the evidence, the agent's contribution and the human decision for SenseOn's own agents; it does not record the internals of a third-party provider's runtime. The claims behind our published numbers, with their denominators, are on /proof-points. Before approving wider autonomy, work through the seven questions in provider logs can't prove what your AI agent did.
Which frameworks and regulations apply?
- NIST AI Risk Management Framework. Voluntary, version 1.0 released 26 January 2023, organised around four functions: Govern, Map, Measure, Manage. Useful as the structure for your programme.
- ISO/IEC 42001. The AI management system standard, published December 2023, and the certifiable route most enterprises will be asked for.
- EU AI Act. Prohibitions and AI literacy obligations applied from 2 February 2025; general-purpose AI model rules, governance and penalties from 2 August 2025; the general application date was 2 August 2026, so most obligations now apply, with high-risk obligations phasing in from 2 December 2027 and 2 August 2028. (Timeline as published by the EU AI Act implementation tracker, checked 4 September 2026. You will meet older dates elsewhere.)
- OWASP GenAI Security Project. The LLM Top 10 and the Agentic Top 10 above. The most directly usable engineering checklist of the set.
- MITRE ATLAS. Adversary tactics and techniques against AI-enabled systems, structured like ATT&CK, for detection engineering and purple teaming.
- UK NCSC. The Guidelines for secure AI system development (27 November 2023) cover secure design, development, deployment, and operation and maintenance; the machine learning principles (22 May 2024) cover the lifecycle.
None of these tells you whether your agents are governed today. They tell you what good looks like. The evidence question is still yours.
How do you detect shadow AI?
Shadow AI is AI use that IT and security have not approved: an unapproved assistant, an MCP server a developer wired up on a Friday, a personal API key on a corporate laptop. Okta's framing is the useful one: unapproved agents create a visibility gap, and OAuth consent grants are one place they surface.
Four detection routes, cheapest first.
- Identity. Review OAuth consent grants and API tokens against approved agents. Unowned grants are the signal.
- Network. Detect traffic to AI provider APIs and inference endpoints from hosts and segments that have no approved use. This is the route that finds what nobody declared, and the one that does not depend on an agent being registered.
- Endpoint. Look for agent CLIs and MCP server processes on developer machines, and for local configuration files that list servers.
- Cloud and SaaS. Look for model API spend, new service principals, and app integrations created outside change control.
Then close the loop: a discovered agent gets an identity, an owner, a scope and a logging path, or it gets revoked. Discovery without that loop is a list that ages.
Frequently asked questions
What is agentic AI security?
Agentic AI security is the practice of governing AI systems that take actions rather than only producing text. It covers the identities an agent uses, the tools and systems it can reach, the approvals required before consequential steps, and the evidence needed to reconstruct, contain and reverse what the agent did. It is an operational security problem, not a model problem.
How do I secure agentic AI?
Give every agent its own identity with a named human owner and short-lived, least-privilege credentials. Approve and pin the MCP servers and tools it may call. Sandbox command execution with filesystem and network isolation. Require human approval for consequential actions only, so approvals stay meaningful. Log across provider, identity, tool, network and target system, and know in advance how each action is reversed.
What are the security risks of AI agents?
The main risks are prompt injection carried in tool output, excessive agency from over-scoped tokens, credential and token sprawl, tool poisoning and agentic supply chain compromise, unexpected code execution, memory and context poisoning, data exfiltration inside tool call parameters, and shadow AI. Underneath all of them sits an evidence gap: consequential actions that no record ties to a decision-maker, an approval or a reversal.
What is shadow AI?
Shadow AI is AI use that IT and security have not approved: an unapproved assistant, an MCP server a developer wired up without review, or a personal model API key used on a corporate device. It matters because unapproved agents hold real credentials and reach real systems while sitting outside inventory, logging and revocation. Detect it through identity, network, endpoint and cloud evidence.
Does the EU AI Act apply to AI agents?
Yes, where an agent falls within the Act's scope. Prohibitions and AI literacy obligations applied from 2 February 2025, general-purpose AI model rules and governance from 2 August 2025, and the general application date was 2 August 2026, so most obligations now apply. High-risk obligations phase in from 2 December 2027 and 2 August 2028. Obligations follow the use case and risk tier, not the word agent.
