The Word Everyone's Throwing Around This Year
The word everyone's throwing around this year is "agentic." Every vendor pitch, every product launch, and every LinkedIn post from someone who discovered the term four months ago is suddenly about AI agents that "research," "execute," and "act on your behalf." If you're still confused by the terminology, our comprehensive guide on [what AI agents are](/blog/what-are-ai-agents-complete-guide-for-businesses-2026) breaks down the core concepts. Underneath the hype, something real is happening. Businesses are handing AI systems real tools, real credentials, and real permission to touch production data, send emails, move money, and modify records, all without a human typing every single instruction.
That's a genuinely different kind of software than the chatbot era we just lived through. A chatbot that gives a bad answer is embarrassing. An agent that takes bad action with a live API key, a connected CRM, and a Slack bot token is a completely different category of problems. It doesn't just say the wrong thing. It does the wrong thing, and by the time anyone notices, the email may already be sent, the record may already be deleted, and the money may already have moved.
This is the piece almost nobody wants to write, because it's less exciting than the "agents are the future of work" narrative. But it's the piece that matters if you're the person whose job it is to decide what an AI system is allowed to touch. So, let's get into it properly: what AI agent security actually means, the real threats that show up in production, the mistakes that keep repeating across different companies and different tools, and a practical, unglamorous framework for deploying agents that do real work without becoming the reason your company ends up in a postmortem.
What "AI Agent Security" Actually Means
Before going further, it's worth being precise about what we're even talking about, because the phrase gets used loosely.
Traditional application security is mostly about protecting a system from an attacker who's trying to get in. AI agent security includes that, but it adds an entirely new attack surface that didn't exist before, which is the reasoning layer itself. An AI agent doesn't just have code that can be exploited. It has a decision-making process, driven by natural language, that can be manipulated, confused, or quietly steered by the very data it's supposed to be processing.
Put simply, AI agent security is the discipline of making sure an autonomous or semi-autonomous AI system does only what it's supposed to do, only with the access it's supposed to have, and only in ways a human can review and reverse, even when the inputs it's fed are messy, adversarial, or outright malicious.
That last part is the crux of it. A traditional program executes fixed logic. Feed it unexpected input and, at worst, it crashes or throws an error. An AI agent interprets input and decides what to do based on that interpretation. Feed it the wrong input, worded the right way, and it might not crash at all. It might just calmly do exactly the wrong thing, convinced it's doing exactly the right thing, and there's often no error message to catch, because from the model's point of view, nothing went wrong. It followed instructions. They just weren't the instructions its actual owner intended.
That's the fundamental shift security teams are adjusting to right now, and it's why simply adding the AI stuff to an existing security checklist doesn't really work. The checklist must change because the nature of the thing being secured has changed.
Why This Conversation Is Suddenly Urgent
A few years ago, this would have been a mostly theoretical conversation. Large language models existed, but almost nothing they touched had real world consequences beyond the text on a screen. That's no longer true, and the shift happened faster than most security teams could adjust to.
Three things changed at roughly the same time. First, models got genuinely good at multi step reasoning and planning, which made autonomous, multi-step task execution actually viable rather than a research curiosity. Second, tool use, the ability for a model to call an external function, hit an API, query a database, or browse a live webpage, became standard practice rather than an experimental feature, largely thanks to protocols like the Model Context Protocol that made connecting an AI system to real business tools dramatically easier. Third, and this is the part that matters most for security, businesses started connecting these newly capable, newly tool using systems directly to production infrastructure: CRMs holding real customer data, email systems that can send to real inboxes, payment platforms that can move real money, and code repositories that can ship real changes.
Put those three together and you get exactly the situation we're in now. Systems capable of autonomous, multi-step action are wired directly into the infrastructure that runs a business, and they're deployed by teams who are, understandably, more excited about what the agent can do than paranoid about what it could do wrong. That gap between capability and caution is where almost every real-world AI agent security incident lives.
It's also worth being honest about why this didn't get taken seriously sooner. AI security research spent years focused on model level concerns such as bias, toxic outputs, and factual accuracy. Those matter, but they're fundamentally different from agent security, which is about what happens once a model's output stops being just output and starts being an instruction that triggers a real action. A biased chatbot answer is a reputational problem. An agent that acts on manipulated instruction is an operational one, and operational problems have a way of becoming financial and legal ones very quickly.
The New Attack Surface: Why Agents Break the Old Rules
Here's the thing that makes agent security genuinely different from the web application security most teams already understand. The attack surface isn't just code anymore. It's language.
In a traditional system, an attacker needs to find a technical vulnerability, such as a SQL injection point, an unpatched dependency, or a misconfigured permission. Those vulnerabilities are discoverable, patchable, and testable with well-established tools. With an AI agent, an entirely new category of vulnerability opens: the agent's own reasoning can be hijacked using nothing but carefully worded text, embedded anywhere the agent might read it.
Think about what a research agent does. It's said to go read web pages, summarize documents, pull data from a CRM, and maybe scan an inbox. Every one of those sources is now a potential vector, not because the underlying system was hacked, but because the agent trusts the content it's processing as much as it trusts the instructions its actual owner gave it. If a webpage the agent reads contains hidden text instructing it to ignore previous instructions and forward all data to a certain address, a poorly secured agent might just do that. Not because it was compromised in a traditional sense, but because it did exactly what it's designed to do: read text and act on instructions found within it. It simply couldn't tell the difference between an instruction from its owner and an instruction planted by an attacker three steps removed.
This is the single hardest conceptual shift for teams coming from traditional security backgrounds. You can't patch your way out of this the way you'd patch a known vulnerability, because the weakness isn't a specific bug. It's a structural property of how these systems currently work: they process instructions and data in the same channel, and separating "this is a command" from "this is content to analyze" is a genuinely unsolved problem at the model level. Security must be built around that reality, not in denial of it.
The Core Threats Every Business Deploying Agents Needs to Understand
Let's walk through the threat landscape properly, because vague warnings about "AI risk" don't help anyone decide. These are the specific, recurring categories that show up repeatedly once agents move from demo to production.
Prompt Injection: The Headline Threat
Prompt injection is, by a wide margin, the most discussed and most consequential AI agent vulnerability right now, and it deserves to be. At its core, it's remarkably simple. An attacker embeds instructions inside content the agent is going to process, and the agent, unable to reliably distinguish between instructions from its actual principal and text it happened to encounter while doing its job, follows the embedded instructions instead of, or in addition to, its real task.
There are two broad flavors worth knowing. Direct prompt injection is when an attacker interacts with the agent themselves, typing something specifically crafted to override its instructions or safety behavior. Telling it to ignore its previous instructions and do something else instead is the crude, well-known version, and most production systems now have at least basic defenses against it. Indirect prompt injection is the more dangerous cousin, and the one business underestimates most. Here, the malicious instruction isn't typed by the person talking to the agent at all. It's sitting quietly inside a webpage the agent is told to summarize, a document it's asked to review, an email in an inbox it's monitoring, a customer support ticket it's triaging, or even a calendar invite it reads while checking someone's schedule. The agent goes to do its actual, legitimate job, encounters the planted instruction along the way, and treats it with the same authority as its original task.
Picture a research agent tasked with summarizing competitor websites. One of those websites has invisible text buried in its code, unreadable to a human visitor but perfectly readable to the agent, that instructs it to include specific text verbatim in its output, or to append a particular link to any report it generates. A poorly defended agent doesn't know that instruction came from a stranger's website rather than its actual owner. It just sees text and, depending on how it's built, may treat it as something to comply with.
Now scale that up. Consider an agent with email access that reads a message containing hidden instructions to forward sensitive attachments to an external address. Or a customer support agent that reads a ticket containing text designed to make it reveal internal system prompts, other customers' data, or discount codes shouldn't be authorized to issue. Or a coding agent reviewing a pull request that contains a comment engineered to make it introduce a subtle backdoor into the codebase it's helping maintain. None of these require breaching a firewall. They require nothing more than getting text in front of an agent that will read it.
Excessive Agency and Permission Sprawl
This is the threat that has the least to do with clever attackers and the most to do with plain organizational carelessness, which makes it more common, not less dangerous.
Excessive agency describes exactly what it sounds like. It's an agent that has been granted more autonomy, more tool access, or more reach than its actual job requires. It happens gradually and reasonably at every step. An agent gets built to draft outreach emails. It works well, so someone adds the ability to send them. It works well again, so someone connects it to the full CRM instead of just the leads it's working. Eventually you have an agent originally scoped for drafting a first touch email that quietly holds write access to the entire customer database, send access to the full email system, and no one entirely remembers deciding that it should have all of that at once.
The danger isn't that the agent will maliciously misuse that access. It's that a single bad output, whether a hallucinated instruction, a successful prompt injection, or a subtle reasoning error nobody caught, now has a blast radius as large as everything the agent can touch, rather than as large as the one narrow task it was originally meant to do. Least privilege access is not a new security idea. It's one of the oldest ideas in the field. It just gets forgotten surprisingly fast once a tool proves itself useful and everyone's instinct is to give it more to do.
Tool and API Misuse
Once an agent can call external tools, and modern agents almost always can, that's most of the point of building one, a whole new failure mode opens that simply didn't exist for a text only chatbot. Tools are how an agent's reasoning turns into real world consequences, and every tool it can call is a lever an error, a manipulation, or a misjudgment can pull.
This shows up in a few recognizable ways. An agent might call the right tool with the wrong parameters, because it misread a number or misunderstood a date range, and deleted or updated far more records than intended. It might chain tools together in a sequence nobody anticipated, using a read tool to gather information and a write tool to act on it, in a combination that individually looked safe but collectively produced an unintended outcome. It might also be tricked, through prompt injection, into calling a tool it has legitimate access to for a purpose its owner never sanctioned, using a legitimate email sending capability to exfiltrate data to an attacker-controlled address, for instance, rather than to send the outreach it was actually built for.
The core lesson here is that tool access needs its own security thinking, separate from the model's own behavior. A perfectly well-behaved model with an overly powerful tool set is still a serious risk, because the danger isn't only in what the model decides to do, it's in what it's technically capable of doing once it decides.
Data Leakage and Sensitive Information Disclosure
Agents are frequently built specifically to move information around, summarizing documents, pulling records, and drafting communications based on internal data. That's exactly the capability that makes data leakage such a persistent risk category.
This can happen in mundane, non-malicious ways. An agent asked to draft a customer email might pull in details from an internal note that was never meant to be customer facing. A research agent building a report might inadvertently include confidential figures from an internal document because it wasn't clearly told the boundary between what's safe to reference internally and what's safe to include in external output.
It can also happen through deliberate manipulation. A cleverly worded prompt, sometimes phrased entirely innocently and sometimes explicitly engineered to bypass restrictions, can convince an under defended agent to reveal its own system instructions, disclose data belonging to a different customer or account it has access to for legitimate reasons, or describe internal processes and tooling that were never meant to be shared outside the company. And because an agent frequently has broader read access than any single human employee would ever be granted, since it might sit across the CRM, the support system, and internal documentation simultaneously to do its job well, a successful manipulation can expose a genuinely wide blast radius of information in one interaction.
Memory Poisoning and Persistent Manipulation
This one is subtler and gets far less attention than prompt injections, but it's arguably more dangerous for agents that run continuously over long periods, because the damage compounds silently.
Agents that are genuinely useful over time need memory, a record of what happened in previous runs, decisions made, and context accumulated, so they're not starting from zero every single time they execute. But memory that can be written to by outputs the agent itself processes are memory that can potentially be corrupted. If an attacker can get a false or manipulated fact recorded into an agent's persistent memory, through a cleverly crafted document it summarized once, an email it processed, or a note it saved to its own context, that corruption doesn't go away after one interaction. It sits there, quietly shaping every future decision the agent makes, until someone notices the agent's behavior has drifted in a way nobody explicitly asked for and must go hunting for why.
Imagine a sales agent that, over the course of routine prospect research, gets fed a poisoned piece of content that causes it to remember a falsehood about pricing or a fabricated internal policy. Every future email it drafts might now reflect that falsehood, consistently and confidently, until a human happens to catch the pattern. That's a slow burning, hard to trace failure mode, precisely because nothing about any single interaction looks obviously wrong.
Supply Chain and Third-Party Tool Risk
Almost no agent operates in total isolation. It's built on a foundation model from one vendor, connected to tools and integrations from a dozen others, often through open standards like the Model Context Protocol that make it trivially easy to plug in a new capability. That convenience is genuinely valuable, and it's also a new supply chain to worry about.
Every third-party tool, plugin, or connector an agent uses is code and infrastructure you didn't write and don't fully control, running with whatever access your agent has been granted. A malicious or compromised MCP server, a poorly secured third-party integration, or a plugin that quietly changes its own behavior after you've already trusted and connected it, can become a direct pathway into whatever your agent touches. This is a familiar shape of problem for anyone who's dealt with traditional software supply chain risk, trusting a dependency you didn't audit, except now that dependency isn't just running code. It's potentially able to shape what an autonomous system decides to do next.
Model Level Manipulation and Adversarial Inputs
Beyond prompt injections specifically, there's a broader category of adversarial techniques aimed at making a model behave in ways its builders didn't intend. Jailbreaking attempts to strip away a model's safety behavior through carefully constructed prompts. Adversarial inputs are crafted specifically to exploit quirks in how a model processes information, sometimes producing outputs that look nothing like what a normal user would ever trigger by accident. These techniques evolve constantly, in something close to an arms race between model providers hardening their systems and researchers, sometimes well intentioned and sometimes not, finding new ways around those defenses.
For business deploying agents, the practical takeaway isn't that you personally need to become an adversarial ML researcher. It's that you should assume the underlying model can, under the right conditions, be pushed into behavior its creators didn't intend, and design your agent's permissions and approval gates as if that will eventually happen rather than hoping it won't.
Multi Agent and Orchestration Risks
As businesses move from single agents to coordinated fleets of specialized agents handing work off to one another, a newer, less understood risk category emerges what happens when the failure isn't in any single agent, but in the handoff between them. Understanding the architecture of [multi-agent systems](/blog/multi-agent-systems-what-they-are-and-how-they-work) is critical to understanding these cascading failures.
An error, a piece of manipulated data, or a poisoned instruction introduced at one stage of a multi agent pipeline doesn't necessarily stay contained to that stage. It can propagate downstream, picked up as trusted context by the next specialist in the chain, compounding as it moves through a system where each individual agent is behaving exactly as designed, trusting input that's already been quietly corrupted upstream. Multi agent systems are genuinely powerful, and that's precisely why specialized handoffs are becoming the dominant pattern for serious agentic work, but they also mean a security review can't stop at asking whether each individual agent is safe. It must ask whether the connections between agents are trustworthy too.
Identity, Authentication, and Impersonation Risk
A less discussed but increasingly relevant issue is how an agent authenticates itself, and how confidently a system on the other end of an interaction can tell it's talking to your legitimate agent rather than something impersonating it. As agents increasingly interact with other systems, other agents, and other companies' automated processes, the question of machine identity, proving which system is acting and, on whose authority, becomes a real security question, not just a human focused one. An agent operating with stolen or overly broad credentials, or a malicious actor standing up for something that convincingly impersonates a trusted agent in a business-to-business workflow, is a threat model that's only going to grow as agent-to-agent interaction becomes more common.
Why Traditional Security Tools Aren't Enough on Their Own
It's tempting to assume your existing security stack, including firewalls, endpoint protection, standard access controls, and a compliance audit, covers this new territory. Some of it genuinely helps. Most of it wasn't built with this threat model in mind and treating it as sufficient is exactly how gaps get missed.
Traditional access controls are built around the assumption that the entity requesting access is either a known human or a known, narrowly defined service account doing one predictable thing. An AI agent doesn't fit that assumption cleanly. It's a single credentialed identity that can be manipulated, through language, into requesting things its human operators never anticipated. A firewall doesn't know the difference between a legitimate API call an agent makes and the exact same API call made because a prompt injection convinced it too. From the network's point of view, both look identical: an authenticated, authorized request. The problem isn't happening at the network layer at all. It's happening upstream, in the reasoning that decided to make the call in the first place.
Standard input validation, similarly, is built to catch malformed data, such as the wrong type, an unexpected format, or a string where a number was expected. It's not built to catch a perfectly well formed, grammatically correct sentence that happens to be an attempt to manipulate a reasoning system. That's a fundamentally different kind of bad input, and it requires a fundamentally different kind of defense, one built around what the agent is allowed to do once it's convinced of something, not just around whether the data it received was technically valid.
None of this means you should throw out your existing security practices. It means recognizing that they're necessary but not sufficient, and that agent specific controls must sit on top of them, purpose built for a system whose primary interface is language rather than structured input.
The Best Practices That Actually Hold Up in Production
This is the part that matters most, because understanding the threats is only useful if it changes what you do. Here's the practical framework, built from the patterns that consistently separate businesses’ running agents safely from the ones that end up writing an incident report.
Design is the least privilege from day one. Every agent should have access to exactly the tools, data, and systems its specific job requires, nothing more, and that scope should be a deliberate decision, revisited regularly, rather than something that quietly expands because it's easier than saying no. If an agent's job is auditing website SEO, it has no legitimate reason to touch payroll data or send financial transactions. Scope access to the task, not to whatever might be convenient someday.
Put a real human approval gate on anything consequential. This is the single most important control in the entire framework, and it's the one that turns a genuinely risky autonomous system into a genuinely useful one. Autonomous research, drafting, and analysis can run freely without a human in the loop for every step, because the worst-case outcome of research or drafting error is wasted time, not real-world damage. But anything that leaves the boundary of the system and touches the outside world, such as sending an email, publishing content, modifying a customer facing record, moving money, or changing a production system, needs a checkpoint where an actual human looks at the proposed action and explicitly approves it before it happens. The gate must be real too, meaning a genuine review step someone looks at, not a checkbox nobody reads because the agent has never been wrong before.
Treat all external content as untrusted, always. Any content an agent reads that didn't come directly and verifiably from its actual owner, such as a webpage, an email, a document, a support ticket, or another agent's output, should be treated as potentially adversarial by default, not as trusted instruction. This is a mindset shift as much as a technical one: clearly separating instruction channels from data channels wherever the underlying architecture allows it, and treating anything ambiguous as data to be summarized, not instructions to be obeyed.
Log everything and make the logs reviewable. Every tool call, every decision, and every piece of output an agent produces should be logged in a way that's exportable and genuinely reviewable by a human, not just technically stored somewhere. When something does go wrong, the difference between a quick, confident root cause fix and a week’s long forensic scramble is almost entirely down to whether you have a clear, complete audit trail of what the agent did, when, based on what input, and who approved it.
Run new agents in shadow mode before trusting them live. Before letting a new agent, or a newly expanded scope for an existing one, act with real consequences, let it run for a meaningful stretch of time producing recommendations and draft actions that a human reviews against what they’d done, without those actions executing. Early performance on the easy cases tells you very little about how an agent handles the edge case that shows up on the fiftieth run rather than the first.
Segment and isolate wherever possible. Don't let a single agent identity span every system in your business if the job doesn't require it. Isolate an agent's execution environment, its credentials, and its data access from unrelated systems, so that even a badly manipulated agent has a limited blast radius rather than a companywide one.
Validate tool outputs, not just tool inputs. Most teams instinctively think about validating what goes into a tool call. Fewer think about validating what comes back. If an agent calls a tool, receives a result, and immediately acts on it without any sanity check, a compromised or manipulated data source can feed corrupted information straight into the agent's next decision.
Keep a named human owner for every agent. Every agent running in production should have one specific person responsible for its scope, its performance, and its output quality, not a vague sense that the team is watching it. Ownerless agents drift toward being over trusted or quietly ignored, and neither outcome is safe.
Review scope and access on a fixed schedule. Put an actual recurring calendar reminder on it, with quarterly being a reasonable cadence for most businesses, to review what every agent in production can currently access, whether that still matches its actual job, and whether anything has silently expanded since the last review.
Build incident response specifically for agent failures. Have an actual plan, written down before you need it, for what happens when an agent does something wrong. That includes how to immediately revoke or pause its access, how to reconstruct exactly what happened from your logs, and how to figure out whether the failure was a one-off model error, a genuine security compromise, or a scoping mistake that needs to be permanently fixed.
Test adversarial, on purpose, before attackers do it for you. Deliberately test your agent yourself. Try prompt injection techniques against it, feed it deliberately manipulated documents and web content, attempt to get it to exceed its intended scope, and see what happens under conditions you control rather than find out for the first time in production.
Common Mistakes That Keep Showing Up
A handful of specific mistakes recur often enough, across genuinely different businesses and different tools, that they're worth calling out by name.
Confusing a capable model with a secure system is the most common one. Teams frequently assume that because the underlying model is sophisticated and generally well behaved, the system built around it is automatically safe. Model quality and system security are related but genuinely separate concerns. A brilliant model wired into an overly broad set of tools with no approval gates is still an unsafe system, no matter how good its individual responses look in a demo.
Granting access based on convenience rather than necessity is nearly universal in early deployments. It's simply easier, in the moment, to give an agent broad access once rather than carefully scoping and re-scoping it as its job evolves. That convenience is exactly what turns a narrow tool into a wide-open liability a few months later, once nobody quite remembers why access is that broad in the first place.
Treating security as a one-time setup step instead of an ongoing practice is another recurring failure. An agent's configuration, the tools available to it, the content it's exposed to, and the threat landscape around all of it keep changing continuously. A security review done once at launch and never revisited is a snapshot of a moment that stopped being accurate the first time anything about the deployment changed.
Skipping shadow mode because early results look good is a mistake driven entirely by impatience, and it's an understandable one, since momentum feels good and a cautious rollout feels slow by comparison. But early success in easy cases is exactly the kind of evidence that creates false confidence right before an edge case exposes a gap nobody tested for.
Under resourcing the human review step is subtly self-defeating. Businesses deploy an agent specifically to save time, then don't allocate any of the time saved to reviewing what the agent produces, on the assumption the AI has it handled once it's live. Approval gates and audit logs only function as real safety mechanisms if a human is paying attention when they're triggered.
And finally, staying silent with the team deploying and living alongside these agents’ day to day causes more slow-motion damage than most people expect. Employees who discover an agent are now quietly doing part of what used to be their job, with no explanation of what it's for, how it's supervised, or what's expected of them going forward, tend to either resist it quietly or stop trusting its output entirely.
What a Genuinely Secure Agent Platform Should Offer
If you're evaluating a platform rather than building agent infrastructure entirely in house, a few specific things separate the options built with security taken seriously from the ones where it's mostly a line in the marketing copy.
Look for a real, visible approval mechanism, not just a claim of human oversight somewhere in the feature list. You should be able to see an actual interactive approval queue, understand exactly what triggers it, and confirm that consequential actions genuinely stop and wait for a human decision rather than proceeding by default.
Look for granular, specific permission controls, not an all or nothing switch. You should be able to scope exactly which tools, which data, and which systems any individual agent can reach, and adjust that scope narrowly as need change.
Look for comprehensive, exportable audit logging as a built-in feature, not an afterthought bolted on after a customer specifically asked for it. Every action, every tool call, and every decision an agent makes should be re-constructable after the fact, in a format your own team can review.
Look for a clear, honest answer about data handling. Is your business data used to train underlying models. Is there a defined data residency and retention policy you can read. Is the platform's security posture independently verified instead of something you're simply asked to take on faith.
And look for a platform that treats the distinction between advisory assistants and action taking agents as a first-class design decision, not marketing language applied after the fact. A platform that's thought carefully about where autonomy should stop and human judgment should start is a platform that's very likely to think carefully about security more broadly too.
Where This Is Heading
AI agent security is still a genuinely young field, and it's evolving fast in both directions at once. Attack techniques are getting more sophisticated as more of the world's most capable red teamers turn their attention specifically toward agentic systems rather than traditional software. Defensive tooling is catching up too, with better methods for separating instructions from data, more mature sandboxing and isolation techniques for agent execution environments, and increasingly standardized approaches to approval workflows and audit logging that are starting to look less like bespoke engineering and more like expected baseline infrastructure.
Regulation is very likely to come, in some form, as agentic AI touches more consequential business decisions and more regulators start paying closer attention to exactly what autonomous means in practice when something goes wrong. Businesses that build genuinely careful security practices now, with proper scoping, real approval gates, and honest audit trails, won't just be avoiding today's threats. They'll likely be ahead of whatever compliance expectations eventually get formalized around this category of software, rather than scrambling to retrofit them under deadline pressure later.
The businesses that get real, lasting value from agentic AI over the next few years won't be the ones that deployed the fastest or gave their agents the widest possible access to look impressive in a demo. They'll be the ones that took the threat model seriously from the very first deployment, built the approval gates and the audit trails before they needed them rather than after an incident forced the issue, and treated agent security as core infrastructure rather than an afterthought bolted on once something already went wrong.
Bringing It All Together
AI agent security isn't a technical concern for a security team to handle quietly in the background while everyone else focuses on what agents can do. It's a foundational part of what makes agentic AI usable at all, in the same way that basic application security is foundational to any piece of software that touches real users and real data, not an optional extra layered on afterward for the security conscious.
The threats are real and specific, not hypothetical. Prompt injection hijacks an agent's reasoning. Excessive access turns a small mistake into a large one. Tool misuse turns a reasoning error into a real-world action. Data leakage exposes what should have stayed private. Memory poisoning corrupts an agent's judgment slowly and silently. Supply chain risk comes from the third-party tools an agent depends on. And there's the compounding risk that shows up specifically once multiple agents start handing work off to each other. None of these are reasons to avoid deploying agents. They're the specific, nameable reasons to deploy them carefully, with the same rigor any serious piece of business infrastructure deserves.
The practical answer isn't complicated, even if it takes real discipline to maintain. Scope access tightly and revisit that scope regularly. Put a genuine, actively monitored human approval gate on anything that leaves the system and touches the real world. Treating every piece of external content an agent reads as potentially adversarial, by default, rather than assuming good faith. Log everything and make sure those logs are something a human can use when it matters. Test the system adversarial before an actual attacker does it for you.
Get that foundation right, and AI agent security stops being a source of quiet, background anxiety every time someone proposes expanding what an agent can touch. It becomes exactly what it should be: the reason you can confidently say yes to giving agents more real work to do, because you already know precisely what happens if one of them ever gets something wrong, and you built the system specifically so that a single mistake stays small, visible, and recoverable, instead of quietly becoming a very expensive and very public lesson.