Picture a coding agent your engineering team quietly stood up three months ago. It has read access to your internal code repositories, it pulls in documentation from public sources to answer developer questions, and when it finds something relevant, it can commit changes and open tickets in your project management system. Nobody in security approved it and nobody in procurement reviewed it. It just works, so it stayed.
Now imagine a single malicious document, somewhere in that documentation pipeline, carrying instructions the agent dutifully executes: exfiltrate credentials, open an outbound connection, modify a deployment script.
That scenario isn’t hypothetical. According to preliminary findings from a June 2026 AI Risk Quadrant (AIRQ) assessment of 100 production AI agents, what you were just imaging describes the architectural reality for the vast majority of agents running in enterprise environments today.
A lethal trifecta is already in your environment
The AIRQ assessment (an early-stage evaluation rather than a certified benchmark) identified a ‘lethal trifecta’ common across the agents they examined. Agents had private data access, opened up points of exposure to untrusted content, and had the ability to take outbound actions.
These characteristics remind me of the fire triangle you learn in Boy Scouts. Just as heat, fuel and oxygen are not problematically dangerous in isolation, so any one of those three characteristics, in isolation, is manageable. But together, they create a condition that can quickly run out of control. With all three of these characteristics in place, a single bad (hostile) document or prompt injection in the wild can effectively commandeer an agent’s capabilities and drive dangerous organizational outcomes. The agent doesn’t need to be breached in the traditional sense. It needs only to do exactly what it was designed to do… with bad inputs.
The assessment’s preliminary figures suggest only around 11% of the agents evaluated landed in the category that the researchers call the ‘fortified leaders’. This is the label given to agents that possess meaningful defenses across all three dimensions. These may not be peer-reviewed statistics (the methodology hasn’t yet been independently validated at scale), but they are signals worth taking seriously. The underlying architectural pattern they describe is completely consistent with those we hear reported to us by security teams in every conversation.
Coding agents and computer-use agents ranked worst across all three risk dimensions: They have the broadest attack surface, the largest blast radius, and the weakest defensive controls. Unfortunately, these are also among the most capable and most rapidly adopted agent types in enterprise environments right now.
While AIRQ’s trifecta paints a usefully clear picture of the risk, it misses another important dimension in pointing out that the risk is not static. Over time, agents accumulate permissions through inheritance, integration, and convenience, often called authority driftAuthority drift expands the risks of the lethal trifecta every day they are left unmanaged.
Policy without enforcement doesn’t touch architectural risk
The instinct for many security teams, when faced with a finding like this, is to reach for governance: publish an AI usage policy, require security review before deployment, add agents to the software procurement process.
Those are the right instincts. But on their own they’re not really worth the paper the processes are written on.
The agents captured in this assessment were architecturally exposed, not simply a danger because of careless use or something that can be mitigated through policy and process. They had capabilities that, by design, could be turned against the organization if the right malicious input reached them. A policy that says ‘agents must not exfiltrate sensitive data’ doesn’t change what happens when an agent with data access and outbound action capability processes a document carrying a well-crafted malicious prompt injection.
Securing access to an agent isn’t the same as securing what the agent does. The gap between policy intent and actual enforcement is where agentic AI risk lives, and it’s a gap that’s widening, not narrowing as agents are increasingly being deployed by teams who see them as handy productivity tools rather than powerful systems that warrant security review. The AIRQ report describes “bottom-up adoption that bypasses procurement gates”, and security teams we talk to describe the dynamic in almost identical terms.
Visibility has to come before control
Before you can enforce anything, you need to see what’s running.
This is where most organizations are genuinely behind. Shadow AI (AI tools and agents deployed outside formal review processes) is a category of exposure that grows every time a developer spins up an agent using a personal API key, or a business team connects an AI workflow directly to a SaaS application without going through IT.
Discovering those agents isn’t a one-time audit task. It requires inline visibility into what’s actually moving across your network and between your cloud applications; what data AI systems are touching; what they’re sending outbound; and whether those systems were ever introduced to a security team at all.
Netskope’s shadow AI discovery capability is built specifically for this: finding agents and AI applications that bypassed procurement, so security teams can make an informed decision about whether to sanction, constrain, or shut them down. You can’t enforce least-privilege access on an agent you don’t know exists.
Constraining the blast radius
For the agents you do know about (and for new deployments going through proper review) the architectural exposure the AIRQ assessment describes points to two principles that should govern how AI agents are provisioned.
The first is least-privilege access. An agent should have access only to the data it needs to complete its defined task, and nothing more. That sounds straightforward but in practice agents are often provisioned with broad access because it’s easier to set up that way, and nobody revisits it later. Enforcing least-privilege for agentic workloads requires the same zero trust access controls that apply to human users. This means agentic AI systems should be treated as principals in your identity and access architecture, not exempted from it.
Netskope’s ZTNA capabilities extend that model to AI agents so that access decisions are made continuously based on context, not granted once at provisioning and forgotten.
The reason Netskope can apply ZTNA to agents and inspect their outbound actions inline isn’t a recent product addition, it’s the architecture the platform was built on. Netskope was born in 2012 and built for the cloud era. Inline data security at scale, native understanding of the structured traffic AI generates, classification of data in motion as it crosses network boundaries –… these have been in the platform’s DNA since the beginning. AI confirmed that we built those foundations well. What other vendors are now assembling through acquisitions, we built.
The second principle is real-time inspection of outbound actions. When an AI agent sends data somewhere (for example to an external API, a messaging tool, or a cloud storage bucket) that action should be subject to the same DLP controls that apply to any outbound data movement. An agent exfiltrating sensitive data under instruction from a malicious prompt looks (in terms of network behavior) a lot like a human doing the same thing. Inline DLP that inspects those actions in real time, on infrastructure built to handle agent-volume traffic without becoming a chokepoint, closes the gap.
What should security teams do with this?
A finding like the AIRQ report can prompt two very different reactions. The first is to wait for more rigorous validation before acting. The second is to recognize that the architectural conditions the report describes (agents with broad data access, untrusted content exposure, and outbound action capability) are already present in most environments, regardless of what any single assessment concludes.
This is also a conversation that’s moved beyond the security team. Chief Risk Officers, Chief AI Officers, CIOs, and boards are all asking the same question from a different angle: Are we deploying AI safely, not just securely? Safety is a business outcome and security is the mechanism that produces it.
The question shouldn’t be whether the 11% figure will hold up under peer review. It’s whether you know, right now, which of your AI agents would survive the same evaluation. And whether you have the visibility and controls in place to do anything about the ones that wouldn’t.
