John Burke, CTO and research analyst at Nemertes Research, published a piece in TechTarget's Search Security on June 25 laying out what CISOs need to know about AI runtime security. The argument is direct. CISOs recognize the cybersecurity implications of AI, but most are still focused on preventing AI-enabled data loss and compliance breaches. Few have turned their attention to the broader runtime threat surface that AI agents create once they start reasoning, choosing tools, and chaining actions across systems most security teams never designed those systems to be touched by.
One line in the piece carries more weight than the rest: a subverted AI can damage the enterprise in proportion to how much it is trusted and by whom. That sentence is more useful than most of what gets written about prompt injection or data leakage, because it forces a CISO to think about blast radius and trust boundaries rather than just input filtering. Burke's framing is correct. The four zero-trust principles he lays out are real controls, not theoretical ones, and the piece works as a solid primer for any security team that hasn't yet mapped its AI runtime risk.
Two questions are left open. Which of the four controls should an organization build first when it's starting from nothing? And what regulatory exposure remains once all four are running exactly as designed? Those are the two gaps this piece tries to close.
What Burke Stated
Burke's strongest contribution is the comparison he draws between AI agents and employees rather than applications. Traditional security models assume software does only what a developer coded it to do. Burke points out that AI agents reason, select tools, chain actions together, and produce different outcomes depending on context and the permissions available to them at the time. That single distinction resets how a CISO should be scoping the threat. You don't run a vulnerability scan against an employee. You manage what they're authorized to access, you watch how they behave once they have it, and you assume the relationship can go wrong even when nothing in the hiring process flagged a problem.
The four scenarios Burke walks through aren't hypothetical. An analytic AI helping staff troubleshoot a network problem can just as easily hand an external attacker the compromise intelligence it gathered along the way. An agent with the ability to change network device configurations can open holes for attackers the same way it closes them for legitimate users. An AI application with no vetting on its inputs or outputs can be fed a prompt carrying hidden instructions to exfiltrate data, and most employees have no instinct to question a tool that's supposed to be helping them. Each of these has already shown up in production environments, not in a research lab.
Burke's read on the tooling gap is also accurate. Static code scanners and software composition analyzers were built to catch known vulnerability patterns in source code. They have no concept of a corrupted prompt file or a malicious skill definition, because those artifacts didn't exist when the scanners were designed. Web application firewalls were built to block malicious HTTP traffic, not to recognize that a perfectly formatted request is carrying an instruction designed to make an AI system misbehave. Burke's closing point lands hardest: attackers have access to the same AI capabilities defenders do, and they're already using it to find new ways into AI tooling. That arms-race dimension hasn't fully entered most enterprise threat models yet.
What's Missing From His Argument
Burke lists four zero-trust principles side by side, as if a CISO could pick any one of them to start with. The principles aren't independent. They depend on each other in a specific order, and getting that order wrong produces security theater rather than security.
31% Organizations that can't determine whether they've experienced an AI breach in the past 12 months. HiddenLayer, 2026.
73% Default AI execution roles that remain inactive — permissions provisioned and never reviewed. Tenable, 2026.
Discovery comes first.
Every one of Burke's four zero-trust principles assumes the organization already knows which AI systems and agents exist and what each one can reach. Most organizations don't have that inventory. HiddenLayer found that 31% of organizations can't determine whether they've experienced an AI-related breach in the past year, and that's not a detection failure so much as an inventory failure. You cannot apply a zero-trust boundary to an agent that has no entry in any registry, because nobody has decided what that boundary should be.
Identity and access governance comes second.
Burke is right that identity belongs at the center of zero-trust for AI. But scoping permissions and enforcing least privilege requires the inventory from step one to already exist. Tenable found that 73% of default AI execution roles remain inactive, meaning permissions were provisioned at deployment and never reviewed again. That's what happens when a team tries to govern access without first knowing the full list of things that need governing.
Runtime enforcement comes third.
Only once an organization knows which agents exist and what they're authorized to do can it write runtime rules that correctly separate normal behavior from an attack. Enforcement deployed ahead of inventory and identity work produces false positives on legitimate agent activity and blind spots around every agent nobody knew was running. The order isn't a suggestion. It's structural.
Stopping the Attack and Proving You Stopped It Are Different Problems
Burke's four principles, applied correctly and in the right order, produce a security program that can detect and block a malicious AI action in real time. None of that automatically produces the evidence a regulator asks for during an examination. Those are two different infrastructure problems, and most runtime security conversations only address the first one.
The clearest example of this gap sits inside the Federal Reserve's own April 2026 guidance. SR 26-2, which replaced the fifteen-year-old SR 11-7 framework for model risk management, explicitly carves generative AI and agentic AI models out of its formal scope, calling them too novel and rapidly evolving to bring under the existing rules. That sounds like a pass for banks running AI agents. It isn't. The same guidance instructs banking organizations to apply their own existing risk management and governance practices to determine appropriate controls for any system the formal rules don't cover. Regulators didn't write the agentic AI rulebook yet. They told every bank running agents to write its own and be ready to defend it.
"The Fed didn't say agents are unregulated. It said the opposite. The footnote instructs banks to apply their own risk management and governance practices to any system the framework doesn't cover."
Cutover, "SR 26-2 & Agentic AI: Navigating the Fed Model Risk Guidance," April 2026
That's the audit gap in plain terms. A runtime control that blocks a malicious prompt produces a security event. Whether that event lands in a tamper-resistant log, gets tied to the specific agent and policy involved, and gets packaged into a record that answers a specific examiner question is a separate piece of infrastructure that Burke's zero-trust framework doesn't build on its own. The EU AI Act imposes its own continuous risk management and post-market monitoring obligations on high-risk AI systems, and Texas's TRAIGA and Colorado's SB 205 both require documented assessment processes rather than a description of controls an organization believes are in place. Across every one of these frameworks, the requirement is the same: show your work.
Coupang is the clearest recent illustration of what happens when that work doesn't exist. The breach that cost the company $409 million wasn't caught by any internal system. A regulator found it during an investigation. The size of the fine reflected not just the exposure of 33.7 million customer records but the absence of any governance infrastructure that would have surfaced the problem before an examiner had to.
An organization that builds Burke's four zero-trust controls and stops there will keep attackers out. It will still walk into a regulatory examination with nothing to show beyond "we believe our controls were working." That sentence has never satisfied an examiner, and it isn't going to start now.
Our Take
The AI Security Take
Burke's piece does something most security writing on this topic doesn't: it tells CISOs to stop thinking about AI as software and start thinking about it as an entity capable of independent, consequential action. That reframe matters, and it's why the piece is worth reading in full. Most enterprise AI security programs are still built around the controls that made sense for the first wave of generative AI deployment — prompt filtering, output checks, basic data loss prevention. Runtime security is the conversation those programs haven't had yet.
The two pieces missing from the conversation are sequence and evidence. An organization that deploys zero-trust enforcement before completing discovery will have strong walls around the agents it already knows about and nothing around the ones it doesn't. An organization that builds enforcement without building the audit layer alongside it will stop attackers and still have nothing to show a regulator who wants proof rather than assurance.
Those two layers aren't separate projects competing for the same budget. They're the same program looked at from two directions. Security teams need to stop the bad action. Legal and risk teams need to prove it was stopped, on a specific date, under a specific policy, for a specific system. The infrastructure that produces that proof is what determines whether an AI security program holds up in front of an attacker and an examiner equally well.
