Securing Agentic AI: 5 Practices Every Security Team Should Adopt Now
Last week we looked at why indirect prompt injection has become one of the most pressing risks facing security teams in 2026, ranked as OWASP’s number one risk for LLM and generative AI applications, and already tied to confirmed incidents involving data exfiltration, unauthorized payments, and even remote code execution. The natural next question is what to actually do about it.
The good news is that this is not an unsolvable problem. It is a new one, and it requires a different mindset than traditional application security, but there is a growing body of concrete guidance from organizations like OWASP and OpenAI on how to build and operate AI agents that hold up under attack. Here are five practices worth putting in place now.
1. Map the blast radius of every agent before it ships
Researcher Simon Willison has described a pattern he calls the “lethal trifecta,” and it is a useful lens for any security team evaluating AI agents. An agent becomes genuinely dangerous when it combines three things at once: access to private data, exposure to untrusted external content such as emails or web pages, and the ability to communicate outward, whether that means sending data, calling an API, or rendering a link. Any one of these on its own is manageable. All three together mean an attacker who can plant instructions in content your agent reads may be able to walk out the door with whatever that agent can see.
Before any agent goes into production, ask a simple question: does it have all three of these capabilities? If it does, treat it as a high risk system that needs the controls below, not a standard application that gets a routine review and moves on.
2. Apply least privilege to what agents can actually do
Give agents their own scoped credentials rather than broad access to the systems they touch, and put real limits on high impact actions like payments, deletions, and code execution. Think about it the way you would think about a new employee. A human customer service representative typically has a refund cap and needs sign off for anything larger. Your AI agents deserve the same discipline. If an agent does not need the ability to delete records or move money, it should not have that ability, full stop.
3. Keep untrusted content out of the instruction channel
A significant share of real world prompt injection attacks work because there is no clear boundary between what a system was told to do and what it happens to read while doing it. Architect your prompts so that external content, web pages, documents, emails, log data, is clearly segregated from system level instructions, and layer input and output filtering on top of that separation rather than relying on filtering alone. Filtering catches known patterns. Structural separation is what protects you against the ones nobody has seen yet.
4. Require human approval for privileged or irreversible actions
Any action with real financial, operational, or data loss consequences should have a human in the loop before it executes. This is not about slowing your teams down across the board. It is about being deliberate regarding which actions are allowed to run autonomously and which ones deserve a second set of eyes, the same distinction you would already make for a wire transfer request or a production database change.
5. Test continuously, and treat the model as an untrusted user
This is the practice most organizations are still missing, and it is the one that matters most. Standard vulnerability scanning and code review will not catch prompt injection, because the flaw lives in how a system processes content, not in a piece of code with a known signature. That is precisely why prompt injection can rank as the number one concern among security experts while showing up far less often in traditional incident and vulnerability records: the tools most programs already rely on were never built to see it.
The only reliable way to know whether your agents actually hold up is to test them the way an attacker would, treating the model itself as an untrusted party and probing the tool integrations, permissions, and data access behind it, not just the model’s responses in isolation. This is exactly where dedicated AI and LLM penetration testing earns its keep. Orenda’s generative AI and LLM security testing is built around this exact threat model, evaluating how an agent behaves when it encounters manipulated content and where its permissions and tool integrations could be abused. Paired with red team engagements and continuous vulnerability management, it gives you a real answer, grounded in evidence rather than assumption, to the question every CISO deploying AI agents should be asking: if someone tried this against us today, would it work?
The bottom line
None of these five practices require you to slow down your AI initiatives. They require you to build with the same discipline you already apply to your networks, applications, and cloud environments: know what you are exposing, limit what can go wrong, and test it regularly against real attack techniques rather than assuming it is fine because nothing has broken yet.
