Agentic AI is the version of AI that does things. A chatbot gives you an answer and waits. An agent plans a sequence of actions and carries them out: querying a database, sending an email, calling an API, executing code, updating a record. The difference matters because the risk profile changes entirely.
Most security thinking about AI has focused on what the model says. Hallucinations, biased outputs, inappropriate responses. With an agentic system, the output is completed work. The model produces a plan and the system executes it. Every tool call the agent makes is a real operation on a real system.
That is why agentic AI has to be governed differently from a chatbot. And why most enterprise security programmes are behind the curve on this.
What makes an AI agent different from a chatbot?
A standard AI assistant works in a request-and-response loop. You type, it replies, nothing else changes in your environment.
An agent has tools. Tools might be functions to read or write files, queries to a database, APIs to external services, web search, calendar access, code execution. When the agent determines a tool call is needed to complete your request, it makes that call. It may make dozens of tool calls across a single task, chaining the output of one into the input of the next, without consulting you at each step.
This is exactly what makes agents commercially attractive. The same property is what makes them a live security risk. An agent acting on a corrupted instruction, or one with excessive permissions, can direct those tool calls in the wrong direction. The consequences are not a misleading sentence. They are actions taken in your systems.
The four places agents can be exploited
Prompt injection, direct and indirect. OWASP lists prompt injection first among LLM application risks for 2025, and for agents the stakes are higher than in a conventional chatbot. A direct injection slips a malicious instruction into the user's own message. An indirect injection is more dangerous: it hides in content the agent retrieves while working. A document it was asked to summarise. A web page it searched. An email thread it is processing. The agent reads the embedded text as part of its working context and follows the instruction as though it came from the user. Our deeper coverage of prompt injection in production AI systems sets out how these attacks work and where in an architecture they can be intercepted.
For an agentic system with real tool access, an injected instruction does not just change the answer. It redirects the agent's actions. A carefully crafted injection embedded in a supplier invoice could tell a finance automation agent to approve and forward it to a different account. The agent will comply unless something in its design prevents it.
Excessive agency. OWASP classifies this as LLM06:2025 in its LLM Application Security Top 10. The principle is familiar from traditional security: an agent should hold the minimum permissions that let it complete its defined function, and no more. Every permission beyond that is potential blast radius. An agent managing internal calendars does not need write access to the shared document store or the ability to send external email. When those extra permissions exist, a manipulated or misbehaving agent can use them. Most enterprise deployments acquire broad permissions early in a project for convenience, and those permissions never get narrowed.
Privilege escalation and tool misuse. An agent that can call other agents, spawn subprocesses, or chain into automation tools carries an escalation path most organisations have not thought through. A compromised agent can instruct a second agent with different access, or use a legitimate automation tool such as a webhook or browser automation script to reach systems outside its apparent scope. The pattern mirrors what penetration testers see with human-operated lateral movement. The entry point has limited access; the path through connected services reaches much further.
Data exfiltration through legitimate channels. An agent working with sensitive material, client records, financial documents, personal health information, can be directed to summarise and forward that data through a channel the agent is already authorised to use: an email, a calendar invite, a webhook, an API call to a storage service. Because the channel is legitimate, conventional data loss prevention tools may not flag it. The traffic is not anomalous. The agent is calling its authorised tools. The problem is what it was instructed to put in the payload.
What a compromised agent actually looks like in a regulated firm
Consider an agentic AI assistant deployed to support a client-facing team at an FCA-regulated wealth manager. Its tools include calendar scheduling, email drafting, CRM record lookup, and document generation. All reasonable capabilities for the role.
An attacker embeds a prompt injection in a phishing email from a spoofed client address. The agent, processing the inbox as part of its normal workflow, reads the embedded instruction: summarise the last three client portfolio reports and send them to a specified external address. The agent's tools include exactly those capabilities. It complies.
The data has left through an authorised email channel. The agent log, if one exists at all, shows a normal tool call. Nobody sees anything unusual until a client raises a question about data they did not expect to be shared.
For a firm under Consumer Duty and the FCA's model risk expectations, this is a material incident. Being able to demonstrate what the agent did, when, with whose data, and what triggered it is the job of the audit trail. Most firms deploying agents today could not reconstruct that sequence of events with any confidence.
What the FCA and PRA expect from firms using agentic AI
The FCA and PRA do not yet have a specific rulebook for agentic AI. They govern it through existing frameworks: the Senior Managers and Certification Regime, Consumer Duty, SYSC, and the principles of operational resilience. What those frameworks require is accountability and evidence.
A firm that cannot explain how an AI influenced or executed a decision affecting a customer is in a weak position under Consumer Duty. The oversight requirements embedded in the Senior Managers regime assume that someone can account for what the firm's systems did and why.
An agentic system acting autonomously at scale can produce hundreds of consequential actions an hour. Logging what those actions were, what triggered them, and what data they touched is the minimum evidence trail that accountability requires. Our AI governance framework for enterprise sets out how that trail should be structured, and why the gap between what the policy intends and what the logs actually capture tends to be wider than teams expect when they first look.
Four controls that actually work
Security hygiene for agentic AI is newer than for conventional software, but the underlying principles are familiar. The difference is that they need to be built into agent design from the start. Retrofitting them is substantially harder.
Principle of least privilege on tools. Each agent should receive only the permissions it needs to complete its defined function. If a document-review agent does not need to send external email, it should not have that tool available. Scope tool access to the tightest practical boundary at design time, and review it whenever the agent's function changes. This single control limits how far a manipulated agent can go.
Human escalation paths for high-consequence actions. An agent can be designed to pause and request human confirmation before actions that cross a defined threshold: external data sharing, financial transactions above a limit, bulk record modification. This is sometimes called a human-in-the-loop pattern. It slows down full autonomy, and for high-stakes actions in a regulated context, that is the right trade-off. Speed is not the primary value when the action in question is irreversible.
Logging at the tool-call level. Every tool invocation the agent makes should be recorded: which tool was called, with what parameters, what it returned, and what the agent did next. This is different from logging the user's prompts. Tool-call logging captures what the agent actually did to your systems. Without it, reconstruction after an incident is nearly impossible. The AI audit trail for compliance article covers what that logging needs to capture and what a regulator will expect to see.
Input and output guardrails. Content screening should run on what goes into an agent, to catch injected instructions, and on what comes out, to catch data that should not be leaving. Guardrails are not foolproof against sophisticated injection, but they raise the difficulty meaningfully and catch the common cases. Pair them with AI policy enforcement in production controls that act at the infrastructure layer, not just at the policy-document layer.
None of these controls adds significant burden to a system designed with them in mind. Each is expensive to add after the fact.
Third-party agent frameworks and supply chain risk
Most enterprise agentic deployments are not built on bespoke infrastructure. They use orchestration frameworks, pre-built connectors, and tool libraries maintained by third parties. A vulnerability in an orchestration layer, a compromised plugin in an agent marketplace, or an insecure API from a tool provider can all reach into your agent's capabilities.
This is the agentic version of a software supply chain risk, and it scales with every new tool integration you add. Foundation model and supply chain risk for CISOs covers the framework layer specifically. AI third-party vendor risk sets out the vendor assessment questions that belong in any procurement process where agentic capabilities are involved. The short version: agents amplify supply chain risk because a compromised dependency does not just affect what the model says. It affects what the system does.
Shadow agentic AI: the deployments nobody reviewed
The riskiest agentic deployment in most organisations is the one nobody knows about. Staff are building no-code automation workflows that chain AI models with business system connectors. They are connecting productivity agents to shared drives, CRMs, and email without any security review. They are experimenting with hosted agent platforms that sit entirely outside the approved software list.
Shadow AI as a concept is not new. The agentic version is sharper because the distance between "exploring a tool" and "running a process with real consequences" has narrowed dramatically. A chatbot a team member experiments with is a data governance issue. An agent they have set up to automate a workflow is potentially making consequential decisions about real client records, unsupervised, while nobody is watching.
A discovery exercise that maps both the sanctioned agents your organisation has deployed and the unsanctioned automation workflows staff have built on their own gives you the starting position you need. Without it, every other governance effort is working from an incomplete picture.
Where to start
The first step is always inventory. You cannot apply least privilege, build audit logging, or define escalation paths for agents you do not know about.
From that inventory, the work is classification and control. Which agents have which tool access? Which produce any logging? Which operate within human escalation paths? Which are built on third-party frameworks that have not been through a security review?
Firms that wait for a regulatory enquiry or a material incident to answer those questions will find the reconstruction far more expensive than the governance would have been. The AI Control Plane is the programme structure we use to bring that discovery, classification, and control into a managed and evidenced form that holds up to scrutiny. An AI governance framework for enterprise gives you the policy scaffolding around it.
Agentic AI is moving faster than most governance cycles. Closing the gap is much easier at the design stage than six months after deployment, when the permissions are baked in and the logs are missing.