Amazon challenges human-in-the-loop AI governance as tech giants shift to accountability models

Why Amazon hates 'human-in-the-loop' AI governance

VP Eric Brandwine explains people aren't all that great, actually Humans tend to be "a little bit precious about humans," according to Eric Brandwine, distinguished engineer and VP at Amazon Security. We like to think we are all very good at our jobs, and we have high opinions of ourselves, he explained during a phone interview with The Register. "But when you actually get down to it, humans are not terribly consistent," Brandwine said. Humans, like AI agents and systems, are non-deterministic. Neither can be guaranteed to produce the same output given the same input twice. Both will make mistakes and even make stuff up. However, we've got millennia of experience dealing with humans and less than a decade with more modern LLMs and the AI systems built on top of them. "We know how humans fail," Brandwine said. "We're comfortable with it. So human-in-the-loop isn't necessarily the gold standard." For years, vendors have told companies that the solution for dealing with any automated system was to put a human in the loop. That battle cry became much louder with the advent of modern AI systems and reached a fever pitch when enterprises started deploying agents into their IT environments. More recently, however, big tech is changing the way it talks about agentic governance and rethinking the whole human-in-the-loop concept. Normalization of deviance In 2017, Brandwine gave a talk on the normalization of deviance at AWS' annual re:Invent conference. It's a gradual process that happens when people in an organization take shortcuts, or don't follow the established procedures or standards, and sometimes it occurs over years. As long as nothing catastrophic happens, this deviant behavior becomes the norm. "It's a thing all humans fall prey to, and one of the most heartbreaking stories I read in this area was about emergency departments and emergency rooms," Brandwine said during a phone interview with The Register. "You've got all these machines, and they're all beeping. Your first day on the job, you jump every single time one of the alarms beeps - but the patient is fine. It's a spurious alarm. You go back to your station, you sit down, and over time, after enough of these false alarms, enough of these repeated beeps with no actual consequence, your discipline slips, and you stop responding. And eventually some tragic outcome occurs." This, he admits, is a very high-stakes example. And yet it's a documented occurrence among healthcare workers, firefighters, and even Army pilots. "Literally, someone's life is on the line, and people still struggle to maintain discipline," Brandwine said. "That's the human condition." Here's how this all applies to agentic AI governance and security. Humans build LLMs and AI systems, and having a "human-in-the-loop" ensures that a person reviews the AI's output and approves (or not) any actions before the AI performs them. "If you put a human inside of this tight loop, and ask them to make approval decisions for agentic tools repeatedly, time after time, they'll do a good job," Brandwine said. "And then they'll do an okay job. And pretty quickly they'll be doing a poor job." This is why at Amazon, "we're not huge fans of human-in-the-loop," he added. "It's something that you should use judiciously, where you absolutely need it. But it's not something that you can do at high velocity. You will not get the results that you want to get." Big tech pulls the human-in-the-loop Amazon isn't the first or only tech giant to start talking differently about the role humans should play in agentic governance. "It is very clear that we have moved from a human-led defense strategy, to a human-in-the-loop defense strategy, to an AI-led defense strategy that's overseen by humans," Google Cloud chief operating officer Francis deSouza told reporters during a press conference ahead of Google's annual Cloud Next shindig in April. "Our model for the future is an agentic fleet that does a lot of the routine cyber security work at a machine pace and then is overseen by humans." Microsoft CEO Satya Nadella, in an X missive earlier this week, argued for "loop learning," instead of having a human check an AI's output at every step. "Companies need to turn their workflows, domain knowledge, and accumulated judgment into AI systems that improve with each use," Nadella wrote. "Private evals should capture whether a model is actually improving against outcomes that matter to the business (not just external benchmarks!). Private reinforcement learning environments should let models grow stronger on real traces from inside the organization." Also this week, IBM execs called for human accountability - not humans in the loop - at all stages of AI development, deployment, and governance. Amazon's alternative to human-in-the-loop is "accountability end to end," according to Brandwine. This means human identity and ownership track through the entire workflow, even when humans aren't directly approving every step. "If I sit down at my keyboard and I type a command that takes a service down, I caused an outage," Brandwine explained. "If I run a script that takes a service down, it's still me that caused the outage. If my agent writes a script that they then run, and it causes an outage, that's still my responsibility." (Secret) keys to the kingdom This also highlights the importance of managing and securing agentic identities - the accounts, tokens, and credentials assigned to AI agents so they can access corporate apps and data. At Amazon, all of the agents have independent identities assigned to them, we're told. "So, as we track agentic activity across our systems, it does not show up in the logs as: 'Eric did this.' It shows up as: 'this agent did this on behalf of Eric,'" Brandwine said, adding that this isn't to "make people afraid to use this technology." "It's to make people pause and think: is this the right way to use this technology? Is this how I should be deploying this?" We still have the humans involved, we still have the humans making decisions, but we're trying to play to the strengths of the humans rather than placing them in this unfair, repeated decision making, human-in-the-loop position." Brandwine told us that Amazon has run into a couple of hurdles when it comes to deploying agents across its businesses, and one of the biggest is what he calls "goal-seeking behavior." This is when a person asks an agent to do a specific task - for example, upgrade a database - and the agent becomes laser-focused on just one action to achieve this goal, ie, deleting the database. This is separate from prompt injection because there's no malicious input. "It's just the agent getting stuck on the wrong action," Brandwine said. Simply telling the agent, "you don't have permission to do this," is likely going to cause the agent to look for a different path to do the same thing (delete the database). Telling the agent why it doesn't have permission to do something tends to produce a better outcome, according to Brandwine. This means telling the agent it's not allowed to do that, and the reason why is because it would cause a production impact. And also include "don't cause a production impact" as part of the prompt. "Giving it that extra feedback has gotten us dramatically better results," Brandwine said. Of course, this is not a fail-proof method. "You still need to be careful with agents," Brandwine told us. "We have millennia of experience with humans. Agentic AI is a very, very new field, we don't have an intuition for this, and one of the fundamental differences between agents and humans is that humans fear consequences," such as losing a job or even going to jail. Agents don't have these fears. This is where setting permissions on what the agent can and can't do or access comes in. Much like everything else with AI, it's nuanced, and it depends on the employee's role in the company, and the company's tolerance for risk. "The person that wants to run the agent wants to give the agent many permissions because that makes the agent more powerful," Brandwine said. "It could do more things for them, it can recoup more of their time, it can deliver more." The security lead, on the other hand, wants to limit an agent's permissions, and this causes yet more tension between the security and development teams. There is no one right solution or policy answer to solve this, according to Brandwine. Instead, it involves dynamic policies that set permissions based on the agent's specific task. There are some overarching, static guardrails - such as an agent must never perform destructive actions or delete entire servers - and then there are policies underneath that establish the maximum set of privileges that the agent can have. "Then we'll have a further scoped-down policy for this action, and there's various techniques for automatically generating policies based on prompt and the end-user's intent," Brandwine said. Even for Amazon, it's not always easy. "It's all driven by risk," he said. "This is a space that's changing quickly, and so we're trying to balance the risk of using untried, untested software against the risk of falling behind and not being able to deliver for our customers. As with all such things, it's complicated." ®

Stop Your Legacy Infrastructure from Hijacking Your AI Agents

Earlier this month, I spoke at the Gartner Security & Risk Management Summit about a blind spot most security programs are still not accounting for - how attackers are circumventing AI security programs by using legacy infrastructure to hijack AI agents. AI adoption is moving faster than security programs can account for. Roughly 71% of organizations are piloting AI agents across their enterprise applications, and 31% have already moved them into production workflows. For this reason, organizations are legitimately pouring resources into securing AI workloads against model poisoning, prompt injection, data leakage, and other emerging threats. Yet this focus misses everything underneath the AI layer. Because an unpatched server, a misconfigured Active Directory permission, or a cached credential on a developer's machine are exposures that give attackers a direct route to everything your AI agents depend on - knowledge bases, cloud storage, Lambda functions, SaaS integrations, and the credentials that connect them. This means that threat actors don't really need to attack your AI head-on - they just need to reach what it connects to. In this article, I'll walk through how legacy infrastructure becomes the attack path into AI agent environments and what security teams can do to block those paths. AI Agents Use What They Inherit Despite their novelty and power, in some ways AI agents operate like other assets in your environment. They authenticate through existing identity providers, store data in existing cloud buckets, execute tasks through existing Lambda functions, and inherit permissions from existing IAM roles. Every one of those dependencies carries whatever security debt the organization had before the AI deployment started. What's more, most organizations are inadvertently compounding that debt. According to Infosecurity Magazine, 70% of organizations grant their AI systems more privileged access than a human in the same role. Not surprisingly, this comes with a painful price tag. Organizations with over-privileged AI reported a 76% incident rate, compared to just 17% for those enforcing least privilege. All of those connections - identity providers, cloud buckets, Lambda functions, IAM roles - run through the infrastructure your teams have managed for years: Active Directory, cloud IAM, service accounts, stored credentials. Yet none of it was designed with AI agents in mind, and most of it was provisioned long before the first agent went into production. The result is that an attacker who finds their way in through any of those layers doesn't need to touch the AI. The agent's own permissions do the work for them. How a CVE from 2025 Hijacks an AI Agent in 2026 The diagram below shows a typical enterprise AI agent architecture. A customer success team uses an AI-powered Co-Pilot - hosted on AWS Bedrock - to query customer data exported from Salesforce into an S3 bucket. The Co-Pilot executes tasks through Lambda functions and integrates with business applications. John, a developer, builds and maintains the agent. Users across the organization interact with it daily. Now here's what happens when an attacker finds a way in. The following diagram shows an attack path my team modeled in a real enterprise environment. None of these exposures are exotic - they exist, in some combination, in most enterprise networks right now. What makes them dangerous is how they connect. Here is how the attack developed, stage-by-stage. * Stage 1: An S3 bucket becomes a critical asset. To feed the CSM Co-Pilot, the team exported Salesforce data into an S3 bucket. That export turned the bucket into a high-value target holding sensitive customer records. Multiple users across the AWS account received overly broad read access to production S3 buckets - including John, the Co-Pilot developer, who never needed access to production data. On its own, this is a simple permissions misconfiguration. * Stage 2: An unpatched server on the perimeter. An external-facing server runs Apache Tomcat. That server is exposed to CVE-2025-24813 - a remote code execution flaw disclosed in March 2025 and added to CISA's Known Exploited Vulnerabilities catalog the same month. It was never patched. Because the server sits in the enterprise environment and is joined to Active Directory, an attacker who exploits the vulnerability can dump cached credentials from server memory and compromise an AD user account. In isolation, this is a known vulnerability on a single server - serious, but not critical. * Stage 3: Active Directory misconfiguration enables lateral movement. That compromised AD account can abuse a Resource-Based Constrained Delegation misconfiguration to impersonate John and access his workstation. John uses AWS CLI to manage the Co-Pilot's cloud resources, and behind the scenes, CLI stores AWS access keys on his machine. The attacker harvests those keys. In isolation, this is an AD permissions issue - one of thousands that most environments carry. * Now connect the three stages. The attacker exploits CVE-2025-24813 on the perimeter, dumps credentials, moves laterally through AD to John's workstation, harvests his AWS access keys, and reads every record in the production S3 bucket - the same bucket that feeds the Co-Pilot's knowledge base. The Co-Pilot agent is now compromised. The attacker controls what it reads, what it trusts, and what it returns to users. No part of the AI stack was directly attacked. Three moderate findings - an overprivileged cloud key, an unpatched web server, an AD misconfiguration - became one critical attack path. What to Do About It The attack path I just described crosses four layers: network, identity, cloud, and AI. Most security programs assess each of those layers independently, and the exposures in each one may already be known. An EASM tool flags the Tomcat server. An AD security tool catches the delegation misconfiguration. A CSPM tool picks up the overprivileged S3 access. Each one reports a moderate finding which may not be remediated due to lower priority but in combination become a critical issue: a Tomcat vulnerability on the perimeter chains through AD into a developer's cloud credentials and ends at an AI agent's knowledge base. Closing these paths starts with an exposure management approach that treats AI agent dependencies (knowledge bases, storage buckets, Lambda functions, etc) as critical assets themselves. From there, map backward: what identity relationships, permissions, and infrastructure connect to those assets, and which of those connections carry exploitable exposures in the context of your environment? When you map the full path, choke points emerge - places where a single fix will block multiple routes to your AI assets. If your exposure management platform can trace that full path - from legacy server through AD and cloud infrastructure to an AI agent's knowledge base - you can fix the exposure before an attacker chains it. If it can't, no amount of guardrails on the AI layer will close it. The Bottom Line AI agent adoption is accelerating across every enterprise department. And every new agent you deploy connects to infrastructure that is already exposed. That means that the attack surface compounds with every deployment. The question for security leaders isn't whether your AI layer is protected. It's whether the environment in which those agents operate - including your bread-and-butter legacy infrastructure - is handing attackers the path to hijack them. Because attackers don't need new techniques to compromise AI agents. They just need the old ones - and an environment that lets them use the old to exploit the new. Note: This article was thoughtfully written and contributed for our audience by Zur Ulianitzky, SVP Product and Security Research, XM Cyber.

Every AI Agent Is an Identity. Most Organizations Don't Treat Them That Way

For years, security teams built their programs around a simple premise of if you control the identities, you can control the risk. Employees authenticate through identity providers. Service accounts connect systems. API keys let workloads talk to cloud services and databases. The actors have been very predictable. And as a result, the identity security and governance model have followed that predictability. Now, this premise is breaking. AI agents entered the enterprise quietly, summarizing meetings, drafting emails, helping employees find information. Most security teams didn't think hard about them at first. They looked like productivity tools, because that is exactly what they were. Then, organizations started connecting them to critical business services such as Salesforce, Snowflake, GitHub, Jira, production databases, and cloud environments. Now, they retrieve information, trigger workflows, update records, write and deploy code, and take actions across multiple systems. Sometimes on the behalf of a human, sometimes autonomously, and sometimes in ways where it's genuinely unclear which. This makes AI agents more than just tools. It makes them identities and most enterprises have no security and governance models for them. The pattern is consistent across organizations. A new identity layer gets built on top of existing infrastructure with almost none of the controls that identity teams spent the last decade putting in place. An agent might be created by one team, used by another, connected to five different applications, and running on credentials that were provisioned for a completely different purpose. It got broad access early because someone needed it to work and didn't want to slow things down. The result is a sprawl of high-privilege, low-visibility actors that most security teams can't inventory, let alone govern. According to a 2026 CSA survey commissioned by us here at Token Security, 82% of organizations discovered at least one AI agent created without the knowledge of security, IT, or governance teams in the past year, and 41% found this happening multiple times. Here's where the security conversation has gone sideways. Most of the attention on AI security has landed on model risk, such as prompt injection, jailbreaks, unsafe outputs. While these are all an important part of the agentic AI ecosystem, they don't paint the complete picture enterprise security teams require. The most important piece they need must answer what can the agent actually access? An agent that summarizes public documentation has limited blast radius. An agent connected to customer records, source code, financial systems, and admin-level cloud credentials is a different problem entirely. A bad prompt, a compromised session, a malicious plugin, or a misconfigured integration can turn an overprivileged agent into a path for data exfiltration, destructive action, or lateral movement through systems that were never meant to be connected. This is no longer theoretical, 65% of organizations experienced a security incident involving an AI agent in the past year, with 61% reporting exposure or mishandling of sensitive data as a result (source). Getting control starts with visibility. Security teams need AI agent discovery and inventory that extends beyond just names and platforms to answer questions that actually matter. Who owns this agent? Who can invoke it? What systems is it connected to? What credentials does it use? What can it read, write, delete, or execute in each target application? This is harder than it sounds, because the surface isn't obvious. A security team might know a sales assistant exists in an AI platform without knowing it runs on a Snowflake service account with admin privileges. They might know a coding agent is installed on developer endpoints without knowing which secrets, repositories, and CI/CD pipelines it can reach. The agent itself is only part of the picture. Everything the agent's identities can touch is the actual exposure surface. The second piece is purpose. Security and governance can't be purely permission-based with AI agents. It has to account for the agent's intent. A sales prep agent only needs read access to CRM records. It doesn't need to delete database tables. A finance workflow agent should only read invoices. It shouldn't be able to create new privileged users. When you understand what an agent is supposed to do, you can evaluate whether its permissions match that scope. And, in practice today, they rarely do and that gap is where the real risk lives and it only widens over time through least privilege policy drift. Once intent is understood, enforcement becomes possible. Permissions can be trimmed to match the agent's actual purpose, overprivileged service accounts remediated, unused credentials rotated or removed, and risky connections caught before they turn into incidents. The part that trips up most teams is that none of this is a one-time exercise. An access review or an audit may feel like progress, but they just provide a point-in-time checkbox and a false sense of security. The reason is that agents change, instructions update, user bases shift, and integrations expand. An agent that started as a narrow internal tool can quietly end up connected to systems it was never designed to touch, not because anyone made a bad decision, but because nobody was watching when the scope crept. That's why governance needs to be continuous to catch agents that start accessing applications outside their normal pattern, use unexpected credentials, or take actions that don't fit their stated purpose. The enterprises that succeed with AI will not be the ones that block agents entirely. They will be the ones that make agents governable and promote secure AI innovation. This means treating them as first-class identities with owners, access, behavior, risk, and lifecycle controls. AI agents are becoming privileged insiders. Security and identity programs must now catch up before those insiders become invisible attack paths. We'd love to show you how we're tackling this at Token Security, book a demo to chat with our technical team so you can scale without sacrificing safety.

Amazon says human-in-the-loop AI oversight is failing because humans stop paying attention

Amazon's security VP says human-in-the-loop AI governance fails fast because people stop paying attention. Google, Microsoft, and IBM agree. Amazon's security leadership is arguing against one of the most widely accepted principles in AI governance. Eric Brandwine, VP and distinguished engineer at Amazon Security, told The Register that human-in-the-loop oversight is not the gold standard companies think it is. "Humans are not terribly consistent," Brandwine said. "Human-in-the-loop isn't necessarily the gold standard." His reasoning draws on a concept he has been talking about since at least 2017, when he gave a talk on normalization of deviance at AWS re:Invent. The term describes what happens when people in an organization take shortcuts over time, and nothing catastrophic results, so the deviant behavior becomes the new normal. Brandwine illustrated the point with emergency rooms. On a nurse's first day, every alarm triggers a response. After weeks of false alarms with no consequences, discipline erodes. Eventually, a real emergency is missed. "Literally, someone's life is on the line, and people still struggle to maintain discipline," Brandwine said. "That's the human condition." He applied the same logic to AI agent oversight. When a human is asked to approve or reject agentic actions repeatedly, performance degrades fast. "They'll do a good job," Brandwine said. "And then they'll do an okay job, and pretty quickly they'll be doing a poor job." Amazon is not alone in rethinking this. Google Cloud COO Francis deSouza said in April that the industry has moved "from a human-led defense strategy, to a human-in-the-loop defense strategy, to an AI-led defense strategy that's overseen by humans." Google's model is now an agentic fleet handling routine cybersecurity work at machine speed, with humans providing oversight rather than approving every action. Microsoft CEO Satya Nadella argued this week for "loop learning," where companies turn their workflows and accumulated judgment into AI systems that improve with each use, rather than inserting a human checkpoint at every step. IBM published a separate call for human accountability at all stages of AI development, not humans in the loop, warning that the latter amounts to "liability laundering." Amazon's alternative is what Brandwine calls "accountability end to end." Human identity and ownership track through the entire workflow, even when humans are not directly approving every step. If an agent writes and runs a script that causes an outage, the person who deployed the agent is still responsible. All agents at Amazon have independent identities assigned to them. Activity logs show "this agent did this on behalf of Eric," not "Eric did this." The distinction is designed to make people think about how they deploy AI, not to make them afraid of using it. The practical challenges are considerable. Brandwine described what he calls "goal-seeking behavior," where an agent asked to upgrade a database becomes fixated on a single destructive path, like deleting the database and recreating it. This is not prompt injection. There is no malicious input. The agent simply gets stuck on the wrong action. Telling the agent it lacks permission to delete the database does not help, because the agent looks for another path to the same goal. Recent research has shown that AI agents connected to real systems create attack surfaces that existing security tools do not cover, and agents often act on instructions they should refuse. What does work, according to Brandwine, is telling the agent why it cannot perform an action, explaining that it would cause a production impact, and including "don't cause a production impact" as part of the prompt. "Giving it that extra feedback has gotten us dramatically better results," he said. The permissions question is where the tension lands. Employees want powerful agents with broad access. Security teams want narrow permissions. The race to govern what AI agents can access inside enterprise systems has already triggered major acquisitions, with 1Password buying access-governance startup Apono for an estimated $250 million to $300 million earlier this month. Amazon's approach uses layered policies: static guardrails that prohibit destructive actions, a maximum privilege set for each agent, and dynamically scoped policies generated based on the specific task and user intent. None of it is foolproof. "We have millennia of experience with humans," Brandwine said. "Agentic AI is a very, very new field." The fundamental difference, he noted, is that humans fear consequences, like losing a job or going to jail. Agents do not have these fears, and attackers are already exploiting that gap. "It's all driven by risk," Brandwine said. "We're trying to balance the risk of using untried, untested software against the risk of falling behind and not being able to deliver for our customers."

Forget Data Leakage: Shadow AI's Real Threat Is Access Control

The first wave of enterprise AI concern was straightforward. It was simply employees pasting sensitive data into public AI tools. Security teams responded with usage policies, domain blocks, and data loss prevention rules. That response made sense at the time. It doesn't fit the problem anymore. Shadow AI has shifted from a data leakage concern to an access control problem. The threat isn't about what employees type into AI tools. It's about which AI agents are running inside the organization, what enterprise systems they're connected to, and what actions they're authorized,or not, to take. From passive tools to active actors Employees and business units are building AI agents at a pace most security teams can't keep track of. Custom assistants, coding agents, workflow automations, and agentic applications are being created across departments with some in sanctioned platforms, but many through browser extensions, SaaS-native features, developer tools, MCP servers, endpoint-based agents, and custom scripts. Many start as quick experiments. Some become embedded in critical business processes within days. The risk profile of these agents is fundamentally different from traditional shadow IT. An unsanctioned SaaS application is a destination for data. An AI agent is an actor that can call APIs, use stored credentials, retrieve records, modify configurations, trigger downstream workflows, and take actions in production systems, often without a human explicitly authorizing each step. An employee pasting a customer record into a public AI tool is a data leakage incident. A custom AI agent connected to Salesforce, Snowflake, GitHub, Gong, and Slack is an access control incident waiting to happen. It could expose data, but it could also perform read, write, and delete actions on that data. It may also run on service accounts with permissions nobody audited and stay active six months after the employee who built it changed roles or left the company. New research from Token Security and the Cloud Security Alliance maps exactly how widespread this exposure has become. Why existing controls don't reach it Most enterprise security controls were designed for human identities and deterministic workloads. IAM policies, DLP rules, and network monitoring assume predictable behavior and defined access paths. AI agents break those assumptions. An agent tasked with resolving a failed deployment might read logs, query monitoring systems, modify infrastructure configurations, open tickets, trigger automation pipelines, and notify engineering teams, all in sequence, all using the same inherited credentials. To avoid breaking workflows, developers grant broad permissions upfront. Those permissions accumulate. Agents inherit creator-level privileges, temporary access becomes permanent, and security and identity teams lose visibility into what those identities are actually doing. Blocking public AI domains doesn't reach any of this. By the time an agent has credentials to enterprise systems, the boundary has already been crossed. Automated remediation of non-human identities is where that gap gets closed. What a real shadow AI inventory looks like Discovering shadow AI requires looking across the environments where agents actually live, such as AI platforms, SaaS apps with built-in automation, cloud accounts, developer tools, endpoints, and identity providers. Here are six questions to define whether security teams have real control. The maturity curve to ensure agentic AI security Most organizations are at the beginning of this and have little to no agent inventory. The next step is to gain partial visibility to know which agents exist, even without full context. After that they need enrichment and context to understand intent and map ownership, access, and credentials to each agent. The next step is to apply enforcement with automated controls that remediate excessive permissions, notify owners of inactive agents, and flag new agents connecting to sensitive systems. The goal isn't to block AI adoption. Teams are under real pressure to use these tools, and many of the productivity gains are legitimate. If security becomes a hard blocker, usage moves further underground and unseen. The better outcome is governed enablement to provide a path for teams to deploy agents with automated controls running continuously in the background. This requires treating AI agents the same way you'd treat any other identity in the enterprise with continuous discovery, defined ownership, scoped access, and lifecycle management from creation through decommissioning. The shadow AI question has changed. It's no longer: what data are employees putting into AI? It's now: which agents are operating in our environment and what did we give them access to? Those are different questions. The second one is the one that defines an organization's exposure and risk. If you're working through that inventory now, it's worth seeing how others are approaching it.

Agentic AI's crossroads: guardrails or massive fails

Autonomy scales risk; build real-time guardrails now or invite disaster Enterprises are deploying agentic AI at a pace that has outrun their ability to govern it. Gartner predicts the average Fortune 500 enterprise will have over 150,000 agents in production by 2028, up from fewer than 15 in 2025. Yet only 13% of organizations think they have the right governance in place to manage them. The result is an execution gap: agents deployed in isolation, producing outputs nobody acts on, automating tasks rather than business processes and delivering unclear business value as a consequence. Governance failures are an execution problem. Agents that can't interface safely with enterprise systems can't automate business processes in any meaningful way. They stay isolated helpers: producing artifacts, fielding customer queries, handling individual tasks. The execution gap -- the distance between what agentic AI promises and what it actually delivers inside the enterprise -- remains largely unaddressed. In 2026 and beyond, the guardrail problem poses an existential risk for enterprises. Adoption has outpaced controls, meaning that agentic AI is scaling faster than robust security measures can be implemented. The speed of tech progress The speed of tech progress can no longer stand as a rationalization for falling behind, and enterprises must address it before agentic becomes uncontrollable. Getting guardrails right will separate enterprises that realize full autonomy from those that stall out in pilots. First, autonomy amplifies risk. Just because agentic AI can act on its own doesn't mean it requires zero human oversight. Autonomy does not equal autopilot. For agentic AI to generate real ROI, agents must do more than reason and respond. They must execute inside the business. That means interfacing directly with enterprise systems: ERP software, finance platforms, supply chain tools and the workflows that run the organization. Without that integration, agents remain one step removed from the work that actually matters. Operational speed can compromise safety, compliance and reliability. Agents work at a blazing clip and on a more granular level than RPA. But speed becomes a moot point if agentic adoption leads to vulnerabilities such as sensitive data exposure. Security and IT teams haven't universally adapted to the new risk landscape. Among the risks agentic poses, "shadow AI" has emerged as a consequence of employees using unauthorized, unsanctioned AI tools or applications. When proper IT oversight or approval gets bypassed, it sets the stage for noncompliance and severe reputational damage. Departmental AI agents are proliferating without central oversight, creating security hazards and fragmented intelligence. Governance lags far behind adoption. In this case, the guardrail gap might as well be a lack. Surveying more than 3,000 IT and business leaders worldwide, Deloitte found that just one in five enterprises reported mature governance to manage the risks of agentic AI. Autonomy without governance is a liability. This is particularly critical as we move toward the era of programmable finance, with Gartner predicting that 20% of monetary transactions will be programmable by 2030. How to Lay the Rails Right Agentic systems perform across a wide range of functions. When building guardrails, there must be no shortcuts. Guardrails bolted on after the fact can't account for the ways agents actually fail: corrupting data, contradicting decisions made elsewhere in the business and creating conflicts between teams acting on different outputs. Controls need to be built into how agents execute, instead of layered on top. 1. Practice measured orchestration When enterprises accelerate AI adoption by stitching isolated tools across departments, security gaps grow harder to manage -- because there's no unified layer to anchor guardrails to. Start by scoping the broader business objective your agentic system needs to serve, not just the task. Once you've determined what your agentic system will handle and which structured outputs will return to the workflow, built-in validation and guardrails become platform-level capabilities rather than afterthoughts bolted onto each individual agent. 2. Build governance capabilities Without clear boundaries, agentic AI collapses. First, determine which decisions it can make independently versus those that need human approval. Real-time monitoring systems that flag anomalies and audit trails that capture the full chain of agent actions will enable accountability and continuous improvement. 3. Scale deliberately No matter how sexy the pilot, agentic AI needs time to mature within the enterprise; you want to spot potential issues before they appear, not after. Start with lower-risk use cases and easy, single-task wins, as with fraud detection and remediation or vendor reconciliation. Avoid intricate processes with hundreds or thousands of inputs, such as the financial close of a business. 4. Guardrail gap = skills gap While agentic AI excels at reasoning, the execution of reliable, repeatable business processes still demands deterministic systems -- and human oversight to bridge the two. To ensure smooth agentic operation in an enterprise, train your employees to move from triage, menial activities and repeated manual steps to judgment, governance and strategic decision-making roles. They absolutely require those skills. Scrum and Tiger teams can solve early problems and address early lessons, then pinpoint how agentic addresses your needs. Putting it All Together: A Guiding Guardrail Principle Yes, agentic AI scales productivity, but without strong guardrails, agentic AI scales risk even faster. Strategic observability and deterministic guardrails are required to ensure that non-deterministic AI stays compliant with regulatory and business standards, with reliable audit trails as well as rules for exactly when to escalate a decision or task to a human for complex exceptions or strategic oversight. In the rush to embrace agentic, remember that the attendant tasks don't represent a series of punch-list items. Veterans of software adoption and replacement projects know that it's a holistic process where human actions and digital components fall into place with methodical synchrony. Agentic AI, while it has altered the face of enterprise technology forever, rewards the same discipline every transformative technology before it has: lay the foundations carefully, and you won't be fighting fires when it scales. We list the best IT automation software. This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

AI agent framework flaws hit 7,000 servers | VentureBeat

Your AI agent did exactly what it was designed to do. The framework underneath it just handed an attacker a shell on the box that holds your OpenAI key, your database credentials, and your CRM tokens. That is not a hypothetical. In a few months, three of the most widely deployed AI agent frameworks each turned a known, ordinary bug class into a way through. Check Point Research chained a SQL injection in LangGraph's SQLite checkpointer to full remote code execution. Tenable and VulnCheck tracked a path traversal in Langflow's file upload endpoint to active, in-the-wild RCE. Cyera documented a path traversal in LangChain-core's prompt loader that reads your secrets off disk. Two paths to a shell, one to your keys. They are the same bug, wearing three frameworks. These frameworks became production infrastructure faster than anyone secured them. They store agent state, take file uploads, load prompt configs, and hold the credentials to databases, CRMs, and internal APIs. The edge tools watch traffic. The endpoint tools watch processes. Neither was built to treat an imported framework as a boundary worth guarding, and that blind spot is exactly where all three chains live, widening every week as these frameworks ship to production. The LangGraph chain, SQL injection to a Python shell Start with the one most teams pulled into production this quarter. LangGraph gives AI agents memory through checkpointers, the persistence layer that stores execution state. It has cleared over 50 million downloads a month. Yarden Porat of Check Point Research took that layer apart and found three vulnerabilities. Two of them chain to RCE. CVE-2025-67644, rated CVSS 7.3, is a SQL injection in the SQLite checkpointer. The function that builds the WHERE clause for checkpoint lookups drops user-controlled filter keys straight into the query with no parameterization and no escaping. This does not hit everyone, but where it hits, it is serious. A deployment is exposed when it self-hosts LangGraph on the SQLite or Redis checkpointer and lets untrusted input reach get_state_history() or a similar history endpoint. Meet those conditions, and an attacker who controls the filter writes a fabricated row straight into the checkpoint table. Run LangChain's managed LangSmith platform on PostgreSQL, and the exposure is gone. Then CVE-2026-28277, CVSS 6.8, finishes the job. LangGraph's msgpack checkpoint decoder rebuilds Python objects from the stored data, which lets it import a module and call a named function with attacker-supplied arguments. That step needs write access to the checkpoint store; the SQL injection is what grants it remotely. LangGraph loads the forged row as a legitimate checkpoint, the decoder runs the specified function, including os.system, and code executes under the identity of the agent server. A third issue, CVE-2026-27022, CVSS 6.5, reaches the same place through the Redis checkpointer. There has been no confirmed exploitation in the wild yet. A working proof-of-concept is public in Check Point's disclosure. The fixes are version bumps: langgraph-checkpoint-sqlite to 3.0.1, langgraph to 1.0.10, and langgraph-checkpoint-redis to 1.0.2. The Langflow chain, one unauthenticated request to RCE Langflow is the one already under attack. CVE-2026-5027, CVSS 8.8, is a path traversal in the POST /api/v2/files endpoint, which takes the filename straight from the form data and writes it to disk unsanitized. An attacker packs that filename with traversal sequences and drops a file anywhere, such as a cron job in /etc/cron.d/. Because Langflow ships with auto-login enabled in its default configuration, an exposed instance needs no credentials at all. A single unauthenticated request reaches the endpoint, and the next cron run hands over a shell. VulnCheck's Caitlin Condon confirmed exploitation on June 9: "Our Canaries observed exploitation of CVE-2026-5027 that successfully leveraged the path traversal to write what appear to be test files on victim systems." Censys put roughly 7,000 exposed instances on the internet, most in North America. This is the third Langflow flaw to draw active exploitation this year, after CVE-2025-34291, which the Iranian state-sponsored group MuddyWater weaponized and which CISA added to its Known Exploited Vulnerabilities catalog in May. CVE-2026-5027 itself was patched in version 1.9.0, released April 15. The timeline is what sets the clock. The patch shipped April 15. Attacks started in June, and VulnCheck added CVE-2026-5027 to its exploited-vulnerabilities list June 8 once its sensors caught the first in-the-wild hits. Every instance left unpatched between those two dates has been sitting in the open for almost two months. The lesson for security teams is to start the patch clock at disclosure, not at a federal catalog entry. The LangChain-core gap, arbitrary file reads through the prompt loader LangChain-core, the foundation under both, disclosed CVE-2026-34070, CVSS 7.5, a path traversal in its legacy prompt-loading API. The load_prompt() functions read a file path out of a config dict with no check against traversal sequences or absolute paths, so an attacker who influences that path reads arbitrary files the process can reach, including the .env file holding OPENAI_API_KEY and ANTHROPIC_API_KEY. Cyera paired it with CVE-2025-68664, CVSS 9.3, a deserialization flaw that resolves environment secrets through a crafted object. The fix versions differ, which matters when you patch: CVE-2026-34070 lands in langchain-core 1.2.22 and 0.3.86; CVE-2025-68664 lands earlier in 1.2.5 and 0.3.81. Clear both, or the higher-severity flaw stays live behind a patched one. Three frameworks, three classic AppSec bugs. Path traversal. SQL injection. Unsafe deserialization. Nothing exotic, nothing AI-specific, just old vulnerabilities living inside new infrastructure. None of this is a frontier-model problem. It is plumbing, sitting in the layer where AI meets the enterprise. Why the scanner cannot see it Merritt Baer, CSO at Enkrypt AI and former deputy CISO at AWS, has named what makes this kind of failure hard to see coming. It does not announce itself as an AI problem. "CISOs will experience MCP insecurity not in the abstract, but when an employee pastes sensitive data into a tool, or when an attacker finds an unauthenticated MCP server in your cloud," Baer told VentureBeat. "It won't feel like 'AI risk.' It will feel like your traditional security program failing." The framework chains here are the same shape. An exposed Langflow instance is an unauthenticated server in your cloud, and the alert, if one fires, reads like an ordinary incident. That is the gap in one sentence. The exploit lives in the framework your code imports. The WAF never sees a msgpack decoder running three layers down. The EDR watches the agent server make the same process calls it makes a thousand times a day and waves it through. Both tools are doing their job. Nobody scoped the framework itself as the thing that could turn on you. The root cause is older than AI, and Baer names it. "MCP is shipping with the same mistake we've seen in every major protocol rollout: insecure defaults," she told VentureBeat. "If we don't build authentication and least privilege in from day one, we'll be cleaning up breaches for the next decade." Langflow's auto-login is that mistake shipped. LangChain-core's unguarded prompt loader is that mistake shipped. The convenient default is the vulnerability. And the moment an agent connects to anything, that risk compounds. "You're not just trusting your own security, you're inheriting the hygiene of every tool, every credential, every developer in that chain," Baer said. "That's a supply chain risk in real time." There is a governance failure layered on top of the technical one, and it is the same miscategorization Assaf Keren, chief security officer at Qualtrics and former CISO at PayPal, has flagged in adjacent tooling. "Most security teams still classify experience management platforms as 'survey tools,' which sit in the same risk tier as a project management app," Keren told VentureBeat. "This is a massive miscategorization." Swap in AI agent frameworks, and it still holds. Teams file LangGraph, Langflow, and LangChain under developer convenience, then wire them into databases, CRMs, and provider keys. "Security has to be an enabler," Keren said, "or teams route around it." These frameworks are what routing around it looks like. Follow the money and it points at the same layer. On its Q1 fiscal 2027 earnings call, CrowdStrike reported its AI detection and response line up more than 250% sequentially, and on June 17 it extended that runtime coverage to agent, LLM, and MCP traffic on AWS. George Kurtz, the company's co-founder and CEO, named the reason in plain terms: "Agents run on the endpoint. They make tool calls, access files, invoke APIs, and move data at the process level." That is the exact plumbing these chains abuse, and real money is now moving to the layer your AppSec scan skips. What to put in front of the board The board does not need the CVE numbers. It needs the consequence, and Keren draws the line the board cares about. Most teams have mapped the technical blast radius. "But not the business blast radius," Keren told VentureBeat. "When an AI engine triggers a compensation adjustment based on poisoned data, the damage is not a security incident. It is a wrong business decision executed at machine speed." A framework RCE is the same problem one layer earlier. The agent does not just leak a credential; it acts on production systems with it, and the business sees an outcome no one can explain. So frame it the way a board frames it: we run AI agent frameworks in production that can be turned into remote shells through bugs our scanners are not built to find, all three are patched, one is under active attack, and here is the date every instance is verified and closed. None of this required custom malware or a zero-day. The six-question checklist Six trust boundaries, one per row, each with the question, the proof point, the command, the fix, and the board line. Run it tonight. How to read this table: each row is one trust boundary, left to right, from the question to ask to the line to read your board. Give the board the deadline, not the technology The fixes are not a re-architecture. They are version bumps and config changes you can land this week. The exposure is the gap between the day the patch shipped and the day your team runs the checks, and right now that gap is measured in months. The frameworks did exactly what they were built to do.

Technology Innovation Institute: AI agents need proof, not promises | Fortune

For most of the generative AI era, enterprises judged AI by what it could do. Could the model summarize a contract, answer a customer, support an analyst or a clinician? That test still holds. It is no longer enough. A harder phase is underway. Organizations are deploying agents that retrieve sensitive data, call tools and APIs, update records and act inside live business systems. The job has changed from producing content to performing tasks. That changes the evidence enterprises need before they can trust these systems. When a chatbot returns a wrong answer, someone usually catches it and fixes it. When an agent moves money inside a payments platform, alters a record in a hospital network or pushes code into production, the damage is harder to contain. Accuracy remains essential but accountability is now the harder problem. The enterprise must be able to show what an agent did, which model and code it executed, where it ran, what data it accessed and whether it stayed inside approved limits. Agents collapse the distance between software output and business consequence. A model that recommends an action carries one kind of risk. An agent that takes the action carries another. As agents reach into email, databases, code repositories and financial workflows, they increasingly function like non-human insiders. They have no intent, yet they can accumulate privileges, spread errors and create exposure at machine speed. Traditional oversight was not built for this. Human review still belongs in sensitive moments. But no enterprise can station a person in front of every action and still expect the productivity that justified the agent in the first place. The task is to let autonomy operate inside limits that are clear, enforceable and provable. Independent evidence is the hard part. Companies have built meaningful governance around AI agents. Policies, oversight committees, post-incident reviews and emerging control planes help register agents, enforce policy, manage identity and log activity across agent fleets. Those capabilities are necessary, but they stop short of independent verification. That is the gap. As agents grow more capable and more autonomous, trust has to be validated at the moment of execution. In high-assurance engineering, trust lives in the architecture and is tested and backed by evidence. Enterprise AI is heading to the same place. Confidence cannot rest on documentation or vendor claims. Organizations need a way to verify behavior when it counts. Consider a finance agent with authority to update vendor records and route payments within an ERP system. To deliver value, it requires access to sensitive financial data and permission to act. Policy may say the agent can touch only approved records, use only approved tools and escalate certain decisions to a person. The policy is not evidence that any of that happened. Logs may capture part of the story, and they are often partial, scattered or impossible to validate on their own. The enterprise needs a stronger record. Which model was running when the decision was made? Was it the approved version? Did it run inside a protected environment? Did it reach only the data it was cleared to use? Were the required approvals enforced before it acted? And can an auditor, a regulator or a partner confirm the answers? This points to the distinction that will define the next phase of enterprise AI. Assurance gives organizations a claim about expected behavior. Evidence gives them a way to validate actual behavior. Enterprises have plenty of the first and still need more of the second. The building blocks already exist. Confidential computing protects data while it is being processed, not only when it sits in storage or moves across a network. Hardware-based attestation confirms that approved software is running in the environment it should be. Cryptographic records can make execution history and policy enforcement resistant to tampering. Strong identity frameworks establish which agents are operating and what each is allowed to do. Combined, these mechanisms can provide verifiable proof that a specific agent version executed in an approved environment, accessed only authorized data and tools, and enforced required policies before taking action. This is why verifiable execution belongs alongside the control plane, not against it. The control plane enforces policy and records what happened. Attestation gives outside parties a way to confirm that the governance held, without taking the platform's word for it. Together they created a level of trust that neither can achieve alone. The demand for independent evidence will not land evenly. It will hit hardest where accountability and adoption are inseparable. Banks, hospitals, government agencies, defense organizations, critical infrastructure operators and sovereign AI programs all need systems they can govern, audit and defend. Open standards will be essential because enterprises increasingly operate across multiple clouds, models and agent frameworks. Trust cannot depend on a single vendor acting as the sole authority for verification. No single cloud provider or model developer can be the sole authority on trust. Enterprises will need interoperable methods to verify how agents behave across different platforms and stacks. Early work on agent attestation and verifiable execution shows where this is going. AI governance must be transparent, portable and independently verifiable. The same principle has a longer clock. Systems deployed today may still be operating years from now, while regulations, threats and security requirements keep moving. If audit records are expected to support trust years later, the cryptography used to protect them also has to evolve. Quantum-era risk adds another layer of concern. Anyone building AI infrastructure for high-value data should design for cryptographic agility now, so security can be updated as standards shift rather than locked to today's assumptions. The next phase of AI will not be settled by capability alone. Better models, greater scalability, lower costs and smoother integration still count. But the systems that earn the deepest place in enterprise operations will be the ones that can answer a harder demand. Can they show they acted within bounds? As agents take on more authority, that has to become a requirement, not an aspiration. For years the defining question in AI has been what these systems can do. For the decade ahead it will be what organizations can verify they did. The opinions expressed in Fortune.com commentary pieces are solely the views of their authors and do not necessarily reflect the opinions and beliefs of Fortune.

Secure AI will be defined by emulated human behavior

Agentic AI is moving rapidly from boardroom ambition to enterprise reality. Gartner forecasts that roughly 40% of enterprise applications will incorporate task-specific AI agents this year, up from just 5% last year. This surge forces every CIO, CISO, and technology leader to consider: What should AI be allowed to access, and how should it operate once inside the enterprise? Many organizations begin by embedding AI agents directly into legacy systems, connecting them to backend databases, APIs, and workflows in the name of speed. While this inline approach can work in modern, well-governed environments, it often bypasses the approval workflows and controls that legacy systems were built around. Agents can access restricted data, skip approvals, or execute transactions without a complete, attributable record. The result is a growing governance gap. Decisions tied to sensitive data can't be reliably reconstructed or defended with the same confidence as human-driven work. Even advanced models stall in pilots because organizations can't prove how outcomes were produced. The solution is not to slow AI adoption. It's to change how AI interacts with the systems that already run the business. When AI bypasses the system, it breaks it Consider a finance workflow in an ERP software system. An agent updates vendor bank details and pushes a payment through a fast-track path, bypassing a required approval step and segregation-of-duties check. Later, when the transaction is questioned, the organization can't prove who approved the change, why it was made, or whether proper controls were followed. That's where accountability breaks down. Changes are made inside core systems, but the evidence is incomplete, inconsistent, or disconnected from the system of record. Emulated human behavior offers a more secure and practical path. These agents operate exactly as a human employee would: logging in with standard credentials, navigating the existing user interface, reading screens in context, following established workflows, and executing tasks while remaining fully subject to every control already in place. No new APIs. No raw backend data exposure. No rewriting of decades-old business logic or security rules. The guardrails designed to protect against human error or misuse -- validations, permissions, approvals, and audit logging -- remain 100% intact. This UI-first approach is especially effective for organizations running mission-critical processes on older platforms. Building secure, governed APIs for legacy systems is expensive and time-consuming, often leaving out protections built into the interface layer. While emulated human agents may not match the speed of direct backend calls, they provide far more valuable enterprise advantages: immediate deployability, ironclad accountability, and zero disruption to proven controls. Secure operation doesn't require avoiding AI. It requires rethinking how it fits into the systems around it. Preparing for emulated human in the enterprise Three priorities can help organizations prepare for the emulated human approach as AI scales into critical workflows. 1. Place AI at the points where work happens Most enterprise AI strategies assume deeper backend integration creates better automation. In environments shaped by legacy systems, it often does the opposite: introducing new complexity while bypassing the workflows and controls already built into the interface layer. Instead, focus AI at the points where it can operate without requiring systems to be rebuilt. This approach dramatically reduces integration overhead, limits exposure of core systems, and allows AI to scale within existing operating models rather than forcing costly modernization. 2. Align AI accountability with human accountability Agents should operate under named identities and the same policies as employees. They preserve approval workflows, follow role-based permissions, and generate the same audit artifacts -- including log entries, change histories, tickets, and recorded approvals -- that organizations already rely on to review human activity. This removes the dangerous two-tier governance model where AI operates under different standards than employees. Organizations can maintain visibility, accountability, and established compliance and risk management controls as AI takes on greater responsibility. 3. Design for adaptability rather than brittle automation Traditional robotic process automation (RPA) relied on rigid, click-by-click scripts that broke the moment screens changed or exceptions appeared. Emulated human agents interpret context in real time, adjust to variation, and continue operating, just as skilled employees do. That adaptability is essential in dynamic enterprise environments where policies change, exceptions are common, and systems are rarely static. Instead of constant break/fix maintenance, organizations gain AI that can operate more resiliently inside real-world workflows. Scaling AI with the systems already in place As agentic AI scales, enterprises will be judged not only by the intelligence of their systems but by their ability to govern them. The pressure to balance innovation with control will only intensify. The most durable strategies will be those that embed AI safely within the systems already in place, rather than racing around them. When an agent's actions can be audited and justified with the same rigor applied to a human colleague, it's finally ready for production. That's how secure, scalable AI will be defined in the enterprise. We feature the best small business software. This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

Copilot, LiteLLM and the AI trust boundary gap

Two AI tools broke in the same way in the same two weeks, and four research teams proved it. The pattern underneath every disclosure is one sentence: enterprise AI accepts external input with no trust boundary. On June 15, Varonis disclosed SearchLeak (CVE-2026-42824), a proof-of-concept exfiltration chain in Microsoft 365 Copilot Enterprise Search. A victim clicks a crafted microsoft.com URL, Copilot searches their mailbox, and the data leaves through a Bing SSRF. No plugins, no second click, no visible indicator. Four days earlier, Obsidian Security published a three-CVE chain against LiteLLM that carried a default low-privilege user all the way to admin and remote code execution. Two tools. Two teams. One broken boundary. The five-check audit at the end of this article maps each gap to a CVE or a market signal from June, a command you can run before lunch, and a sentence a CISO can read to the board. Copilot turned a trusted URL into an exfiltration engine SearchLeak chained three weaknesses into a silent data-theft chain. The URL q parameter fed attacker instructions straight to Copilot's LLM. A rendering race condition fired an image tag before the output sanitizer ran. Bing's image-search endpoint, allowlisted in the Content Security Policy, routed the stolen data out. Microsoft rated the flaw critical and patched it on the back end, according to Varonis. NVD has not yet scored it; a third-party tracker lists it at 6.5 medium. The severity is contested, but the mechanism is not. The escalation is the real story. This is the third Varonis Copilot exfiltration chain in twelve months, after Reprompt in January and EchoLeak in 2025. Reprompt hit Copilot Personal. SearchLeak hit Enterprise Search. Enterprise inherits the user's full organizational permissions, so the blast radius is everything that a user can reach. LiteLLM handed a default account to every provider key The LiteLLM gateway holds the keys for OpenAI, Anthropic, Azure, and Bedrock behind a single proxy. The Obsidian chain runs in three moves. CVE-2026-47101, an authorization bypass, lets a non-admin mint a wildcard API key. CVE-2026-47102 promotes that caller to proxy admin through an unguarded /user/update endpoint. CVE-2026-40217 escapes the code sandbox through exec() with full builtins. Obsidian then demonstrated a reverse shell by injecting a forged tool-call response through LiteLLM's callback mechanism. Obsidian assessed the combined chain at CVSS 9.9. The developer typed one word. The attacker popped a shell. A separate LiteLLM flaw made the urgency immediate. CVE-2026-42271, a command-injection bug in the MCP test endpoints, landed on the CISA KEV list on June 8 with a June 22 remediation deadline. That KEV entry is not the Obsidian chain. The two are distinct disclosures four days apart, fixed in different releases, pointed at the same gateway. LiteLLM carries more than 40,000 GitHub stars and sits in thousands of enterprise deployments. This is not the first scare, either. A supply-chain compromise backdoored LiteLLM versions 1.82.7 and 1.82.8 on PyPI in March. A compromised gateway exposes every provider credential the organization holds. Langflow and Mini Shai-Hulud proved the pattern scales The same boundary broke in two more tools in the same fortnight. Langflow CVE-2026-5027 became the third Langflow remote-code-execution flaw to hit active exploitation this year. A path traversal in file upload lets an attacker write files anywhere on disk, and because Langflow ships with auto-login enabled by default, a single unauthenticated request reaches RCE. VulnCheck confirmed exploitation on June 9. Censys counted roughly 7,000 exposed instances, the heaviest concentration in North America, with MuddyWater attribution. The Mini Shai-Hulud campaign hit a different pressure point. After the worm's source code went public on May 12, copycat variants compromised 32 Red Hat Cloud Services npm packages on June 1, packages pulled 80,000 times a week. The worm harvests more than 20 credential types and self-propagates under the compromised maintainer's identity. Four teams, four tools, one operating failure. The bug classes differ. SearchLeak is a prompt injection. LiteLLM is privilege escalation. Langflow is path traversal. Mini Shai-Hulud is supply-chain poisoning. The boundary that broke is the same in all four. The market already repriced the risk CrowdStrike's Q1 FY27 earnings call put a number on the gap. AIDR, the company's AI detection and response line, grew ending ARR more than 250% sequentially, with a Q2 pipeline above $50 million (SEC-filed 8-K). Total company ARR reached $5.51 billion, and CrowdStrike's fleet telemetry shows more than 1,800 agentic applications running across enterprise endpoints. On June 17, the company extended AIDR to AWS, adding real-time evaluation of agent, LLM, and MCP communications across Amazon Bedrock, Kiro, and Strands Agents, building on its work with Anthropic's Project Glasswing. Daniel Bernard, CrowdStrike's chief business officer, said the AI attack surface now spans development, runtime, identities, and cloud infrastructure, and that teams treating those as separate domains leave the gaps between them open. Practitioners name the same gap in plainer terms David Levin, CISO at American Express Global Business Travel, told VentureBeat the pattern does not surprise him. "We kind of have this shadow AI, which is just the new version of shadow IT," Levin said. Both Langflow and LiteLLM fit the description. Teams stood them up for convenience, gave them credentials, and never brought them under governance. Levin puts the fix before deployment. "We didn't go into this with just saying we're going to go do this without the right fundamentals," he said. "We leverage NIST controls. NIST has released their CSF along with their AI framework. OWASP released their top 10. You need the right fundamentals before you deploy." Merritt Baer, CSO at Enkrypt AI and former AWS Deputy CISO, named the structural version of the failure in a separate VentureBeat interview. "Enterprises believe they've 'approved' AI vendors, but what they've actually approved is an interface, not the underlying system," Baer said. "The real dependencies are one or two layers deeper, and those are the ones that fail under stress." She has tied that directly to how systems fall. "Raw zero-days aren't how most systems get compromised. Composability is," Baer told VentureBeat. "It's the glue between the model and your data where the risk lives. If you give an agent bash and a root token, you've already done most of the attacker's work for them." That is what rows 2 and 4 of the audit test: the gateway that holds every key, and the agent identity no one governs. Levin had a sharper frame for the boardroom. "You need to talk more in terms of risk versus compliance to your boards and your executives," he said. "It's not about the size of the engineering team anymore. It's the size of your imagination. It's all written in plain English. It's not hard for anyone." Neither SearchLeak nor LiteLLM needed custom malware or a zero-day to work. Adam Meyers, CrowdStrike's SVP of Intelligence, put the operational squeeze in numbers in an exclusive VentureBeat interview. "The problem is not zero-day. The problem is patching. If you 10x that problem, they're gonna be completely underwater," Meyers said. He pointed to identity as the second front. "Some of these AI have their own identities, or people give their identity to the AI to take action on their behalf, and that makes it a very complex problem." The five-check trust-boundary audit Each row maps a gap to its proof point, a verification command for Monday morning, the fix, and the sentence to read to the board. The fix is plumbing, not policy The June 2 executive order creates an AI Cybersecurity Clearinghouse with a July 2 deadline. The five gaps above are not frontier-model problems. They are plumbing problems in the gateways, orchestration platforms, identity layers, and runtime environments where AI meets the enterprise. The audit is five rows. Every row maps to a June disclosure or market signal, a command a team can run before lunch, and a sentence a CISO can read to the board. The question is not whether your vendor will patch. It's whether you find the gap first -- or whether an attacker finds it the way they found Copilot and LiteLLM.

AppViewX targets ungoverned AI agents with new identity security product

AppViewX targets ungoverned AI agents with new identity security product AppViewX Inc. today launched Agent Identity Security, a product that discovers, governs and monitors artificial intelligence agents across enterprise environments as autonomous software increasingly operates on sensitive systems without human oversight. The product extends the AppViewX platform, built on the company's machine identity and public-key infrastructure tools, into AI agent security. It gives security teams a single control plane for every machine and agent identity in their environment, according to the company. AppViewX is pitching the launch at a problem it describes as enterprise security's fastest-growing blind spot: AI agents that act autonomously with broad access and minimal supervision. Ungoverned agent identities can misuse privileged access and violate compliance policies, exposing organizations to security risk. The company is framing the product around two trends hitting enterprises at once. AI agents are proliferating quickly, while the prospect of quantum computing breaking current cryptography is pushing organizations to rethink how they establish digital trust. AppViewX argues that the authentication tools most companies rely on were built for a human-centric world and were not designed for either machine-scale identity or a post-quantum environment. "AI agents have become the largest workforce most enterprises never hired, operating autonomously across sensitive infrastructure with broad access and minimal oversight," said Chief Executive Archit Lohokare. "This new class of identity will lead to incredible innovation if governed appropriately for the post-quantum era. Agent Identity Security gives enterprises the visibility, governance and threat detection to deploy AI agents at scale, without trading speed for security." Agent Identity Security includes four main capabilities. It continuously discovers agents along with their large language models, tool connections and credentials, producing a centralized AI bill of materials. It enforces policy across an agent estate, mapping to frameworks including the National Institute of Standards and Technology's AI Risk Management Framework, the European Union's Artificial Intelligence Act and System and Organization Controls 2. It also applies task-based access controls that restrict agents to only the tools and data each job requires, integrating with existing privileged access and identity management tooling. A fourth component, an AI companion called Guardian Agent, flags anomalous agent behavior in real time and walks teams through remediation. The company is positioning its PKI roots as the differentiator, arguing that grounding agent governance in cryptography addresses the AI and quantum challenges together rather than as separate add-ons. Todd Thiemann, principal analyst at Omdia, said enterprises are deploying AI agents faster than they can govern them, creating "considerable business risk." Grounding agent governance in a native PKI foundation, he said, gives enterprises the cryptographic depth to tackle both the AI and quantum challenges "in one motion, rather than bolting on solutions after the fact." Agent Identity Security is available now as a private preview for qualified enterprises. AppViewX will demonstrate it at the Identiverse 2026 conference. AppViewX has raised about $50 million to date from Brighton Park Capital, including a $30 million growth round in 2019 and a $20 million Series B led by the firm in 2022.

Phishing the agent: Why AI guardrails aren't enough

AI agents are reshaping how enterprises automate work, but their effectiveness depends on access to sensitive systems and data. The paradox is that granting them the permissions they want creates new attack surfaces that organizations aren't yet equipped to handle. This is the defining tension of the AI era. AI agents are proliferating across enterprises with 91% of organizations already using them yet only 10% have a clear IT management strategy in place. This gap matters because as these systems grow more autonomous and more deeply embedded in workflows, enterprises are operating without clear visibility, meaningful oversight and control over how their AI agents behave. The access problem Our recent research revealed how agents running on OpenClaw, an open-source AI agent automation platform, could expose credentials and leak sensitive information when attackers compromised the communication channels controlling them. To appreciate the scale of this risk, we must first understand the platform itself. OpenClaw combines a chatbot-style interface with access to external tools and large language models. Users can then configure agents to browse the web, read and write files, manage inboxes, execute commands, or interact with other machines. In many cases, they're designed to operate autonomously with minimal human oversight. That level of access is what makes agents powerful, helping many to manage everyday admin and time-consuming tasks. However, this power is a double edged-sword and can make them a risk to businesses. When agents become attack surfaces Agents need access to tools, accounts, applications, the web and more to be useful. Often, this means an agent needs access to secrets: API keys, personal access tokens, credentials, .env files, OAuth tokens. The agents/models are by default prompted to be as helpful as possible, and that characteristic starts to pose some particular concerns when it comes to credentials and tokens. If an agent such as OpenClaw can't access a resource, it will ask for credentials right in the chat, exposing those secrets within the context window. Agents will happily store API keys in their unencrypted configuration files, which information-stealing malware is starting to target. Remote access capabilities could effectively create a back door into enterprise environments. If an attacker gained access to the communication channel controlling an agent, such as a messaging or remote access platform, they could potentially gain access to everything the agent itself could access. In an enterprise context, this is a nightmare. The paradox of recognized risk Perhaps the most revealing finding was that some agents recognize risky behavior while simultaneously carrying it out. This underlines how their decision-making ability and autonomous operations can be a business risk. In one test, an agent correctly identified that exposing an OAuth refresh token through an unencrypted communication channel represented a serious security violation. But it then proceeded to share the token anyway before expressing concern about its own decision. Organizations should not rely on the invisible guardrails that frontier model providers put around agents. They're easily circumvented. But an AI agent cannot divulge credentials that it doesn't have access to. This is why the conversation around AI agent security cannot focus solely on stronger guardrails. Attackers are already finding ways to manipulate agent behavior through prompt injection, social engineering, and compromised communication channels. Governance, not just guardrails AI agents are essentially identities within enterprise systems and need to be managed as such. They perform actions and make operational decisions in ways that increasingly resemble human employees or privileged service accounts. Yet many organizations are deploying these systems without applying the same governance standards. Most businesses already understand the importance of least-privilege access, audit logging, identity management, and access reviews for employees. AI agents should be subject to the same principles. That means limiting what agents can access, avoiding long-lived credentials wherever possible, and ensuring sensitive information is stored securely through centralized systems with human oversight. Organizations also need visibility into where agents are deployed, what tools they can interact with, and how to disable them quickly if something goes wrong. If an agent goes rogue, there needs to be a "kill switch," a way to immediately revoke an agent's access to resources and shut it down. Agentic AI systems could deliver major operational upsides, but deploying them without robust identity and access governance introduces significant security risk. As these systems become more deeply embedded across enterprise environments, organizations must stop treating them as experimental tools and start governing them as part of the digital workforce. This means managing the full lifecycle of agents, from knowing which agents are deployed, what resources they access to and keeping a full audit trail so no one can say, "I don't know what happened. The agent did it." There's no reason why conventional security wisdom, such as the principle of least privilege, lifecycle management and robust logging, should be thrown out in an agentic age. In fact, it's more relevant than ever. We've tested and reviewed the best cloud storage. This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

'Yesterday, a user was the weakest link. Today these agents are becoming the weakest link': Zscaler CEO Jay Chaudhry on why he believes zero trust can secure the AI agents of the present, and the future

Zscaler CEO Jay Chaudhry lays out the company's plans for security AI agents AI agents are entering the workforce, and while some show promise at increasing productivity and ending repetitive rote work, others are using their autonomy to cause some serious problems. Zscaler CEO Jay Chaudhry believes his company has a solution. Speaking in Vienna at the opening keynote of Zscaler Zenith 2026, Chaudhry shared his perspective on how a security architecture born in 2007 is best suited to secure the workforce of the future. "Agents are becoming the weakest link" "There have been so many instances where Microsoft Copilot exfiltrated data without a user action, the agent did it," Chuadhry said. "We're seeing OpenClaw poisoned with credential stealers, and there are other cases where databases got deleted, email inboxes got deleted - and it's not users who are doing it. These agents operate independently, they can make decisions, they can take actions." Where a human has the ability to recognise if their actions are destructive, many AI agents do not double check. "Yesterday, a user was the weakest link, today these agents are becoming the weakest link." "They move at machine speed. They need no coffee breaks, no weekends, no time to sleep," Chaudry noted, pointing to the fact that there is very little time for human decision making to take place once an autonomous agent begins a workflow. "The challenges are coming because the AI revolution is different.," he added. "In the internet wave we had human beings able to access websites, in the cloud wave we could have people build applications on the cloud and access them. In every prior wave, we were securing waves using new tools, but this time the tools are the workforce." "This is where zero trust will play a bigger and bigger role." Zscaler recently unveiled a wave of new tools to help secure emerging AI technologies and autonomous agents under its Zero Trust Exchange platform. Among them are tools to prevent AI agents from abusing their permissions, and tools to mask their presence from attackers looking to create a double agent. The tools unveiled include AI Broker: a platform for maintaining organisational visibility over the access controls applied to autonomous agents, and Endpoint AI Security: designed to closely monitor for malicious activity at the device level, digging as deep as the browser, extension and plugin levels. "It's a very exciting but challenging problem to solve," Chaudhry noted, adding that "to really take any action, you've got to understand what you have and what the risk is associated with it." Not only does the new AI agent platform feature MCP and A2A brokers to secure agentic communications, but it also helps in securing agents by "understanding the task that is being done, understanding prompts properly, and being able to inspect prompts to understand the intent." Additionally, Zscaler announced AI Access Graph, which provides visibility into the connections between individual identities, applications and data sources. "In an enterprise, you've got all these entities, you've got all these data sources. They talk to each other. How do you know who is talking to who? Who has what kind of access?" "This problem was solved by a bunch of PhDs at the University of Texas in Austin," Chaudhry explains, pointing to Zscaler's recent acquisition of Symmetry Systems. "It takes telemetry and meta data from all of these sources, applies AI on top of that, and creates a powerful graph that allows you to connect the dots." For Chaudhry, positioning AI agents behind zero trust and using Zscaler's new tools makes enterprise security "simple, elegant, and your workloads are hidden from the internet." Currently, Zscaler handles more than 750 billion requests per day, and with agentic traffic rapidly growing, Chaudhry expects to add "one or two zeroes to this number." "That's the scale our engineering team is working towards. That's the scale we want to build."

How AI Agents Are Making Identity Security More 'Critical' Than Ever: Partners

When it comes to identity, 'we see it as that really necessary piece to help manage anything in the AI space -- but specifically agentic,' says GuidePoint Security identity security leader Kevin Converse. As the rush continues around deploying AI agents across organizations of all sizes, one question in particular is becoming impossible for security teams to ignore: Who -- or what -- is actually getting access to the organization's IT systems? And just as important as the visibility question is a second issue relevant to cyber risk: Is that access actually appropriate? For solution providers, helping to answer those questions for customers has become a massive and growing focus in 2026, as CISOs and CIOs grapple with mandates to securely enable agentic automation within their companies. [RELATED: Global AI Week 2026] That shift is putting even greater pressure on security and IT teams to rethink their approach to identity security and access management -- especially around non-human identities, life-cycle governance, least privilege and continuous monitoring, solution provider executives told CRN. "Identity absolutely is the perimeter at this point," said Rob Gregory, CISO at Denver-based Optiv. "Agents in and of themselves are identities. And what they can do -- or what they should be able to do -- needs to be tracked, reviewed, attested to," Gregory said. "There should be an approval process. So it should have your traditional life-cycle management. It should have your traditional IAM [identity and access management] practices." Without a doubt, there is a huge identity risk when agents inherit human privileges without oversight from their organizations, according to Ian Swanson, AI security leader at Palo Alto Networks, Santa Clara, Calif. "Many times we will find that there are agents running on the loose that don't have strict least-privilege controls," Swanson said. "Or let's say an identity takes on a human identity. What if you were to leave the enterprise, but now that agent lives on and it's carrying out tasks and it has your privileges?" Ultimately, organizations must ensure they are "constantly" assessing the underlying posture configuration around identity and access so that there are delegated controls on the identity front, he said. In that vein, discovery is of course crucial, but the other challenge is making sure that "you have those all those insights that you're able to see in real time, to be able to say, 'OK, are those actions actually approved or not?'" Swanson said. That visibility challenge is only getting steeper as AI is increasingly adopted from the bottom up, according to Nancy Wang, CTO at 1Password, Toronto. "Shadow AI is like shadow IT on steroids," Wang said. "You don't know what your employees are using. You don't know how they're using it -- or even why they're using it." The bottom line is that if employees are using company data with unsanctioned AI agents, "then you're essentially exfiltrating sensitive data from your enterprise into the world -- or even worse, credentials, whereby attackers can use those to [compromise] you," she said. At the same time, solution providers said the rapid adoption of agentic AI is making the problems more urgent. Many companies , they said, are rapidly adding new, automated identities into environments, which were often already struggling with forms of machine access such as service accounts, certificates, API tokens and secrets -- non-human identities securely authenticating to and interacting with sensitive resources like databases or cloud services. Non-human identity has long been a challenge for privileged access management (PAM) practitioners. What's new is the scale and urgency within businesses, according to Cyderes' James Hauswirth. A non-human identity is an authorization and authentication mechanism that allows an activity to be performed either automatically or at least through a process that doesn't require human intervention, said Hauswirth, global managing director of PAM at Kansas City, Mo.-based Cyderes. That includes everything from software agents running on laptops to certificates, service accounts, tokens and secrets, he noted. The thing to keep in mind is that AI agents will use whatever authentication mechanism they can, Hauswirth said. "Part of the challenge is that AI can use whatever identity it's given access to to be able to go out and do whatever it does," he said. While the estimates vary about how many agents there may end up being in proportion to each human worker, it will no doubt add up to an "explosion" of agentic identities over time, according to Hauswirth. The reality is that not only is it a major challenge to understand what agents can access, but there are also big hurdles around determining who the agents belong to -- and whether the agents' actions are even still aligned with their original purpose, 1Password's Wang said. There's no question that the cyber risk from uncontrolled agents could be massive, according to industry executives. When it comes to an agent running locally on a device, a la OpenClaw, the agent has access to "all your data files," said George Kurtz, co-founder and CEO of CrowdStrike, Austin, Texas. "Everyone [is] plugging in their credentials to plug into Box and Dropbox and Google Drive and their email and every other thing that's out there." All in all, if agents are being granted access to data and workflows, "how do you even know what's going on?" he said. "This is really scary stuff." Increasingly, that is a top concern for customers as AI agents introduce new layers of uncertainty into already complex environments, according to Arctic Wolf CEO Nick Schneider. "How do I know that my employees are leveraging company assets -- in particular, data -- in a way that is proper, given that we know that there are LLMs they could plug anything into to get an output?" Schneider said. "That requires certain detections and visibility into what's happening on the network or the browser or the endpoint to be able to identify what's happening, and/or identify through identity [systems] whether it's a human taking an action or an agent taking an action." Even as the agentic surge continues, there's also a risk that identity and access concerns may fall to the wayside amid the pressing needs around updating vulnerability management, following the emergence of powerful frontier AI models for vulnerability discovery, executives said. Jay Chaudhry, founder and CEO of San Jose, Calif.-based Zscaler, said the emergence of AI-accelerated vulnerability discovery -- paired with long‑running challenges such as insufficient patching -- has created a level of anxiety in the cyber field that he has never seen before. To enable a strong security posture in a threat environment that may see as much as a 20-fold spike in software vulnerabilities, "our view is that the best security is what we have been talking about from the start of Zscaler with zero trust," Chaudhry said. Zero-trust principles, likewise, are critical when it comes to identity security and access controls, solution providers said. Importantly, this creates a significant advisory and services opportunity, as customers need help discovering where non-human identities exist and determining who owns them -- as well as understanding what they can access and deciding how long that access should last, according to solution providers. When it comes to enabling AI agents, identity security and access controls are undoubtedly "critically important" -- and on track to only become more essential going forward, said Kevin Converse, vice president for identity and access management at Herndon, Va.-based GuidePoint Security. "We see it as that really necessary piece to help manage anything in the AI space -- but specifically agentic," said Converse. "When you see the non-human identity explosion, that is kind of a new space for everyone," he said. "So, trying to figure out what's the best way to get visibility -- that's the first piece of it. And then [the goal is] finding ways to put controls around it."

Why security leaders are cautious about agentic AI

Agentic AI is everywhere in cybersecurity right now, but it often feels like everyone is using the term slightly differently. Vendors are quick to mention it, yet rarely stop to explain what it actually means in practice or what problem it's meant to solve. For security leaders, that makes it a difficult space to navigate, especially when expectations are high but clarity is still catching up. At its core, agentic AI describes a goal-oriented system of multiple agents that can act, sometimes autonomously, towards an outcome. That is a concept, not a cybersecurity result. In software development, the value is more straightforward. Multiple agents can collaborate to write, test, and improve code. In cybersecurity, the environment is far more fragmented. Tools span endpoint, network, identity, cloud, vulnerability management, and response. If agentic AI is limited to a single vendor's ecosystem, it cannot deliver meaningful outcomes. It simply operates within another silo. The Challenge of Fragmented Security Environments The cybersecurity industry has long talked about platformization, but in practice many platforms have become larger collections of disconnected capabilities. This is where many early implementations fall short. Instead of transforming workflows, they provide a chat interface that allows operators to query multiple systems. While this may improve usability, it actually increases cognitive load. Security teams need to know what the platform is capable of, ask the right questions, interpret results, correlate findings, and decide on actions. Why Caution Is Justified Security leaders are right to approach agentic AI carefully. The market is full of bold claims about autonomous systems that can solve complex problems without human input. In reality, most of these systems are far from that level of capability. Without expert level instruction, agentic systems cannot operate autonomously in a reliable way. Many current solutions depend on users crafting prompts and interpreting outputs. Transparency is another concern. If a vendor cannot clearly explain how their system works, what data it uses, and where human oversight applies, it is difficult to trust the outcomes. In security operations, where decisions can have direct business impact, that lack of clarity is unacceptable. The Role of Guardrails and Human Oversight Effective agentic AI in cybersecurity must include strong guardrails and human-in-the-loop control. Security teams can use AI to accelerate investigation, analysis, and prioritization, but final decisions must remain with people. Actions need to be explainable, traceable, and auditable. Security leaders must be able to understand why a recommendation was made and what evidence supports it. Without that, trust quickly breaks down. The goal is not to remove humans from the process, but to give them better information faster and reduce the number of manual steps required to reach a decision. Planning Past the Hype Cycle The industry is already moving beyond early experimentation. Agentic workflows are beginning to reshape how security operations function. In some cases, they will reduce the need for traditional orchestration approaches as intelligence becomes embedded directly in investigation and response. At the same time, new models, like Mythos, are emerging that can assess vulnerabilities and provide deeper insight into risk. These developments will challenge tools that rely heavily on static analysis or periodic assessments. Mythos has transformed the vulnerability detection space and we're starting to see disruptive volumes of findings. But, what happens 12 months from now after the number of findings plateau? How will your agentic tools detect misconfiguration or poor posture and take remediation action for those vulnerabilities that did not get patched? That's where the real test begins. Agentic AI offering lasting value should move beyond discovering issues to continuously identifying root causes, detecting drift in posture or configuration, and guiding remediation over time. What Good Looks Like in Practice When implemented correctly, agentic AI can deliver meaningful benefits. Consider a ransomware incident. Instead of requiring an analyst to manually investigate across multiple tools, an agentic system could connect events across endpoint, network, and identity data. It could identify that malware execution is linked to a disabled protection control, trace lateral movement attempts, and highlight indicators of compromise. All of this information can be presented as a clear, evidence based narrative. Rather than sorting through alerts, the analyst is given a concise understanding of what happened, why it matters, and what actions can be taken. This might include isolating affected systems or restricting access to contain the threat. Reducing Noise and Improving Decision Making One of the biggest challenges in security operations is the volume of alerts. Agentic AI has the potential to improve the signal to noise ratio by correlating data and focusing attention on what truly matters. By combining evidence from multiple sources, it can escalate only the most critical issues and provide clear reasoning behind those decisions. This allows teams to respond more quickly and with greater confidence. Today, many investigations take hours or even days. By automating key steps, agentic AI can reduce that time significantly, helping teams keep pace with fast moving threats while reducing burnout. What to Prioritize Security leaders need to separate marketing claims from real capability. Many vendors promote AI, but few are using it to fundamentally improve how security work is done. The focus should be on solutions that reduce detection and response time and improve operational efficiency. Strong solutions are grounded in real data. They rely on tools that directly observe activity across endpoint, network, identity, and cloud environments. This data provides the foundation for accurate analysis and decision making. Equally important is the ability to take action. Systems that only generate alerts or tickets add friction. The most valuable platforms enable teams to act within the same workflow, whether that means isolating devices, enforcing policies, or guiding response actions. A Practical Path Forward Not all consolidation is beneficial. Security teams should avoid solutions that add noise without improving clarity. They should also be cautious of systems that rely heavily on open ended prompts. These interfaces often shift the burden onto the user, forcing them to determine what questions to ask and whether the system can answer them. Security leaders should avoid AI that produces unreliable or unsupported outputs. Effective agentic AI must be grounded in repeatable workflows and supported by verifiable evidence. Agentic AI has potential to improve cybersecurity operations, but only when it is applied thoughtfully. The goal is not full automation, but meaningful augmentation of human expertise. CISOs should adopt a measured approach. Invest in solutions that provide clear value today, maintain governance and oversight, and build toward greater capability over time. By focusing on outcomes rather than hype, security leaders can take advantage of agentic AI without introducing unnecessary risk. Success will come from using AI to make security teams faster, more informed, and more effective while keeping humans firmly in control of decisions that matter most. We rank the best identity management software. This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

AI Is Finding Bugs Faster Than Enterprises Can Patch

Join the DZone community and get the full member experience. Join For Free I have spent the better part of a decade building data protection products for global enterprises. Cloud DLP, CASB, SSPM, Behavior Threats, AI Access Security, ISPM, etc. The kinds of things that sit between a user, an agent, or an application and the sensitive data nobody wants to see in the wrong place. Every conversation I have had with a customer security architect this year eventually arrives at the same question. The threat landscape has clearly changed. What does that mean for the controls we already own? This article is the analysis I have been sharing with security architects across industries who are evaluating how their data protection programs need to evolve. It is grounded in what is publicly documented, what it actually changes for enterprise data security, and where I would direct the next dollar of investment based on a decade of building these products at scale. What Actually Shifted, With Sources There are three publicly verifiable data points worth understanding before any control conversation makes sense. Discovery Is Becoming Inexpensive Mozilla shipped Firefox 150 in April 2026 with two hundred and seventy-one fixes that came out of a single sweep using an early version of Anthropic's Mythos preview model. That is roughly four times the project's typical annual baseline, in one pass. Mozilla also added the most honest sentence I have read on this topic all year. They said they have not seen any bug in the set that an elite human researcher could not have found, given enough time. SecurityWeek covered the details: securityweek.com/claude-mythos-finds-271-firefox-vulnerabilities. Read that caveat carefully. The thing that became automated is not novelty. It is the cost of finding a class of bugs that humans were always capable of finding. When the price of an action drops by an order of magnitude, the action gets done at scale. That is the shift, and it is the shift that matters. Patching Is Not Getting Cheaper at the Same Rate HackerOne paused new submissions to its Internet Bug Bounty program on March 27, 2026. The IBB is the oldest crowdsourced vulnerability reward program for open source, dating back to 2013. The pause was not a budget decision. It was an admission that the gap between AI-assisted discovery volume and the ability of volunteer maintainers to ship patches had become unbridgeable on the existing incentive model. Dark Reading's coverage is here: darkreading.com on the IBB pause. Earlier in the year, the curl project removed bounties from its program for the same reason, after a wave of low-quality AI-generated submissions overwhelmed triage. If the upstream open source ecosystem is struggling to keep pace with discovery, every enterprise that ships software with open source dependencies is downstream of that struggle. That is most enterprises. Autonomous Agents Are Already Creating Real Incidents In April 2026, the Cloud Security Alliance published two surveys that I think every data security team should read. The first study found that fifty-three percent of organizations have had AI agents exceed their intended permissions, and forty-seven percent have already experienced a security incident involving an agent in the past year. The second, published a week later, reported that eighty-two percent of enterprises have discovered previously unknown agents running in their environments, and sixty-five percent have had an agent-related incident. The most common consequence was data exposure. CSA's findings: Enterprise AI Security Starts with AI Agents and Autonomous but Not Controlled. Take those three threads together. Bug discovery is industrializing. The patch side is bottlenecked. And inside the enterprise, autonomous agents are already operating in places nobody fully maps. That is the operating reality, not a forecast. Why This Matters More for Data Security Than for Any Other Function Most of the AI security conversation is framed around vulnerabilities and exploits. I think that framing misses what is actually changing for enterprises. When a class of vulnerabilities becomes cheaper to discover, the average time between exposure and exploitation shortens. When average exposure time shortens, the probability that any given control fails inside that window goes up. When more controls fail more often, the consequence shows up at the data layer. Data is the asset. Everything else is a path to it. The CSA finding I keep coming back to is the one that says agent incidents most often produce data exposure, not service outages. That tracks with what I see at customer sites. The blast radius of an agent compromise is determined by the data the agent had access to, the policies that were being watched, and the speed at which someone noticed. None of those three is improving on the timeline that adversaries are improving. That sentence is the part of the conversation that I find most data security teams are not yet having internally. It needs to happen this quarter. Three Things Data Security Programs Should Rethink Now 1. Stop Treating Non-Human Identities as a Hygiene Problem CyberArk's 2025 Identity Security Landscape, surveying 2,600 cybersecurity decision-makers globally, found that machine identities now outnumber human identities by more than 80 to 1 in the typical enterprise, up from roughly 45 to 1 in their 2024 study. GitGuardian's State of Secrets Sprawl 2025 report found 23.8 million new secrets exposed on public GitHub in 2024 alone, a 25 percent year-over-year increase, with non-human identities flagged as the dominant credential population behind that growth. The exact ratio in any given environment is a question for the IAM team, but the order of magnitude is consistent across every serious study I have read, and it is rising fast. Most enterprise IAM programs were designed around human users. Periodic access reviews. Quarterly attestation cycles. Manager signoff. None of that infrastructure was built for a population that is now eighty times larger, that provisions itself, and that often outlives its original use case. CSA's research found that only 21 percent of organizations have a formal decommissioning process for AI agents. Everyone else is accumulating what the report calls retirement debt: agents who completed their task months ago and still hold credentials, tokens, and data access. From a data security standpoint, the practical consequence is that an enterprise's most overprivileged identity is rarely a person. It is a service account from 2022 that nobody remembers, an OAuth grant that an integration test attached to a real production scope, or a workflow agent that picked up admin-level permissions during deployment because the person setting it up did not want to debug a permission-denied error at 11 p.m. These identities are reachable by adversaries through a single credential compromise, and they often have direct access to the kinds of data that DLP policies were written to protect at the human user layer. The remediation requires a structured non-human identity program with a named owner, a defined lifecycle covering provisioning, rotation, and decommissioning, and quarterly access reviews that apply to bots the way they apply to humans. Workload identity federation rather than long-lived secrets. Scoped service accounts. Logging that captures what each non-human identity touched, not just whether it authenticated successfully. From a tooling perspective, this work sits at the intersection of CASB, IAM, and DLP, and in most enterprises, it has no clear owner across those three functions. Establishing that ownership is the precondition for everything else. 2. Refresh Classification and Tagging for an Agentic Environment In my own work on DLP product strategy, I have come to think of classification and tagging as the foundation that every other data control sits on. If sensitive content is correctly identified at the moment it is created or ingested, downstream policies have a fighting chance. If it is not, no amount of policy authoring downstream will catch up. Most enterprise tagging programs were designed for documents flowing through email, endpoints, and a manageable list of SaaS applications. The current generation of AI agents and copilots flows through none of those choke points cleanly. An agent reads a corpus, generates a derivative artifact, and writes that artifact somewhere else. The original tag, if there was one, often does not survive the round trip. The derivative may contain sensitive content that was reassembled from sources that were each individually below the policy threshold. Three practical refreshes are worth funding now. * Treat AI-generated outputs as a first-class data class. Anything produced by an agent or copilot needs provenance metadata that travels with it: which model produced it, against which prompt, derived from which sources, with which level of human review. Most enterprise classification taxonomies do not have a slot for this yet. Add one. * Lower the threshold for tagging at ingestion. The cost of misclassifying a sensitive document used to be that a human eventually emailed it to the wrong person. The cost now includes an agent reading it as part of a larger context and producing a derivative that lands in a SaaS workspace your DLP product does not inspect. Err on the side of more aggressive classification at the source. * Audit your DLP coverage of LLM endpoints and agentic SaaS surfaces. Most DLP deployments I see in the field have rich coverage of email and endpoints, partial coverage of cloud applications, and almost no coverage of the LLM and agent traffic that has become a meaningful share of how sensitive data now leaves the environment. That is the coverage gap most likely to show up in a 2026 incident report. 3. Put a Model in the Pull Request Path This is one of the few areas where the offensive shift in AI capability cuts directly in defenders' favor, and most enterprise application security programs are not yet using it. The traditional SAST and DAST queue is where AppSec hours go to die. Thousands of unverified findings, most of them noise, validated entirely by humans on a backlog that never empties. The newer pattern is to put a model-based reviewer in the pull request path itself. Every PR is reviewed by an automated agent for security defects before a human sees it. Findings show up as inline comments. High-confidence findings can block the merge. OpenAI publicly stated in April 2026 that its Codex Security agent has contributed to over 3,000 critical and high-severity vulnerability fixes across the ecosystem since launch, and that its Codex for Open Source program now provides free security scanning to more than 1,000 open-source projects. Anthropic, Semgrep, and several other vendors have shipped comparable capabilities. Whether you build on a commercial offering or assemble an internal pipeline, the workflow is what matters. One nuance worth knowing about. Standard commercial models often refuse legitimate dual-use security queries by policy. Binary reverse engineering, exploit reasoning, malware analysis. If your AppSec team has been telling you that AI tools "do not work for security," this refusal threshold is usually the reason. Both Anthropic's Glasswing program and OpenAI's Trusted Access for Cyber, expanded on April 14, 2026, to thousands of verified individual defenders, exist precisely to provide a lower refusal threshold for verified defensive use cases. Enterprise procurement and legal teams should start the verification paperwork now, not after a need arises. The Supply Chain Is the Other Half of the Data Exposure Problem Two recent incidents are worth holding in mind whenever this conversation comes up. On September 8, 2025, eighteen widely used npm packages, including chalk, debug, and ansi-styles, were trojanized after a phishing campaign targeting the maintainer known as qix. Those eighteen packages collectively account for over 2.6 billion weekly downloads. The malicious versions were live for roughly two hours and were written to drain cryptocurrency wallets, but the same access could have been used to exfiltrate environment secrets, build credentials, or sensitive data from any CI pipeline that pulled the bad version during that window. Palo Alto Networks Unit 42 and others published detailed breakdowns: paloaltonetworks.com on the qix incident. A week later, on September 15, 2025, the Shai-Hulud worm became the first self-propagating malware in the npm ecosystem, compromising hundreds of packages in its initial wave and continuing to evolve through follow-on campaigns into late 2025 and early 2026. The malware integrated TruffleHog to scan for secrets in compromised environments, harvested credentials from cloud instance metadata services where available, and weaponized GitHub Actions workflows for persistence. Palo Alto Networks Unit 42, ReversingLabs, Wiz, and others have continued to track variants of the same family. The reason these matter for a data security conversation is that the attacker's objective in both cases was credentials and secrets in build environments. From there, the path to data is short. A compromised CI runner with cloud credentials can read whatever those credentials can read. A compromised GitHub token can read whatever the org allows. A compromised npm publish token can introduce a future payload that does both. Treat the build pipeline as a data security boundary, not just an engineering productivity surface. A dependency firewall that validates package provenance before installation (Sonatype Nexus Firewall, JFrog Xray, Socket.dev, or equivalents) is the highest-leverage single control I know of for closing this attack surface. The Shadow Agent Problem Is a DLP Problem in Disguise The single most striking statistic in the April 2026 CSA research, to me, was that eighty-two percent of organizations had discovered previously unknown AI agents in their environment over the past year, and forty-one percent had discovered them more than once. The agents most commonly emerged in internal automation and scripting environments, in custom assistants and plugins built on LLM platforms, in SaaS tools with built-in automation, and in developer-created workflows. This is, structurally, the same problem that shadow IT was a decade ago, and the same problem that shadow SaaS became five years ago. The difference is that the average shadow agent has read access to more sensitive data than the average shadow application ever did, because agents are useful precisely in proportion to how much context they can reach. A finance team's reconciliation agent, helpfully built in an afternoon, often ends up with broader visibility into financial data than the human who built it. A customer support copilot frequently has a service account with access to the entire ticket database, including PII. None of this is malicious. It is the path of least resistance for getting an agent to do something useful. Three controls help close the gap, and they are mostly extensions of capabilities a mature data security team already owns. * CASB and SSPM coverage of LLM and agent platforms. The platforms hosting these agents (custom GPTs, Copilot Studio, internal MCP servers, vendor copilots) are SaaS applications. They need posture management, sanctioned application policies, and inline data protection just as much as Salesforce or Workday do. Most CASB and SSPM deployments are still catching up here. Push your vendor. * Inline DLP on prompt and completion traffic. The point at which sensitive data leaves the environment is increasingly the prompt itself. Inline data inspection at the LLM gateway, using the same content matchers (EDM, IDM, OCR, vector ML) you trust for email and endpoints, is the right architectural pattern. The vendors are building this, but few enterprises have it deployed. * An agent registry, even a basic one. Until the agent population is enumerable, no policy applied to it is provable. A spreadsheet is fine to start. The goal is to be able to answer, on any given Monday, three questions: which agents exist in production, what data each one can read, and who is the human owner of each. CSA's data shows that most enterprises cannot answer those questions today. What I Would Actually Start on This Week Comprehensive ninety-day plans tend to lose momentum after the first two weeks of execution. The more effective approach, which I have refined over years of operationalizing data security programs at enterprise scale, is a focused set of starting moves that can ship in two weeks and that compound into a larger program over the quarter. * Run an inventory pass for AI agents and copilots in your environment. Spreadsheet is fine. Capture name, owner, data scope, and approval status. The goal is to convert the CSA shadow agent statistic from an industry survey number into a number you actually have for your own organization. * Review the data scope of every service account and OAuth grant tied to an LLM, agent, or copilot platform. Most of them were sized for development convenience, not production. Tighten the ones that need tightening. Decommission the ones that are no longer in active use. * Pilot a model-based reviewer in the pull request path of one codebase. Measure the false positive rate and developer satisfaction at week four. If the numbers are reasonable, expand. If they are not, tune and try again. * Add provenance metadata to your data classification taxonomy. Even if the only label you can ship this quarter is "generated by an AI system," shipping it now is more valuable than waiting for a perfect schema. Tagging at ingestion is the part of the program that compounds, and it has been undersized for the agent era at most enterprises I have seen. * Open the verified access conversation with your AI vendors. Anthropic Glasswing, OpenAI Trusted Access for Cyber, and equivalent programs from other providers offer pathways to models with reduced refusal thresholds for legitimate defensive work. The application process involves coordination with General Counsel and procurement, which is why initiating it before an urgent need is critical. Programs of this kind will become foundational infrastructure for enterprise security teams over the next two years. These moves represent the structural transition that enterprise data security programs need to make over the next eighteen months. Programs that begin this work now will spend that window refining the controls and integrating them across their existing security stack. Programs that delay will spend the same window writing postmortems that explain why the controls were not in place. Conclusion The cybersecurity industry has navigated several genuine inflection points over the past decade, and the current moment qualifies as one of them on a specific structural ground: the cost curve for finding software flaws has bent, while the cost curve for shipping patches has not. The gap between those two curves is where every enterprise security program now operates, and the consequences land first at the data layer, which is where my work has been concentrated for the past decade. Data security teams that internalize this framing now will spend 2026 building defensible programs around a fundamentally changed threat economy. Teams that wait for a more dramatic signal will spend the same period responding to incidents that the structural shift made predictable.