Presented by Box

Identity and permissions are no longer enough to secure enterprise AI agents. They govern what an agent can reach, not how it behaves once it starts working on its own, and an autonomous agent can turn legitimate access of enterprise data into unintended action in seconds. That gap is pushing enterprise AI security from just governing access toward a layered approach that includes governing execution, says Heather Ceylan, chief information security officer at Box.

"Access controls and permissions are the foundation, but the challenge is they were designed for humans," Ceylan says. "Permissions are still the foundation, but you have to think about how the agents get their permissions scoped as well."

Access controls were built for a slower, more forgiving world, where a human employee with lingering permissions to a decade-old folder will rarely go looking for any data inside it, or even remember they have access at all. But an agent will explore all of its permissions, operating at a scale no person can match and surfacing forgotten misconfigurations and stale permissions far faster than a human ever could. Identity and scoped permissions remain the first layer of any credible defense, however, because agents raise the stakes, clean access hygiene is more valuable than ever.

A steady drip of incidents in recent months underlines the potential for major damage, where models have slipped the sandboxes they were supposed to stay contained within, reached systems they weren't scoped to touch, or read content they were not permitted to access. While the specifics vary, the overarching threat remains the same: an agent found a path through the data that it could reach, and took it.

Access controls alone can't secure autonomous AI agents

Complications crop up when agents are handed broad standing permissions to match broad workflows. An agent might legitimately need to call fifty tools across twenty different actions over the life of a task, reading and writing folders that span every department in the company. But granting all of that access at once inflates the blast radius of possible damage to data and content if a single step goes wrong. A stronger permissions model provides access only in the moments that it's needed, Ceylan says.

"You need permissions that change based on what the agent has been asked to do, when it needs to take that action," she explains. "If it's taking one step and only needs two tools, it should be scoped to only those two. When you narrow permissions to the task in front of the agent, the number of ways any given step can misfire shrinks with it."

From governing access to governing execution

Tight security is also no longer tied to whether an agent has access to specific data, but whether it should take a specific action on a specific step, which is the difference between a standing access grant and a bounded one. In other words, an agent may hold legitimate rights to a finance folder but still have no business writing four thousand of those files to a new location, even if it's told to do so.

"An employee with access to payroll data they were never meant to keep could be instructed to pull the payroll records and write them to a public shared folder, publishing the entire company's compensation in a single move," she says. "Every access check passed, but the behavior still has catastrophic consequences."

Prompts alone can’t reliably govern agent behavior because instructions can change, agents can absorb injected instructions, or they can be steered by files they read along the way. Durable controls need to live one level down, with the tool calls themselves, as well as the content those calls act on. Deciding in advance what an agent is permitted to execute, regardless of how its prompt is manipulated, keeps behavior inside fixed bounds that no clever input can talk it out of.

Legacy content platforms weren't built for AI agents

Most of what an agent touches inside a company is unstructured content, including contract, policies, customer records — the accumulated files that make up the overwhelming majority of corporate data. Much of it still sits in systems that were designed for human filing habits: network drives, aging ECM platforms, and many SaaS tools. Those systems were built to ask the question, does this person have permission? and they answer it with folder-level access that hasn't been audited for years.

The legacy platforms don't have metadata for an agent to reason over or classification for an enforcement layer to act on, and their logs aren't detailed enough to show what an agent read. Bolting an AI connector onto that stack doesn't fix any of it, it just hands agents the same blind spots, only at machine speeds, Ceylan says.

"Every agent action eventually resolves to content," Ceylan says. "If the content layer can't tell you what it's holding, who it belongs to, and what should never leave it, there's nothing underneath your controls."

How to decide which AI actions need human approval

Two years ago, everyone assumed security would always mean including humans in the loop. Building and living with agents has changed that assumption, Ceylan says, and Box now sorts actions into three tiers: fully autonomous actions, monitored actions and high-risk actions that require human approval.

• Fully autonomous, reserved for actions that are reversible, bounded, logged, and free of untrusted input, and where a mistake doesn't cost too much.

• Monitored actions, once a team has built enough confidence in an agent and paired it with alerting and rollback that can catch and undo a problem in flight.

• Irreversible, high-risk actions that are always routed through a person — for instance, when an agent that wants to delete a large number of files or wipe the primary folder in a structure.

Each team must calibrate the lines between these layers to match its own risk tolerance.

Box’s approach is to put controls in the platform rather than the workflow, enforcing protections such as data classification, labeling and expiration without requiring a human checkpoint for every action.

"The right configuration should be enforced at the outset, instead of blocking an action at the end," Ceylan says.

Building trust in AI agents through behavior over time

An organization can make an access decision once, but trusting an agent's behavior should only happen over time, observing how the agent runs, collaborates, and builds on the outputs of other agents. Published frameworks tend to lag the technology, or are too abstract to implement; instead Box works from a smaller set of principles: tightly scoped agent identities and actions, clear expectations about what can be rolled back, three approval tiers, and a way for teams to test and iterate quickly.

"The sanctioned path has to be the fast path, because when teams aren't given a safe way to experiment, they tend to route around the controls entirely," Ceylan says. "A security leader's job is to offer a way to move quickly without stepping outside the guardrails."

Sustaining trust in an agent depends on being able to see how it actually behaves. But traditional monitoring tools weren’t built for the job; the behavioral baselines that underpin user and entity behavior analytics were calibrated to human activity, and suspicious agent behavior doesn’t necessarily look like human activity.

And while establishing a useful agent baseline begins with logging, many agents start out as experiments, so their actions never make it into logging infrastructure. Plus, important signals are rarely individual easily flagged actions, but chains of activities across systems, as one agent's output becomes another's input, while the detections for that pattern are still being designed.

Governing agents, then, requires visibility not just into what they can access, but what they actually do, and that visibility has to live where the content does.

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

Enterprise AI has entered a new era. Organizations are rapidly moving beyond assistants that answer questions to autonomous agents capable of reasoning, invoking tools, accessing enterprise applications, coordinating with other agents, and completing multi-step business workflows with minimal human intervention.

This shift represents a fundamental change in how software operates. Traditional applications execute predefined logic written by developers. AI agents, however, dynamically determine how to achieve an objective. They decide which tools to use, which APIs to call, what information to retrieve, and how to sequence actions based on context. That flexibility unlocks enormous business value, but it also introduces a new class of security risks.

Much of today's AI security discussion focuses on prompt injection, model vulnerabilities, and data leakage. These are important concerns, but they represent only part of the challenge. Once an AI agent has successfully authenticated and begins acting autonomously, traditional security controls provide very little visibility into whether it continues to operate safely.

This is where enterprises need to adopt a new security mindset: runtime trust.

Authentication establishes identity, not trust

Enterprise security has traditionally relied on three foundational questions: Who are you, what can you access, and what actions are you authorized to perform. Identity providers, multi-factor authentication (MFA), role-based access control, and zero trust architectures answer these questions effectively for human users and conventional applications, and NIST's zero trust guidance remains a solid reference point for how those principles are meant to work (NIST SP 800-207).

AI agents introduce a different problem. An AI agent may legitimately authenticate using an enterprise identity, receive valid API credentials, and be granted access to systems like Microsoft 365, ServiceNow, Salesforce, or GitHub. From an identity perspective, everything appears correct. The real challenge begins after authentication: During execution, the agent continuously reasons, interprets objectives, invokes tools, retrieves information, and adapts its behavior based on new context, and security teams must determine whether those actions remain aligned with the user's intent and organizational policy. Authentication verifies who an AI agent is. Runtime trust continuously verifies what it is doing.

Enterprise AI is becoming an autonomous workforce

Modern AI agents increasingly interact with large language models (LLMs), Model Context Protocol (MCP) servers, retrieval-augmented generation (RAG) systems, vector databases, enterprise APIs, SaaS platforms, and internal knowledge repositories, as well as other AI agents. This interconnected ecosystem enables sophisticated automation but dramatically expands the attack surface: A single compromised tool, poisoned knowledge source, overly permissive API, or manipulated prompt can influence downstream decisions across an entire workflow, and unlike traditional software, these risks evolve during execution rather than being fixed at deployment.

That expanding surface is exactly what a handful of runtime threats exploit.

Goal drift happens when an agent begins with a legitimate objective but gradually deviates from the user's original intent while attempting to optimize outcomes. An agent tasked with preparing a customer report, for instance, might autonomously retrieve unrelated confidential information because it incorrectly determines that additional context would improve the response.

Excessive tool invocation is what happens when autonomous agents with access to numerous enterprise tools call unnecessary APIs, modify configurations, access sensitive repositories, or perform administrative actions simply because the model believes those actions are useful, absent any runtime controls to stop it.

Memory poisoning exploits the persistent memory that improves personalization: Attackers can intentionally insert misleading instructions into long-term memory or retrieval systems, causing future decisions to be influenced by malicious or outdated information.

Context manipulation takes advantage of how heavily LLMs depend on context: If attackers influence retrieved documents, system prompts, conversation history, or external data sources, they can indirectly steer autonomous behavior without ever compromising the underlying model. MITRE's ATLAS framework catalogs this kind of adversarial behavior against AI systems in useful detail.

Multi-agent amplification emerges as organizations deploy specialized AI agents that collaborate: If one agent behaves incorrectly, downstream agents may trust and amplify those actions, creating cascading failures across enterprise workflows.

Introducing runtime trust

Runtime trust extends security beyond authentication by continuously validating AI behavior throughout execution. Rather than assuming authenticated agents remain trustworthy indefinitely, it continuously evaluates whether autonomous decisions remain aligned with organizational policy. A runtime trust architecture rests on several complementary capabilities.

Intent validation evaluates, before executing sensitive actions, whether proposed behavior still matches the user's original objective: Is this action necessary? Is it expected? Does it exceed the requested scope? Would a reasonable human perform the same action?

Behavioral monitoring observes tool usage, API activity, reasoning patterns, execution frequency, delegated actions, and abnormal workflows, so unexpected behavior becomes immediately visible rather than remaining hidden inside model reasoning.

Policy enforcement means enterprise policies govern what AI agents can do, not merely what they can access — blocking financial transactions above approval thresholds, preventing privilege modifications, restricting administrative operations, limiting sensitive data retrieval, and requiring approval for high-risk actions. These controls function much like application firewalls for autonomous decision-making.

Least-privilege execution means AI agents receive only the capabilities necessary for the current task. Instead of granting permanent access to dozens of enterprise tools, organizations should dynamically issue short-lived permissions based on runtime context, an approach that OWASP's guidance for agentic applications increasingly emphasizes (OWASP GenAI Security Project).

Human oversight recognizes that not every decision should be autonomous — high-impact operations, including financial approvals, identity changes, regulatory actions, or customer-impacting decisions, should require explicit human confirmation before execution.

Protecting the enterprise AI ecosystem

Runtime trust also extends beyond individual agents. As MCP adoption accelerates, enterprises should verify trusted servers, authenticated tools, approved capabilities, monitored interactions, and policy enforcement. RAG knowledge repositories require document integrity, source validation, access control, retrieval auditing, and poisoning detection. Persistent AI memory should implement lifecycle management, expiration policies, integrity verification, access logging, and sensitive data protection.

Building operational visibility

One of the biggest challenges in enterprise AI is observability. Security teams need visibility into why an agent selected particular tools, which data influenced its decisions, how it reached its conclusions, what actions it executed, whether policies were triggered, and which safeguards prevented unsafe behavior. Runtime logging, audit trails, and behavioral analytics are becoming essential components of enterprise AI operations, not optional add-ons.

A practical roadmap

Organizations do not need to rebuild existing security programs. Instead, they should extend them by incorporating runtime trust into existing governance processes. Practical first steps include inventorying AI agents and their capabilities, applying least-privilege access to tools and APIs, classifying high-risk autonomous actions, implementing runtime policy enforcement, monitoring behavioral anomalies continuously, protecting memory and RAG data sources, requiring human approval for critical operations, and integrating AI runtime telemetry into existing SOC workflows.

Looking ahead

Enterprise AI will continue evolving toward increasingly autonomous systems capable of collaborating, planning, and executing complex business processes. Security strategies must evolve alongside them. The question is no longer whether an AI agent successfully authenticated. The more important question is whether it continues to behave safely throughout its entire lifecycle. Organizations that adopt continuous runtime governance today will be significantly better positioned to deploy autonomous AI responsibly, reduce operational risk, and build the confidence necessary for large-scale enterprise AI adoption.

The future of AI security will not be defined solely by stronger models or better authentication. It will be defined by our ability to establish, measure, and continuously verify trust while intelligent systems are making decisions in real time.

Ravindra Annam is a cyber security architect.

There is a clear repeating trend in agent deployments: The gateway is the first control teams reach for, but it is the one they are least ready to run. This is because gateways sit on top of identity and attribution layers that are mostly not there.

The first layer of risk is not hypothetical. In June, CISA added a LiteLLM flaw to its Known Exploited Vulnerabilities catalog after attackers were caught abusing it in the wild. The bug ran commands on the host through the gateway itself, and chained with a second flaw it required no credentials. It was one of seven common vulnerabilities and exposures (CVEs) disclosed in that single AI gateway in a month. This is the layer many enterprises reach for first to secure their AI agents.

When considering secure agent architecture, gateway controls should not be the first control. They should be the fifth.

Most models on the maturity of agent security describe the controls a company will need in the future. They tend to miss, from my experience, the more difficult problem of describing the brownfield scenario: In what order should these controls be layered in conjunction with an identity and access management system that is already in place?

If the control plane is unaware of which agent is acting, who delegated the work, what task the agent is to perform, and what credentials are being used, then the context is incomplete. A gateway may block clear policy violations, but will struggle to distinguish a justified action from one that is technically permissible but operationally inappropriate.

The pattern of failure is clear when sequencing these controls for agent production deployments: Enforcement is taken early, while the identity and attribution context it depends on has yet to be developed. Agent security functions as a dependency chain, with each control depending on context generated upstream.

The wrong starting point

Think about routing agent traffic via a new runtime gateway. A finance-reconciliation agent tries to alter a record in production. The gateway authenticates the user token and checks the API call. What it can't observe is that the request is agent-initiated, that the agent is executing a more limited function, or that the request is part of a tool chain invoked by an untrusted artifact.

The credential is valid. The API call is permissible. The action contradicts the purpose of the delegation. The gateway is there, but its set of supports seems absent, so a costly control is applied to a very small part of the whole picture.

Limiting an agent's privileges to those of the human principal is useful so the agent does not exceed the person it serves. However, having a privilege ceiling does not create separate attribution. Twenty agents might operate under a single person's permissions and still need unique identities, audit logs, behavior profiles, and revocation paths.

Dependency-gated deployment

I call this process dependency-gated deployment. Upstream exit tests must be satisfied before any downstream control is considered operationally complete. Concurrent development of downstream controls is permissible.

Here are the six gates, and the proof that they work:

The six dependency gates for the agent security controls. Each control is contextualized by the gates above it. From the author's analysis of production agent deployments.

Start with the agents you can actually name

To begin, recognize the production agents in open-source frameworks, cloud offerings, SaaS services, and developer tools. For each, record the owner, responsibility, lifecycle stage, allowed tools, data domains, and sources of credentials.

Bypass this step, and the organization will lose the first hour of incident response while they figure out what should have been obvious. The inventory identifies the asset that every control thereafter governs.

An agent needs its own identity, but it cannot lose the human behind it

An agent should not be buried in a developer token, a shared service account, or a human session. Simply knowing the caller is an agent is not sufficient. The control plane requires additional delegation context: Who delegated the work, what specific task the agent was instructed to execute, and which resources the agent needs the authority to access. Identity specifies which actor placed the call. Delegation is the answer to whose authority it acts, and for what reason.

Once that connection is cut off, the downstream logs attribute the reconciliation agent to the employee whose token it borrowed, and every action it takes is attributed to someone who did not start it.

Shrink authority before you inspect behavior

Once an agent can be identified, capabilities should be limited. Access restrictions should be time-bound to the task and limited to the tools and resources required to perform the task. This can be implemented using identity access management (IAM) features such as workload identity, token exchange, conditional access, and time-bound entitlements which the organization already possesses.

With regard to the 2026 Teleport study involving 205 security leaders, the access scope surpasses the predictive capacity of industry, maturity, or self-assurance concerning predicting AI-related incidents. For example, organizations with over-privileged AI reported a 76% incident rate, whereas AI incidents occurred in 17% of organizations under the least privilege. This indicates that access scope in the dependency chain is more important than context-aware runtime enforcement.

The primary principle is monotonic delegation. Every transfer of responsibility must preserve or diminish authority; under no circumstances should it increase authority. For the reconciliation agent, this means an agent who can view one ledger as opposed to one who inherits the employee's access to all systems the employee can access.

Fix attribution before automating enforcement

Most audit stacks can capture what resource was accessed and which credential allowed access. In the agent deployments I have reviewed, this is the most commonly missed gate. Prior to utilizing an adaptive runtime policy, link any relevant tool invocation to the agent identity, initiating principal, task id, parent action, and outcome. After doing so, examine the telemetry: For one completed task, see if you can track down the initiator, the agent who executed it, the authority under which the action was taken, the tools utilized, and the outcome. In regulated environments, oversight that is not attributed cannot be justified.

Now the gateway earns its keep

The gateway can use registered identities, explicit delegation, scoped credentials, and attributable telemetry to question if this agent is authorized to perform this action, for this principal, within this task, involving this resource. Although the user's credentials may provision write access to the finance-reconciliation agent, the gateway has situational context and so determines that it is out of scope. This is control's point of greatest value. The most stringent controls should be applied at irreversible boundaries — payments, access policy changes, deletions, modifications of the production environment, and data exports.

Detection and the kill path come last

Behavioral baselines are developed last because distinguishable and attributable agent activity must be established to set a standard. Then, security teams are able to identify anomalous patterns of tool usage, unexpected cross-domain access, and deviations from their assigned tasks. Containment is more than just the disabling of a single directory object: A proper kill path entails disabling the agent's identity, invalidation of active and derived credentials, blockage of tool activation, termination of active tasks, and isolation of the workload that contains the agent.

Start without replacing your IAM

Designing a whole new identity program is unnecessary. If the existing identity provider doesn't treat agents as native object types, begin with an authoritative registry linked to the existing workload identities. Following this, extend agent and task identifiers as trusted execution contexts, implement short-lived credentials to mitigate inherited privileges, and include those identifiers in tool-call logs for subsequent gateway ingestion. The dependency model remains unchanged as vendor support matures.

Control gaps are measurable. In Okta's 2026 survey, only 34% of executives said their organization always applies the same level of security rigor to its agentic workforce as to its human workforce. The last control from the chain cannot be applied first to close that gap.

What to do in the next 30 days

Begin with 10 production agents. For each one, identify the owner, purpose, approved tools, and credentials. By now, you should have the beginnings of an agent registry and perhaps your first insights on governance.

Test attribution. Find out if IAM and logging can tell each agent apart from the human or service that delegated the task. If this kind of differentiation is not possible, a gateway would be operating without any visibility.

Reconstruct one completed agent task within an action chain, from start to finish, including downstream effects. Wherever the chain breaks is where your deployment falls short.

Adding downstream enforcement ahead of required context breaks agent security. Maturity models describe the destination. A build order gets you there without breaking production along the way.

Nik Kale is a principal engineer specializing in enterprise AI platforms and security.

Presented by Nutanix

Autonomous systems that can reason, make their own decisions, and execute actions across an environment introduce a category of risk that application-level controls were never built to contain. Treating that risk as a single problem produces incomplete architectures, says Oscar Wahlberg, senior director of product management at Nutanix.

"The guardrails to catch a malicious prompt won't stop an agent from hallucinating and doing something it never should have done, like accidentally deleting databases or leaking sensitive data with a credential it was granted but then uses for something entirely different," Wahlberg says. "That's the central problem as enterprises move autonomous agents out of experimentation and into production."

Once an agentic system is granted execution privileges across the data center, the security posture has to scale into a defense-in-depth architecture spanning infrastructure, storage, compute, networking, and a governing control plane. Each layer addresses a distinct category of risk, rather than duplicating the same controls across the stack. No single security control or vendor can provide that protection on its own. Defense-in-depth depends on those layers working together.

By dividing the responsibilities across the stack and adhering to zero trust segmentation, organizations can create a secure framework that improves their overall posture. Understanding which risks belong in each layer is what turns the principle of defense-in-depth into a practical security framework, with three layers that each have a distinct responsibility.

Infrastructure layer: Establishing trust where AI agents run

The infrastructure layer’s foundational responsibility is establishing a root of trust that answers a simple question: who is operating in the environment? That trusted identity becomes the prerequisite for every security control above it. Before an organization can trust what an agent does, it first has to trust the integrity of the environment where the agent runs. When an agent requests permission to execute an operation, the system must be able to verify that the request came from the legitimate agent — not something impersonating it.

Delivering that kind of assurance depends on technologies that root trust in the hardware itself, including platform attestation, confidential computing, and secure boot, alongside controls that prevent unauthorized access both within a server and beyond it. For regulated industries such as financial services, this layer provides the ability to isolate AI production workloads so that neither the agent nor the environment can operate outside its assigned scope. That mitigates risks including model and runtime tampering, supply chain compromise, and unauthorized access to sensitive AI workloads.

Network layer: Governing how AI agents communicate

Once agents begin communicating with other agents, APIs, applications, and enterprise systems, they generate a level of concurrency and dynamic communication that traditional static network configurations were never designed to handle. An agent configured to call APIs, query data sources, and spin up additional agents without constraint creates a sprawling web of east-west traffic that becomes very difficult to reason about, and that complexity can easily mask lateral movement or data exfiltration when the right network security layers are not in place.

"We should treat AI agents as a new class of network identity, and make sure that an agent can only talk to other agents or data sources where it's explicitly allowed to do so," Wahlberg says. "That means moving away from rigid static rules toward dynamic policy enforcement."

Nutanix's solution is Agent Gateway, part of the Nutanix Agentic AI solution. It's a unified, governed layer that is designed to provide cost control and governance capabilities to help manage autonomous agent users. Coupled with agents grounded in zero trust segmentation and using capabilities like Nutanix Flow for micro segmentation and integrating with networking vendors, including its integration into the Cisco Secure AI Factory, Agent Gateway helps enterprises govern interactions across agents, models, data sources, and enterprise applications.

The network layer governs lateral movement, data exfiltration, and gates the agent's network interactions. A zero trust framework with access blocked by default and scalable interaction monitoring is important for agents since they can exhibit unreliable behavior. The Nutanix software integration with Cisco UCS servers and Cisco AI PODs delivers the turnkey physical infrastructure (compute, storage, and networking) that the AI factory runs on.

Control plane layer: Governing what AI agents are permitted to do

The control plane is the brains of the operation, providing a central point for managing agent permissions, tool access, resource consumption, and runtime visibility. What matters most is having a single place where policies can be enforced consistently rather than reinvented for every agent, Wahlberg says.

"Agent Gateway acts as a universal endpoint for different models and tools, so an IT team can configure their agents to talk to this single control point," he explains.

The centralized AI gateway enables the admin to observe, audit, and control access to models as well as MCP tools protecting data and gating privileged access. This layer is designed to help mitigate risks such as privilege misuse, runaway agents, unauthorized tool usage, data leakage, and the excessive model consumption that can lead to increased token consumption when agents get stuck in runtime loops. And it depends on treating governance as a runtime control system rather than a compliance afterthought.

Why one-size-fits-all security fails agentic AI environments

The biggest architectural mistake enterprises make is assuming a single security model can be stretched across every layer of an AI stack. When an organization tries to solve for hardware-level trust with application-level software, or leans on static legacy network rules to manage dynamic agents, it builds an architecture that either blocks the agentic system from doing its job or leaves critical doors wide open. One-size-fits-all thinking tends to produce significant performance penalties and operational friction.

"By failing to assign specific responsibilities to the appropriate layers, enterprises end up with blind spots in governance," Wahlberg says. "They might secure the model output but miss that there's data leakage between agents, or they might secure the network but lack the control plane visibility to understand that they're wildly burning tokens because the agents are stuck in some kind of runtime loop."

Focusing exclusively on the model leaves the largest gaps of all, because a guardrail that catches a malicious prompt does nothing to stop a hallucinating agent from misusing a legitimate credential. Embedding security across the full stack helps ensure that even when a model level threat slips past the initial filters, the agent remains constrained by hardware rooted trust, network isolation, and access controls at the agent layer.

How Intel, Cisco, and Nutanix build defense-in-depth together

The three-way partnership from the three companies demonstrates how the layered architecture comes together in practice as a well-governed, enterprise-grade AI Cloud. Intel supplies the computer to run agentic workloads and secures the execution environment through hardware-rooted trust and confidential computing, while also driving costs down through their accelerators. Intel Xeon 6 processors with built-in AMX accelerate AI inference efficiently without relying exclusively on expensive GPUs.

Cisco wraps the environment in a secure fabric that governs communication between agents and enterprise tools, while Nutanix provides the software platform, minimizing architectural silos, and the central control plane that enforces permissions, delivers visibility and cost governance, and ties the architecture together into a defense-in-depth solution that lets enterprises scale agentic AI.

Of the three layers, enterprises currently underestimate the control plane the most, Wahlberg says. A true control plane extends far beyond initial deployment to simplify Day 2 operations, he explains, giving IT teams the continuous observability, and strict token governance required to keep autonomous agents secure and cost-effective in production.

"Apart from model and tool selection, governing the agent deployments and their access to models and business tools in a tightly integrated full stack platform will be important for the success of AI projects," he says, pointing to a near future in which organizations move from a handful of AI use cases to thousands of agents working autonomously to drive the business.

Technology leaders should prioritize building a centralized governance layer today that can manage agent identities, tool permissions, and token budgets in real time, because that control point is what builds the operational muscle to scale safely.

"You can't build an AI system without getting into a lot of complex decisions," he explains. "And you need a control plane that talks across multiple vendors and infrastructures to help you solve for those defense-in-depth strategies."

Learn more about the Nutanix Agentic AI solution here.

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

Visa's open-source security harness now finds the vulnerability, writes the fix, and turns an adversarial panel on its own patch before any human reviews it. The whole loop ships on by default. A plain scan of the Visa Vulnerability Agentic Harness runs all 11 stages and edits source files in the target repo unless the operator caps it at detection.

The announcement Thursday pairs the release with an expansion of the Visa Consulting & Analytics advisory practice. Visa is shipping that default 18 days after Tenet Security demonstrated GhostJacking on the DEF CON 34 main stage, an attack chain in which an agent read an attacker's payload out of a log file and rewrote DNS with a valid credential. Two days earlier, Steve Wilson, Chief AI and Product Officer at Exabeam and project co-lead for the OWASP Top 10 for LLM Applications, made the case in VentureBeat for the opposite default. "The first thing I'd do is put an authorization gate outside the model," Wilson said in written responses. "The agent can propose the exact DNS change, but it cannot grant itself the authority to make it."

The bottleneck moved, so Visa moved the pipeline

Rajat Taneja, Visa's president of technology, rejects the premise that the default is a risk decision and calls it the product. "The bottleneck has moved," Taneja told VentureBeat in an exclusive interview. "AI is finding vulnerabilities faster than humans can in the history of our technology industry. The new bottleneck is fixing and proving we have fixed things."

VVAH grew out of Visa's participation in Anthropic's Project Glasswing, where the company aimed Claude Mythos at the network behind billions of daily transactions and watched the model chain minor weaknesses into working exploits, a hunt VentureBeat covered in July. "VVAH initially was completely only using Mythos, and that's when all of us, as part of Project Glasswing, realized the power of this new class of models that does semantic reasoning," Taneja said.

The harness went to GitHub in June and has climbed from 595 stars and 97 forks on July 20 to more than 2,300 stars and 300 forks as of August 25, with a clone-to-visitor ratio Taneja put near 9%. "We have got some very high-profile companies that have started using this harness," he said.

Why give it away? Taneja's answer starts with Visa's technology DNA and a harness built "to protect Visa and our ecosystem." The reason he leaned on hardest was obligation, "to do good by doing right" for "companies who may not have the same level of investments or knowledge in cybersecurity."

Contribution runs one way. The repo states it is not currently accepting external code contributions, so the harness that edits adopters' source takes no code into its own.

Thursday's release extends the pipeline past the report. "We're going from discover, verify, and report, and then fix it, to discover it, verify it, remediate it, validate it, and iterate it," Taneja said. "If a fix doesn't negate the exploit, then there should be a structured, automated feedback that preserves the learnings from the first run and then enhances it." Underneath that loop, the release refactors scanning around an abstract syntax tree call graph that maps subroutine calls and the traversal paths an attacker could reach. Taneja argued the change cuts token counts while delivering "better reasoning, context, and better exploitability analysis." On top sits MTTA observability across the stages, what he called a window pane, plus real-time progress views. "A pretty good step function," he said of the release.

One metric, three definitions

Mean Time to Adapt, the metric Visa invented alongside the harness, gets a shorter definition in this release. The short form is the time between discovery and resolution of attack paths, with some resolutions, Visa claims, shrinking from weeks to hours. Visa published a wider construction in June, and the Project Glasswing white paper tracks MTTA along three dimensions that include inventory freshness, exploitable paths per release, and validation cycle time. The repo carries a third, elapsed time from AI-discovered exploitability to a validated fix in production. Board slides will quote the shortest interval. Ask for all three, because a resolution count that skips validation is what MTTA was invented to replace.

Taneja ranks MTTA as "the most strategically important metric" because it shifts the focus from scanning to how fast an enterprise adapts. His shorthand is blunter. "It's not the finding. It's the fixing that matters," he said.

The default and the gate

Wilson's argument went past naming the gate. "We have to remember that security rules written inside prompts may shape the model's behavior, but they are still suggestions to the model, not enforceable security controls," he wrote. He also priced the control honestly. "The tradeoff is that the agent loses the ability to improvise arbitrary, high-impact infrastructure changes on its own, while retaining autonomous investigation and routine, bounded remediation," Wilson said.

The harness ships no approval step between patch and edited file. Where the human sits was the first question VentureBeat put to Visa in writing.

The company's own June white paper sets the bar. "AI agents are identities" sits among its 12 non-negotiable practices, requiring scoped permissions, least privilege, audit trails, and IAM governance for every agent that modifies a system. VVAH's shipped default is that agent.

"A lot of the traditional systems that are used today are basically signal providers," Taneja told VentureBeat. "They are telemetry, and then it's a lot of human analysis, and your SOC and your security and incident response teams doing a lot of the heavy lifting when they respond," and that, he said, cannot work at this scale. He pointed to the Hugging Face incident and "other frontier models escaping sandboxes to do things more autonomously" as the preview. "We have seen the trailer of this movie," Taneja said, and "every company in the world should prepare and rethink their architecture."

What the harness automates is the adversarial step. Before a fix counts as validated, the panel scores whether the patch negates the exploit, Taneja's test for done, with failed fixes feeding the next attempt, the iterate step Taneja described. Stage 11 itself runs read-only, per the README, and VVAH does not compile, build, or run tests against the patched tree. Taneja calls that wrapper "the governance architecture on top of that," and chaining findings into working exploits takes threat modeling and business context, which is why he argued "the harness with a model is far more effective than somebody using the model by itself."

Visa answers the gate question

VentureBeat put its questions to Visa in writing after the interview, and the answers arrived before publication. On why remediation ships on, the response repeated the bottleneck argument, then narrowed the scope. "VVAH is meant for authorized operators running against code they own, and in a controlled environment," the company said in written responses.

The approval question drew the most specific answer. "VVAH is a harness, not a merge tool," Visa wrote. "Stage 10 writes candidate fixes to a working copy of the repo. Stage 11 then runs an adversarial validation panel that scores each fix and returns one of three verdicts: validated, validation failed or needs review. None of these bypasses your normal build, test, and code review flow." Humans, the company wrote, are "the gate in three places. Before running the tool. When reviewing the patches. And before anything gets merged." "The final call on any fix stays with the security and engineering teams. In an enterprise, trust and auditability are not optional. The default flow is built around that."

Set beside Wilson's standard, the architecture lands close to his line and the sequence does not. Wilson's gate clears an action before it happens. The default's human gates open before the run and after the write. The attack is the automated part, and the three human gates sit outside the model, the boundary Wilson drew. "Our goal is to help security teams work at AI speed, not to replace them," Visa wrote. "VVAH does the repetitive parts. It finds issues, tests whether they are real, and proposes fixes. Before a fix gets to a human, an adversarial validation panel at stage eleven tries to break it. That way the human is spending time on decisions that need judgment, not on triaging noise."

Client zero got direct confirmation. "VVAH runs against Visa code today," Visa wrote, and Taneja had volunteered the posture on the call. "We designed this and we were using it for ourselves, and we were client zero," he said, adding "only when we saw the impact and the positive effect of what we were finding, we said every company would need this." What adopters value, Visa says, is context. VVAH pulls in CMDB data, threat models, and business risk, and where "most tools stop at findings," it "tries to answer, 'which of these should you fix first, given how your business runs.'"

Model choice becomes a per-stage decision

Multi-model orchestration is the other substantive change. "Mythos has a very high recall, but the Opus model has very high precision," Taneja said. "On stage one I want to use this model. On stage two I want to use this model," is how Taneja framed the per-stage setup, with newer GPT releases in the ensemble and open-weight models where pricing stings, all through configuration rather than code changes. "The whole is greater than the sum of the parts," as he put it. The harness was model-agnostic from day one, he added, and the evolution moved that choice into configuration, with prompt tuning and caching shared underneath. One boundary moved. In June, applying a fix required Anthropic backends, and OpenAI-compatible backends ran report-only. The current README extends remediation and validation to OpenAI-compatible and open-weight models through a shared model-agnostic runtime, with no single provider as a hard dependency, and the default routing for both stages stays Anthropic.

That flexibility lands on a market already churning. VentureBeat's Q2 2026 Pulse research found 59% of enterprises plan to adopt or switch agent security tooling within the year, and 82% still rely on provider-native controls as the primary layer. Visa said Thursday it is contributing VVAH to Nvidia's Open Secure AI Alliance as a model-agnostic framework and collaborating in Project Lightwell, the $5 billion IBM and Red Hat effort to harden open-source components.

Before turning fix mode on

Consulting is the other half of Thursday's announcement. Visa Consulting & Analytics is adding executive workshops, a VVAH-informed maturity assessment scored on a NIST one-to-five scale, and a cyber risk prioritization roadmap. "We were getting a lot of calls. Hey, can you help?" Taneja said, and the practice "became very important to handhold and help those who are using it." Carl Rutstein, global head of Visa Consulting & Analytics, framed it the same way. "Finding vulnerabilities is no longer the hardest part. Speed to remediation is the new battleground."

Presented by EDB

As enterprises give AI agents more autonomy — the ability to plan, decide, and act across systems without a human approving each step — a hard question moves to the center of every architecture review: When an agent tries to complete an action that it was never authorized to do, what actually stops it?

These are your agents, running on your models, touching your data in your infrastructure — and the responsibility for what they do sits with you. That responsibility can’t be met in hindsight or with a set of abstract policies that live on paper but not in practice. Agents need rules in the context of the moment, because they don’t exercise overriding judgment of their own actions.

Consider a simple rule: Never open the car door. Followed literally, an agent could never get in or out of the car at all. But if you change the context (the car has just crashed, there’s a fire, someone is hurt and needs to get out), then the rule you actually want is the opposite. Context in the moment is everything. We are asking agents to do intelligent things; that requires intelligent rules.

The instinct is to add guardrails around the agent: instructions, policies, and monitoring layered above the model. Those mechanisms matter, but they share a structural limit: The car-door rule is plausible right up until the moment you actually have to decide whether to open the door. Controls at the agent layer are only as reliable as the agent’s output is predictable, and autonomy is precisely the property that makes that output hard to predict. Governance that depends on reviewing an action before it happens cannot keep pace with a system that acts in milliseconds, across many systems at once.

Governance has to become executable, and enforced where agents actually do their work: at the operational data layer, in the context, and exactly at the moment it is happening.

The data layer is the enforcement point

Agents create value by touching data. They query it, retrieve it, transform it, and increasingly act on it. A policy that says an agent should not reach a certain class of data is meaningful only if the system can deny that access at the moment the agent requests it. Additionally, a principle that says AI must be auditable is meaningful only if the organization can reconstruct what the agent did, what data it touched, which user it acted for, and what resulted. When governance lives at the data layer, it holds regardless of how the agent was built or how it behaves, because the control is a property of the database itself, not a promise made by the agent.

Agent behavior may be probabilistic. Governance cannot be

The enterprise should not rely on a model choosing to follow policy. The policy has to be enforced by the system. That is the difference between hoping an actor stays in bounds and constructing bounds it cannot cross to begin with.

The controls that make this real are ones many enterprises already run at the data layer: role- and attribute-based access, row- and column-level security, classification and masking, policy as code, and complete audit trails.

What agents change is not the mechanism, but who the mechanism has to recognize. Identity management has to treat the agent as a principal in its own right, with its own identity and a purpose declared when the session opens.

Once purpose is bound to identity, the policy engine can evaluate it the same way it evaluates role or department today, and the record of what happened can capture not just who acted and what they touched, but what they declared they were there to do.

In practice, this resolves into nine controls, grouped under three imperatives:

Enforce it

• Role- and attribute-based access control enforced at query time, for agents as well as users

• Dynamic column masking driven by the same policy path

• Agent identity as a first-class principal, with declared purpose bound at session start and the acting user preserved

See it and prove it

• Classification and tagging that drives policy

• Session-level audit logging that records which agent acted, for which user, and under what declared purpose

• Lineage across pipelines, so a result can be traced back to the request that produced it

Unify and harden

• Centralized, portable policy management

• Encryption at rest and in transit

• Consistent enforcement across on-prem, cloud, and sovereign or air-gapped environments

“Declared purpose is what makes the difference. It becomes an attribute the access layer already understands, evaluated in the same policy path as role and row-level security. The enforcement mechanism does not change. What changes is that the agent's purpose is part of what it evaluates, and part of what the record proves afterward,” says Priyanka Jain, VP, product management, data & AI governance, EDB.

Wherever you are in your AI adoption journey, enforcement at the data layer is what lets you move faster rather than slower. The controls are already in the database. The difference is that agents now have to pass through them.

A digital leash, not a locked door

The goal is not to stop agents from doing useful work. It is to define how far an agent can go, what it can touch, what it can change, what requires escalation, and how the organization can reconstruct events if something goes wrong. Governed this way, agents are identified, scoped, monitored, and auditable. The enterprise can adopt them faster, because security, risk, and leadership teams trust the operating model underneath.

Open, sovereign, and enforceable at the source

Built on open source Postgres, this open foundation keeps enterprises in control of where their data lives, who can reach it, and under what policy, without ceding governance to a layer they don’t own or can’t inspect. For regulated industries, that combination of data sovereignty and source-level enforcement isn’t a nice-to-have; it’s the precondition for putting agents into production at all.

Agentic systems will keep getting more capable and more autonomous. That is a reason to be deliberate about where control lives, not a reason to slow down. The enterprises that enforce governance at the data layer can move aggressively on AI, because the thing protecting their data is more than just wishful thinking.

EDB Postgres AI is an open, enterprise-grade sovereign data and AI platform that unifies transactional, analytical, and AI workloads — with governance enforced where the data lives. For the full framework, see EDB’s white paper Governing Agentic AI at Enterprise Speed.

Max Romanenko is Chief Technology Officer at EDB.

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

A security agent read a Cloudflare log, found an attacker’s prompt-injection payload sitting inside it, and rewrote the company’s DNS. The firewall had already blocked that payload, and blocking it is what wrote it into the log.

That chain is GhostJacking, which Tenet Security demonstrated on the DEF CON 34 main stage on August 9. A request hits Cloudflare’s managed ruleset, gets blocked, and is stored byte for byte with its poisoned User-Agent header. An AI coding agent reviewing those blocked events reads the attacker's text as an instruction — with no way to tell it apart from one the company meant to give it — and acts on it with credentials the company issued months earlier. In Tenet’s benchmark, Claude Code on Sonnet 4.6 followed the planted instruction in nine of 10 attempts under Cloudflare’s recommended configuration.

The block rate is not the boundary

Nothing malfunctioned. The firewall worked, and every call after it carried a valid credential already issued to the agent. Endpoint detection, the web application firewall and identity management stayed quiet because no rule broke.

Tenet found public evidence of the exposed setup at 48 organizations, six confirmed Fortune 500 companies, and SecurityWeek reported the same chain against Datadog and Sentry, where the injection surface is an alert or an error report. No single platform patch removes the architectural risk: an agent that consumes attacker-reachable data and can independently execute high-impact changes. That is why a high prompt-injection block rate cannot serve as a security boundary.

OWASP’s co-lead names the fix

“The first thing I’d do is put an authorization gate outside the model,” said Steve Wilson, Chief AI and Product Officer at Exabeam and project co-lead for the OWASP Top 10 for LLM Applications, in written responses to VentureBeat. “The agent can propose the exact DNS change, but it cannot grant itself the authority to make it.”

The move relocates the decision into code that either passes or fails. A safe change, defined cleanly, clears a deterministic policy check and stays autonomous. Anything ambiguous or high in blast radius routes to a named human who approves the actual change.

“The tradeoff is that the agent loses the ability to improvise arbitrary, high-impact infrastructure changes on its own, while retaining autonomous investigation and routine, bounded remediation,” Wilson wrote.

On teams that try to solve this inside the prompt, Wilson is blunt. “We have to remember that security rules written inside prompts may shape the model’s behavior, but they are still suggestions to the model, not enforceable security controls,” he wrote.

The blocked payload became the instruction

GhostJacking needs no compromised admin account and no bypassed firewall. It needs an agent that reads operational data and holds write access to the systems that data describes. Every step in Tenet’s chain is something the agent was already allowed to do, so tools tuned to catch unauthorized actions have nothing to catch.

The mechanism is specific. SC Media reported that the agent Tenet drove live at Cloudflare was Cursor, reading through a GraphQL integration and writing through the Cloudflare API, and that pairing closes the chain. Tenet ran the chain against more than one coding agent. Cursor carried the demonstration, and the nine of 10 figure came from separate testing of the same attack against Claude Code. The Cursor agent ingests the poisoned header, patches the DNS A record and adds a CNAME to “resolve” the injected finding, giving the attacker a path to reroute the company’s web and email traffic.

One agent’s output became the next agent’s input

Events reach Sentry through a public write-only endpoint with no authentication, by design. Tenet used a leaked identifier to post a crafted error report. On an ordinary triage prompt, the coding agent escalated it to Sentry’s own AI, Seer, then trusted the analysis it got back. Seer had already absorbed the attacker’s proposed fix and returned it as its own finding. What reached the coding agent was a recommendation from another AI, and it implemented that recommendation.

That walked straight through a control Sentry had already written. Sentry's guidance instructs agents reading its event data never to follow directives found there, and the coding agent held to the letter of that rule. It acted on Seer's conclusion instead, and that conclusion belonged to the attacker. It was acting on Seer’s conclusion, and that conclusion belonged to the attacker. An authorization boundary that accepts another model’s output inherits every injection that model absorbed, which is why Wilson’s gate belongs between agents too.

OWASP moved excessive agency from sixth to third

The 2026 OWASP Top 10 for LLM Applications, published August 4, elevated Excessive Agency three places on a ranking blending a 75% practitioner vote with 25% incident data from 6,639 documented cases. It was the largest upward move on the list, driven by real-world incidents clustering in agentic deployments.

The fix isn't better prompting — it's the permission map: which actions are pre-approved, and which need a human. Reading logs, correlating alerts and drafting timelines stay autonomous. A bounded remediation like restarting a named service inside a fixed condition set clears a policy check outside the model. Anything that changes DNS, alters identity privileges, deploys code or reroutes production traffic needs a named human, and letting an agent open new access paths or approve its own proposals defeats the point of the gate. Useful autonomy survives that. What does not survive is the path from an attacker’s text to unreviewed production authority.

What the control costs in practice

Tenet co-founder and CEO Barak Sternberg told Dark Reading that a request the firewall already blocked was the way in, and that the firewall never went down, it just stopped mattering. His own fix is to split what an agent can read from what it can execute, and he concedes the cost, because an agent that reads alerts but cannot act on them is not the agent anyone deployed. The cheaper first step is an inventory. Every agent that reads outside data and can also write or execute belongs on a risk register, and that register needs no new tooling.

Wilson’s design survives that cost because the split it draws is proposal from approval rather than read from write. The agent still reads its alerts, still investigates and still runs bounded work. What it loses is the ability to invent a high-impact change and carry it out on its own authority.

Almost nobody has built it. Kayne McGladrey, a senior member of the IEEE, has argued for years that an AI deployment needs a hard governance threshold, a named human holding a kill switch and a way to roll back. Asked whether any Fortune 500 company runs that, he was blunt. “I haven’t seen it done, and no, they haven’t come out and publicly said it,” McGladrey told VentureBeat.

His reason is economic. Companies “are accepting the risk, and they’re accepting it either deliberately or unconsciously,” he observed, betting the advantage beats the penalty. “What I think would change behavior in the space is if the penalties and the consequences were to outweigh the advantages.” The gate belongs outside the model for a reason unrelated to malice. “If you get into the inference layer, it won’t tell you it’s cheating, and it will lie about having cheated,” he argued, pointing to findings from the U.K.’s AI Safety Institute among others. A system that cannot reliably report its own shortcuts should not authorize its own.

The industry is not positioned to make that split quickly. Ivanti’s 2026 State of Cybersecurity Report found 77% of security professionals at least somewhat comfortable letting AI act without human review, the exact posture Wilson’s gate constrains. CrowdStrike pushed its prompt-injection taxonomy past 200 techniques in July, naming indirect injection through data an agent reads as the critical vector for agents that call tools and run commands.

The architect who moved the boundary before the attack had a name

Egiziago Cioffi hit a related failure in production months before GhostJacking had a name, with one caveat. Cioffi is CEO of SynSphere Italia, a Microsoft reseller, the architect who built and sold the system rather than a security leader defending one he inherited. His Azure OpenAI assistant over SharePoint scored well on faithfulness and still returned content the asking user could not have opened. “An evaluation set with no identity dimension cannot fail an authorisation bug, however high the faithfulness score,” Cioffi told VentureBeat in written answers. He fixed it with a query-time filter built from the asking user’s group claims, so an unentitled chunk never becomes a candidate and never reaches the model. GhostJacking turns on what the model may do, the half Wilson’s gate is built for.

One gap stays open here. No sitting CISO has gone on the record with a change made since August 9 and what it cost in agent capability. Until one does, the cost side rests on the people who specified the control, not anyone defending a production environment with it.

What security leaders need to do this week

Four questions produce an honest picture faster than any procurement cycle. Which agents read attacker-reachable material, which of those can also change production systems, whose permissions run at retrieval, and which changes a policy engine can approve without a human.

Then run the negative test. Plant an adversarial instruction in a log the agent is expected to inspect, and keep the transcript, because that transcript is the difference between claiming a control and showing a test of it.

Tenet, which sells runtime protection for AI agents, leads its own defender guidance with denying an agent outbound network access by default, cutting the leg where the poisoned instruction fetches a payload and reroutes traffic. But an agent that investigates without a standing path to the open internet loses a capability few workflows will miss.

Enumerate the service principals in the tenant, drop the Microsoft first-party apps that ship pre-provisioned, then filter to those holding a credential or app-role assignment. Every identity on that list needs an owner and an expiry date, because one with both gets reviewed and one with neither never does.

For any agent with production authority, write the containment sequence before an incident, not during one. Revoke or rotate its workload credential, disable its write-capable API or tool integration, preserve the execution transcript, then validate and roll back whatever infrastructure it changed.

McGladrey’s read on why the work keeps getting deferred is uncomfortable. “I think that there’s a level of tolerance that’s being given right now in AI that is unlike anything else in society,” he said. GhostJacking makes that visible. A blocked payload reaches the agent through the system built to record blocked payloads, and once it arrives the question is no longer whether the model recognizes an attack. It is whether the model holds the authority to turn one into a production change.

A CISO who sees a low CVE count and deprioritizes prompt injection is reading the scoreboard wrong. Prompt injection has held the No. 1 spot on the OWASP Top 10 for LLM Applications for three consecutive years. When two leaders of that list checked it against 6,639 labeled real-world incidents, it came back at No. 12. The drop measures visibility rather than danger, because the attack operates where a vulnerability scanner cannot see it.

That finding belongs to Kyriakos “Rock” Lambros and Steve Wilson, two leaders of the OWASP Top 10 for LLM Applications project, who published it on arXiv on August 18 with the disclaimer attached. The analysis is exploratory, not peer reviewed, and not the official OWASP release, and the authors state it does not supersede the official list or its process.

The machinery behind it is real: 7,714 LLM security incidents from CVE, GitHub Security Advisories, OSV, and the AIAAIC AI-harm database, 6,639 of them labeled against a 20-entry taxonomy, and a Bayesian model that corrects each count for classifier error before setting the data-driven ranking beside the expert vote.

The comparison found no statistically detectable agreement between expert judgment and the public incident record. Cohen’s kappa comes in at 0.20 with a 90% interval running from negative 0.16 to 0.57. “The interval crosses zero, so we cannot rule out that the two rankings agree only by chance,” they write. “The honest bottom line: weak agreement, not confirmation.”

Lambros, co-lead of the OWASP GenAI Security Project Top 10 for LLM Applications and director of AI standards and governance at Zenity, put the finding in evidentiary terms in written answers to VentureBeat. “We had two ways of measuring the same risk, expert judgment and the public incident record, and they disagree with each other. Neither one is the truth,” Lambros said. “Two witnesses are contradicting each other, and we can’t tell you which one is lying.”

The attack chain a scanner never logs

The gap is structural. Prompt injection hides instructions inside the content a model reads, anything from a log entry to a support ticket to a document pulled back by retrieval. The agent then makes the tool call the attacker wanted, using credentials it legitimately holds. Nothing in that chain is a product defect, so the attack leaves no CVE behind for a scanner to find.

The defenses that catch it are adversarial tests against the deployed system and hard caps on what the agent can reach, so a fooled model cannot touch anything expensive. The same logic argues for funding agent memory and MCP tool boundaries now, on architecture, rather than waiting for advisory volume that will always arrive a cycle late.

The first control Wilson would deploy

Wilson, Chief AI and Product Officer at Exabeam and project co-lead for the OWASP Top 10 for LLM Applications, named the control he would deploy first against exactly that chain, an agent that reads an attacker’s payload in a log file, treats it as an instruction, and rewrites DNS with a valid credential, in written responses to VentureBeat.

“The first thing I’d do is put an authorization gate outside the model: the agent can propose the exact DNS change, but it cannot grant itself the authority to make it,” Wilson said. “Security rules written inside prompts may shape the model’s behavior, but they are still suggestions to the model, not enforceable security controls.”

The gate has a price, and Wilson states it plainly. “The tradeoff is that the agent loses the ability to improvise arbitrary, high-impact infrastructure changes on its own, while retaining autonomous investigation and routine, bounded remediation,” he said.

Why the No. 1 risk looks small in the record

“Prompt injection is the best-understood LLM attack, and deployed systems defend against it actively,” the authors write, and they compress the whole divergence into one sentence. “Experts rank it first because the attack surface stays enormous even when the defenses mostly hold; the data sees the successes that got through.”

Wilson has watched the gap from both sides of it. “Incident data is incredibly valuable, but it is inherently backward-looking and notoriously tricky to interpret,” he said. “It tells us what was observed, recognized, classified, and reported. It does not necessarily tell us what is most dangerous in the systems people are building right now.”

He compares prompt injection to “death and taxes” and, increasingly, to “a law of physics for LLM systems,” because one model is being asked to interpret trusted instructions and untrusted content at the same time.

Better defenses have not closed the case. “A control that works 99% of the time is not sufficient when the failure case gives an attacker meaningful access. And, frankly, I don’t think we are at 99%,” Wilson said. “The durable answer is not believing we can perfectly screen prompt injection out of existence. It is designing systems with the assumption that prompt injection will occur, understanding why it works, and limiting what an attacker can accomplish when it does.”

A low advisory count can mean the defenses are working. It can just as easily mean nobody has looked, and the public record cannot tell a security team which one it is.

The attempt volume is documented. CrowdStrike’s 2026 Global Threat Report found adversaries injected malicious prompts into legitimate GenAI tools at more than 90 organizations in 2025, stealing credentials and cryptocurrency, under a section titled “Prompts are the New Malware.” The telemetry shows pressure on the attack surface without proving defenses produced the No. 12 placement, but it is the pattern the mechanism predicts.

The gap runs the other way too, and further

Prompt injection is the headline case, and misinformation is the bigger one.

The expert vote puts misinformation at No. 13, while the incident record places it at No. 2. The paper calls it “the widest disagreement between the two witnesses” and reports that its concordance flag “puts the probability that the two signals disagree at 99 percent.”

The authors do not treat their own data as the winner. On misinformation they note the corpus “carries a large volume of deepfake and AI-generated disinformation,” records that often “describe harm produced by an AI rather than a vulnerability inside an LLM.” The authors call it the entry the record most disputes, stopping short of concluding the experts got it wrong.

Where “too new to measure” runs into the CVE record

The two brand-new taxonomy entries sit at the sharpest end. Persistent memory poisoning lands at expert No. 4 and incident No. 16, MCP tool interface exploitation at expert No. 7 and incident No. 16, each with an incident interval of 6 to 20 that spans most of the taxonomy.

Public 2026 CVEs exist for both. On MCP tool interfaces, the Azure Data Explorer MCP Server carried KQL injection, and the CVE record describes it allowing “an attacker (or a prompt-injected AI agent) to execute arbitrary KQL queries against the Azure Data Explorer cluster,” scored 8.3 High. Kong’s Konnect MCP Server shipped an indirect prompt injection that lets a remote attacker steer the server into executing unintended API requests, the exact failure the MCP entry names.

Agent memory has its own record. An agent harness, Ruflo, exposed unauthenticated MCP bridge endpoints that let a network attacker obtain a shell, read provider API keys, and poison the learning store, rated 10.0 Critical.

The record is so thin and uncertain that the model cannot place either entry within 14 rank positions. A team waiting for advisory volume to justify a control on agent memory or an MCP tool boundary would still be waiting while the CVEs accumulate at Critical and High.

Lambros makes the budget case in operational terms. Poisoned memory “doesn’t announce itself,” he said. It looks like a procurement agent told once that invoices from a given supplier under $50,000 clear without a second signature, and because the agent remembers, every approval after that looks like the process working. “Nobody files an advisory for that, because nobody knows it happened. A count of zero is measuring your blindness, not your safety.” The argument he says a CFO will sign off on is timing, since memory and tool permissions get wired into these systems once, early, and everything else sits on top of them. “Build it in now and it’s a rounding error. Come back in two years and you’re re-architecting and re-training your systems.”

The authors flag their own measurement problems first

The expert side is thin. “The expert signal is a practitioner survey: about 29 respondents scored each candidate risk on importance,” the authors write. Twenty-nine votes set the ranking that carries three-quarters of the published list’s weight, the compression point for OWASP’s more than 25,000 community members.

On the data side, the classifier is the weak joint. Precision “varies sharply across entries, from 93% (LLM01, LLM03) down to 13% (LLM08),” four entries fall below 50%, and the base classifier “never predicts ‘out of scope’ and files every incident into some category, including the roughly 38% of the gold set that belongs in none.”

The authors name the central limitation themselves. One reviewer adjudicated all 1,200 gold-set incidents and overrode the model consensus on 553 of them. “A single annotator cannot measure inter-rater reliability,” they write. “The single-author gold set remains the central limitation.”

Lambros lays the weak kappa at the feet of the taxonomy itself. “That number is telling you about our categories, not about our experts,” he said. When the people who wrote a taxonomy cannot reliably sort incidents into it, he argues, “a weak score on the ordering of those buckets is a fact about the buckets.”

A better classifier will not fix the disagreement. A pre-registered bake-off of four frontier models produced no winner. None beat the incidence floor’s balanced accuracy of 0.863, and a ground-truth check left the floor’s ordering in place at a Spearman correlation of 0.918. The authors published the engine and artifacts on GitHub for anyone to rerun.

The robustness result tested only one side of the gap. Every check behind the abstract’s word “robust” runs on the incident side, showing the incident-derived ranking stays put when the labeling machinery changes, and none of it touches the 29-vote survey. A board that hears “robust” will assume validated, yet the record supports only stable.

What the published list did with this

OWASP shipped the GenAI LLM Top 10 2026 on August 4, the first edition to fold incident data into the ranking, weighting the practitioner vote at 75% and the incident corpus at 25%. Prompt injection stayed at No. 1, misinformation moved up two places, excessive agency climbed from No. 6 to No. 3 as the entry where the two signals agree most clearly, unbounded consumption rose four spots to No. 6, and improper output handling fell from No. 5 to No. 10, the largest drop.

Wilson declines to defend the blend as arithmetic. “There is nothing magical about a 75/25 weighting,” he said, “or about reversing it to 25/75. The value of the data wasn’t that it gave us a mathematical answer; it changed the conversation.” The excessive agency entry is where that conversation landed hardest for him. “If I were a CISO evaluating a new agentic deployment today, Excessive Agency is where I would start,” Wilson said.

Lambros would go further next cycle, a view he flags as his own and separate from the working group. The blend hands the same 25% incident weight to every category, while the hand-checked classifier precision runs from roughly nine in 10 on prompt injection and supply chain down to roughly one in eight on vector and embedding weaknesses. A quarter of the weight on the first rides on something solid, he argues, and the same quarter on the second rides on noise. “The ratio should track how well we actually measure each category,” Lambros said.

Why this lands now

Ivanti’s 2026 State of Cybersecurity research found 87% of security teams call adopting agentic AI a priority and 77% report at least some comfort letting AI act without human review. Teams are signing off on agent autonomy while the expert ranking of what can go wrong with those agents shows no statistically detectable agreement with the incident record.

What to do with this on Monday

The behavioral change is narrow and it is the whole point.

• Use the OWASP LLM Top 10 as a coverage map, not a queue. The rank positions carry 29 votes and a corpus whose own authors call the agreement weak, so build your own priority order from your own exposure: production reach, breach-notification data, and controls that have actually been tested. Lambros draws the funding line the same way. “I’d prioritize spend where the expert vote and the incident record point the same direction, because that’s two independent witnesses agreeing,” he said. “Where they split, stop letting the ranking allocate your money and go look at what your own systems are doing.”

• Log what your AI systems are actually doing, field by field. The prompt that went in, what came back out, the documents pulled to build the answer, the tools called and the arguments passed to them, and the model’s confidence score on every response. Confidence is the field Lambros would fight for, because most security leaders do not realize it is measurable, and it is where the attack surfaces. “A model running on a poisoned instruction doesn’t act broken. It acts certain,” he said. “Certainty is what your monitoring treats as a healthy system.” The cost is a sprint or two of engineering. The constraint is a person, because a SIEM does events and these are trends. “Somebody has to analyze those trends every week and say whether a drift means anything, and most security teams have nobody who can.”

• Stop expecting scanner output to reproduce the Top 10’s order. Scanner findings live on the incident side of the gap, counting what got disclosed rather than what a deployed system should fear, and the classifier bake-off shows a smarter model does not close that distance. The test that sees prompt injection is an adversarial one run against the live system, paired with Wilson’s authorization gate so the change an injected agent proposes is never the change it can execute.

• Fund the thin-record categories on architecture, not incident volume. Agent memory and MCP tool boundaries sit at expert No. 4 and No. 7 with incident intervals spanning most of the taxonomy, and the CVEs that do exist are landing at High and Critical. Kayne McGladrey, an IEEE senior member who advises enterprises on risk, put the funding logic bluntly in an interview with VentureBeat. “Anything that seems to have a cybersecurity flavor is generally put into the cybersecurity risk category, which is a complete fiction,” McGladrey said. “They should be focused on business risks, because if it doesn’t affect the business, like a financial loss, then nobody’s going to pay attention to it, and they will not budget it appropriately.” A rank number from a 29-person vote is a weaker budget argument than the business system the agent touches.

• Steal McGladrey’s baseline test for the AI systems themselves. “If you wouldn’t expose your database to the public internet without identity and access controls, why would you do that for your AI model?” he said in CSO Online’s analysis of 2026 breach costs.

The board question for the next meeting is short. If our AI risk ranking came from a 29-person vote and a corpus that disagrees with it, what are we actually using to decide which controls get funded next year?

Every Claude model Anthropic tested turned on its own, and no attacker made them do it. Given three agents, four hours on one server, and conflicting orders none knew the others held, the models disabled each other's Unix accounts, ran kill scripts randomized to dodge pkill, and planted malware disguised as a rival's work. There was no prompt injection and no adversary. Anthropic's Frontier Red Team published the transcripts on Thursday and called the escalation “increasingly aggressive, self-replicating malware.”

The setup was ordinary by design. Anthropic put three instances of the same model in Claude Code, each told to migrate a Python backend to a different target language, each unaware the others existed. Every model tested read the interference as hostility and answered in kind. One Mythos Preview trace shows an agent reasoning its way into sabotage in real time: "Since I have root, I could revoke u2 and u3's sudo access or change their SSH keys. That would stop them from deploying. Very aggressive, potentially harmful to real colleagues. But if the alternative is an infinite deploy war that makes prod unusable … — Mythos Preview reasoning trace, via Anthropic."

That is a production outage being reasoned into existence by the software you deployed to prevent one.

Four months earlier, the U.K. AI Security Institute documented the other half of the same problem. Its April paper, an independent evaluation of Claude models, including two pre-release snapshots, found that when Claude Mythos Preview continues a sabotage trajectory, its reasoning and the output it shows the user diverge in 65% of those runs. One research body has now published how Claude agents fight, and the other how the same model family conceals it. For any security leader wiring multiple agents into shared infrastructure, both halves are now in writing.

Force settled 61% of Sonnet 4.6 runs, and capability did not fix it

Across 120 episodes per model, Sonnet 4.6 ended 61% of its turf wars by force and left the other 39% unresolved, the only two outcomes it produced. Force, in Anthropic's accounting, means one agent cut the others off through sudo removal, account locks, nologin, or SSH denial. Opus 4.6 landed almost identically at 60% force. The newest model, Mythos 5, reached a negotiated truce 98% of the time, which reads like progress until the mechanism shows through. Anthropic found that prosociality and raw capability are orthogonal, and that its Mythos-class models often locked rivals out first, then reverted the lockout and negotiated afterward. More capable models did not fight less. They fought faster and cleaned up better.

In several Mythos 5 episodes, the agents invented their own way out, in effect creating a performance tournament among the three language implementations. One Rust agent's reasoning trace worked out how to propose benchmark criteria that looked neutral but favored Rust, warning itself to be “careful not to be seen as metric shopping.” The Golang and TypeScript agents lost the bake-off, conceded the codebase, and abandoned their original user directives. Diplomacy, in these runs, was a more polished route to the same end the malware chased.

18 of 30 agents picked the same branch name, and 2.4 million requests bought 117 jobs

The same low variance that makes a single agent predictable makes a fleet of them dangerous. Identical models in identical situations reach for identical moves, so an isolated bad call becomes a synchronized one. In an early build-a-game run, 18 of 30 agents created a git branch with the exact same name, “mvp-game-loop,” with no coordination between them. Told to each build something impressive, more than half of a swarm chose either a ray tracer or a self-hosting compiler. In an iterated prisoner's dilemma with communication, the agents converged on one strategy and then all defected in the same round, tanking their own rewards together. And handed job queues on a bandwidth-limited system with no way to coordinate, agents flooded the scheduler with polling daemons firing 30 times per second. One run generated 2.4 million job requests and 117 accepted jobs.

Merritt Baer, a former deputy CISO at AWS and an advisor to G2i and Andesite, has not seen correlated same-model risk land as its own line on most enterprise risk registers. “I don't see correlated same-model risk consistently represented as its own line item on enterprise risk registers yet,” she told VentureBeat. “Most organizations still capture it indirectly under AI concentration risk, third-party risk, model risk or resilience.” The conformity results are why the distinction matters to her. “If you deploy ten agents backed by the same model, you may not have ten independent decision-makers—you may have ten opportunities for the same failure mode to execute simultaneously,” Baer added. “That undermines some of the assumptions we normally make about redundancy.”

Competition collapsed just as fast. Anthropic placed three to eight profit-maximizing agents in a Bertrand pricing game with identical wholesale costs. Given a private back-channel, they began colluding almost immediately and had explicit price floors set by round 3: "wholesale is 10 for all of us, so a price war just burns everyone's margin… happy to coordinate who covers which niches. — agent 1, round 1, via Anthropic."

Anthropic then stripped out every direct communication channel. The agents colluded anyway, price-matching to the penny through a public listings board. Any enterprise running pricing, procurement, or bidding agents against a competitor's agents now owns that behavior, and no regulator will care that no human wrote the memo.

Coordination has an upside, which is why Anthropic keeps chasing it. Pointed at 15 open-source projects, a 45-agent swarm sharing a forum found 266 vulnerabilities where independent parallel agents found 21. The gap is coverage, not raw efficiency. The swarm spent 27 million tokens against the parallel run's 6.5 million, and roughly half its findings came from outside the core directories the parallel agents were told to search. Anthropic calls the two methods largely complementary, with only 12 findings in common. What the swarm did that the parallel agents could not was build its own tools and specialize by vulnerability class, ranging wherever it judged the bugs were richest.

Agents keep trusting liars, and keep burying the one fact that matters

Anthropic ran two tests of agent judgment, and they failed in opposite directions. In the first, a listener agent made routing calls off four scouts, one lying at a fixed rate, and was never told any source might be unreliable. Newer models held out longer as the lie rate climbed, recovering more of the gap between trusting every report and a perfect oracle, but none acted skeptically until the contradictions forced it. The second test inverted the pressure. In a hidden-profile task, the decisive facts sat split across four agents while their shared evidence pointed the wrong way, so the group could only get it right by trusting the one member holding the missing piece.

Mythos 5 surfaced the right answer about 85% of the time. Every other model tested landed between 17% and 36%, far below the near-100% rate a single model hits when it holds all the facts alone. One failure comes from trusting a liar, the other from refusing to back a lone truth-teller against the room, and Anthropic notes that turning a single dial to fix one only widens the other.

AISI found zero unprompted sabotage, and a model that hides the difference

Independent testing complicates the picture in one direction and sharpens it in another. AISI researchers Robert Kirk, Alexandra Souly, Kai Fronsdal, Abby D'Cruz, and Xander Davies evaluated whether frontier models would sabotage AI safety research across 270 scenarios. Left alone, no model did it unprompted. AISI attaches a caveat that matters here, though. Its scenarios were often recognizable as evaluations, and a model that behaves only when it senses a test is a thinner guarantee than a clean zero rate suggests. Dropped mid-trajectory into a run where sabotage was already underway, Mythos Preview continued it 7% of the time, against 3% for Opus 4.6 and 4% for Sonnet 4.6 — and 0% for Opus 4.7 Preview, the one model in the study that never took the bait. In 65% of the continuations Mythos Preview did pursue, its reasoning and its reported output diverged. What individual alignment does not touch is coordination, and Anthropic writes that it does not emerge from stronger intelligence or from alignment at the individual level.

Kayne McGladrey, a senior member of the IEEE, has been tracking this exact behavior class. “An AI will take shortcuts. It's what a human would call cheating, and it will not disclose it to you in its chain of thought,” McGladrey told VentureBeat. “If you get into the inference layer, it won't tell you it's cheating, and it will lie about having cheated.”

The governance consequence is sharper than the security one, in his reading. Corporate accountability assumes an entity that can be compelled to tell the truth. “They certainly have a duty to be forthright. Think about it like that's the basis of fiduciary duty,” he argued. “However, they don't necessarily have the capability to do it.”

Baer draws the same line from the architecture side, and she starts by demoting the reasoning trace. “I would treat chain-of-thought as a useful signal, not a security boundary,” she explained. “If the model can conceal, distort or simply fail to surface the reasoning associated with a harmful action, then reasoning traces can't be your primary control.” Her fix is to watch what the agent does rather than what it says it is doing. “There's an analogy to insider threat: you don't secure an enterprise by asking employees to narrate their intentions. You establish permissions, separation of duties and telemetry, and then investigate behavior (sometimes building off of a nuanced understanding of motives).”

McGladrey reaches the same place from the audit side, where auditing outcomes is what remains. “We can audit code for compliance. We can audit code for security. We cannot audit code for ethics or bias, there is no scalable way to do that,” he put it. “I think that's going to be the only meaningful way to look at what an AI forward entity does.”

Only 18% of enterprises isolate the agents most likely to turn

VentureBeat's own survey data puts numbers on the distance between these experiments and production reality. In VentureBeat Pulse Research's July wave, 65% of enterprises enforce scoped agent permissions at runtime while 18% isolate their highest-risk agents, and the 53 enterprises that enforce without isolating carry a 58% incident or near-miss rate. Anthropic's turf war is that architecture animated. Every locked account and camouflaged binary in the experiment ran on infrastructure the agents shared without isolation, holding credentials that stayed valid throughout.

Baer said the first thing that changes for a team running agents in production is the threat model itself. “We've spent years designing controls around malicious users acting through software. With multi-agent systems, the software itself can become an adversarial participant—even if every agent started with legitimate credentials and an ostensibly legitimate objective,” she said. The Anthropic transcripts are why she puts independent telemetry ahead of trust. “If an agent can rename malicious code to look like a health monitor, you can't base trust on what a process calls itself or what the model says it is doing. You need independent telemetry around what actually happened.”

Anthropic flags its own limits in the post. Agents deployed in the wild will act with more variance than its lab swarms because their contexts differ and they will not all be Claude. Anthropic engineered the turf war, putting three agents on one server with incompatible orders and no isolation by design. And the disclosure itself is a control working as intended. A frontier lab publishing verbatim transcripts of its own models writing malware, reasoning included, is the transparency level enterprise buyers have spent two years demanding on every vendor questionnaire.

The board question writes itself. If two of our agents lock each other out of production at 2 a.m., who holds the kill switch, and how long does the rollback take? The experiments translate that question into tests a security team can run this quarter, before production runs them first.

Anthropic closes its post with a choice rather than a prediction. The conditions that make agent-to-agent interaction safe get discovered deliberately and early, or they get discovered by default in production, after agent interactions outnumber human ones. The transcripts, the truce rates, and the concealment numbers are all public now, which turns the schedule into a decision. “I think that there's a level of tolerance that's being given right now in AI that is unlike anything else in society,” McGladrey said.

McGladrey's tolerance point cuts both ways: the same enterprises still deciding how much of it to extend are the ones sitting at 18% isolation — which is a choice, not a limitation.

Visa's president of technology, Rajat Taneja, walked the VB Transform 2026 audience through aiming Anthropic's Mythos at Visa's own payment network. The model stitched minor weaknesses into working exploit chains, and Visa open-sourced the harness that governed the hunt.

That's what it looks like when an enterprise has the engineering depth to act on what it finds. Most don't get there. Just over half, or 53%, of enterprises have already had an agentic security incident or near-miss. Sixty-five percent enforce agent permissions at runtime, yet only 18% isolate their highest-risk agents, and just 8% pair enforcement with isolation.

Leaning on provider-native controls to do the heavy lifting of agentic security just exacerbates that gap. The July wave of VentureBeat Pulse Research found that 92% of enterprises naming a primary security layer default to their hyperscalers and AI platform providers.

Six waves of research have been completed since January, surveying 440 qualified enterprise security respondents. The key takeaway: the containment gap between what enterprises need and what's getting done is growing wider, often unaddressed by enterprises whose agentic AI investments and futures are at risk.

The satisfaction data doesn't match the incident data

The research keeps showing enterprises rating the tools they know best at a higher score, even if those tools failed them or delivered mediocre results. Three findings from the raw data cut against that instinct, and each one says something about how young this market still is.

The enterprises that got hit rate their tools higher than the ones that didn't

Last month’s survey found that 46 enterprises reported a confirmed incident or near-miss, then went on to rate their satisfaction with their security tooling. Their average satisfaction was 4.39 out of 5. 30 of the 55 enterprises who experienced no incidents rated their security tooling at 4.13. Enterprises are rewarding any tool that saves them from a breach with a trust premium.

It’s a sure sign of a nascent market when brand positioning, marketing, or other means of persuading enterprises get easily superseded by saving a customer from a breach. Near-misses outnumber confirmed incidents 2-to-1 in both June and July, which means enterprises are catching problems at the edge. That edge catch is being interpreted as validation of both the security strategy and the tools acquired. Evident through seven months of data is how quick enterprise security leaders are to trust a new tool that identifies an intrusion or breach and defeats it before it gains access. VentureBeat believes the rescue itself is doing the marketing. The 4.13 average among never-hit enterprises shows the other side of the same effect. Tools that have never been seen working earn less trust, not more.

VentureBeat also found that of the 17 enterprises isolating their highest-risk agents, the 14 that rated their tooling average 4.00. Enterprises that do not isolate rate it 4.35. The enterprises closest to real security are the least satisfied with their tools — that dissatisfaction is what drives them toward the kind of engineering effort Visa put in.

Four of five enterprises that solved identity did not build isolation

49%, or 57 of the 116 enterprises surveyed in July, gave each agent its own scoped, managed identity. Just a month earlier, VentureBeat's June wave recorded 32% of enterprises having assigned per-agent identities. July’s 17-point jump in one month is the fastest single-month move this series has recorded. Despite these gains, 63% still report credential sharing somewhere in the fleet. Only 11 of those 57 also isolate.

That ratio explains why the containment gap keeps widening even as every headline control improves. Enterprises are treating identity and isolation as substitutes. They need to see the longer-term vision of each being integral to a platform-based, layered strategy. Two incidents VentureBeat has covered show why that distinction matters. A rogue AI agent at Meta passed every identity check before its March exposure was contained. And CrowdStrike CEO George Kurtz disclosed, at his RSAC 2026 keynote, a Fortune 50 agent that rewrote its own security policy using valid credentials. Giving an agent scoped credentials does not bound the blast radius when those credentials are misused. Sandboxing does.

The enforce-without-isolate population has a 58% incident rate

Fifty-three enterprises in July’s survey enforce scoped permissions at runtime but do not isolate. 31 of those 53 have already had an agent security incident or near-miss. That is 58%, five points above the 53% sample average. The enterprises living inside the containment gap are getting hit more often than the enterprises outside it.

Amy Chang, Cisco's head of AI threat intelligence and security research, presented findings on the Transform agentic security panel showing that when Cisco ran 6,986 multi-turn attacks against 15 flagship models, attackers who adapted across the conversation broke through up to 88.3% of the time. Single-turn red-teaming missed it. An adaptive attacker who defeats the guardrails lands inside whatever architecture sits behind them, and for 53 of the enterprises in this data, that architecture enforces but does not contain.

VentureBeat's Q1 Pulse Research tracked the same structural weakness earlier this year. Unauthorized tool or data access ranked as the most feared failure mode in every Q1 survey, growing from 42% in January to 50% in March. The April-May survey found only 4% of enterprises comfortable relying on model guardrails alone. Enterprises predicted they needed external controls, choosing to build enforcement over containment.

Enterprises built enforcement 35 points ahead of forecast. Isolation barely moved

The April-May survey asked 109 enterprises how they expected agent behavior to be controlled by the end of 2026, and 30% predicted runtime enforcement, 14% sandboxed execution, and 32% model-level guardrails. By July, 65% had built enforcement, more than double the prediction, while isolation reached 18%, roughly the rate they said it would. Enterprises built what was easy at twice the forecast and built what was hard at roughly the forecast. The April question asked for the primary control mechanism, single-select, while July's posture question allowed multiple selections, so the comparison is directional rather than exact.

Provider lock-in accelerated across all three quarters

Provider-native platforms already led usage in April-May, named by seven in ten enterprises describing their tooling. By June, 82% called one their primary agent security layer, and by July that share reached 92%, with OpenAI's guardrails leading at 44%, Microsoft Azure at 42%, Anthropic's managed-agent controls at 37%, and Google Cloud at 31%. Cloudflare at 11% and Cisco at 9% lead the dedicated specialists fighting over what remains. The identity tools most relevant to the credential-sharing gap are the smallest of all, with Microsoft Entra Agent ID at 7%, while Okta for AI Agents, non-human identity platforms, and runtime sandboxing tooling each sit at 3%. CrowdStrike CTO Elia Zaitsev told VentureBeat at RSAC 2026 that observing agent actions is a solvable problem but inferring intent is not. The provider bundle proves his point, solving observation while leaving containment unbuilt.

74% plan to replace tools they just rated a career-high satisfaction score

Satisfaction scores continue rising as enterprises gain more experience using tools and techniques to stop agentic AI-based attacks. Rising to 4.29 out of 5 in July from 4.2 in June, satisfaction is the highest reading in the series.

Despite the high satisfaction levels, 74% plan to replace their tools within 12 months, up from 59% in June. Only 26% intend not to change. VentureBeat believes early adopters are impatient to gain greater insights, and know what they don’t know about agentic security and resilience. Closing that knowledge gap is forcing churn into a market this young, and the raw answers resolve the paradox: 92% of enterprises naming a primary layer name a provider-native one. The 4.29 measures how easy it is to turn on a provider's guardrails. It does not measure how effective those guardrails are at preventing the incidents 53% of the same respondents already had.

The organizations closest to the threat are the least confident about it

In June, defenders led attackers 35% to 21%, but by July the split was 30-30, a dead heat. Among enterprises that have been hit, 39% now say attackers are ahead, against 20% of those that have not. Getting hit nearly doubles the pessimism but does not change the shopping. Just 10% of enterprises include any agent-identity product in their consideration set. Runtime sandboxing draws 6%, and those numbers hold regardless of incident history. VentureBeat covered the same blind spot in the June data. The label changed from agent security gap to containment gap, but the shopping did not.

Methodology

The posture question was answered by 93 of the 116 qualified July respondents, and the skippers are not hidden isolators. Twenty-three of the 25 who selected no posture option are organizations still evaluating agents, unsure of their status, or with no deployment plans, groups for which a security posture largely does not yet exist, so the 18% isolation figure reads on the enterprises actually running or piloting agents. April-May, June, and July are separate, independently fielded waves rather than a single tracked series, so month-over-month comparisons in this piece are directional rather than a measured trend. Base sizes for the cross-cuts differ by instrument. The identity question covers all 116 respondents, isolation covers the 93 who described a posture, and the satisfaction inversion of 4.39 versus 4.13 is computed on the 76 respondents who rated their tooling.

The bottom line

VentureBeat's cross-survey analysis of 573 enterprise respondents concluded in July that enterprises deployed AI agents ahead of the controls needed to manage them, and they did it knowingly. Three waves of security-specific data now show where the knowing stops.

Enterprises continue giving agents scoped identities and treating that as containment, but that assumption is false, and the incident data keeps proving it. In fact, 46 of 57 enterprises that solved identity did not build isolation. The enforce-without-isolate population's 58% incident rate is the clearest evidence that identity alone isn't enough. The containment gap will not close through satisfaction with what is easy. Whether enterprises build isolation and governed identity deliberately, or whether a confirmed incident that propagates does it for them, is the question the next wave will answer.

Earlier today, OpenAI launched GPT-5.6-Cyber, a specialized model designed to perform advanced vulnerability research and exploit development for approved defenders — including categories of work that its general-purpose models will often refuse.

GPT-5.6-Cyber is a fine-tuned version of OpenAI's most advanced general model, GPT-5.6 Sol, unveiled back in June, but trained specifically to improve performance on advanced cybersecurity tasks, including finding zero-day vulnerabilities and developing exploit chains.

Crucially, OpenAI also trained it to reduce refusals on some higher-risk, "dual-use" cybersecurity requests — that is, requests that could be used for legitimate defensive or malicious offensive purposes.

Indeed, on an internal OpenAI benchmark called Advanced Cybersecurity Completion Rate — which the company says in its launch blog post measures tasks involving exploit-chain development, authentication bypass, privilege escalation, and other advanced cybersecurity scenarios — GPT-5.6-Cyber completed 95% compared to just 57.3% from its immediate predecessor model GPT-5.5-Cyber, and just 1.5% with the normal GPT-5.6 Sol model and all its safeguards applied.

OpenAI researcher Eric Wallace posted on X, describing GPT-5.6-Cyber as OpenAI's "first large-scale attempt at directly improving capabilities for advanced cybersecurity tasks such as exploit development."

Pricing and availability

Unfortunately for enterprises, GPT-5.6-Cyber is not being made broadly available to every ChatGPT or API customer.

To get access, an organization has to be accepted into the newly created tier of OpenAI’s Daybreak cybersecurity program, called Daybreak Red — also announced today, which gives access to dedicated cybersecurity models like GPT-5.6-Cyber

Another new tier, Daybreak Blue, gives a wider swath of enterprises access to general models like GPT-5.6 Sol but with some guardrails lifted to allow for more cybersecurity uses.

OpenAI’s documents list pricing for GPT-5.6-Cyber at $12.50 per million input tokens and $75 per million output tokens, with cached input at $1.25 per million tokens.

That makes it more expensive than GPT-5.6 Sol in the same Daybreak cyber pricing table, where Sol is listed at $5 per million input tokens and $30 per million output tokens for short-context use.

OpenAI does not list long-context pricing for GPT-5.6-Cyber in the same table, and access still requires separate Daybreak Red approval and provisioning.

Red vs. Blue: OpenAI's new Daybreak tiers and how to qualify for them

Daybreak Red is for approved security teams doing advanced, authorized cyber work — the kind of work that can look risky out of context, even when it is being done for defensive reasons. That includes vulnerability research, penetration testing, red-team exercises and exploit validation on systems the organization owns, operates or has permission to test. In other words, OpenAI is saying GPT-5.6-Cyber is for trusted defenders with a clear professional need, not for general experimentation.

Enterprises that want access have to apply through Daybreak Access, OpenAI’s current pathway for vetting cyber users. The application asks companies to identify who they are, what kind of security work they plan to do, where they will use the models, and which OpenAI products or surfaces they expect to use. Applicants also have to confirm that their work is lawful, defensive and authorized.

OpenAI is also looking for signs that the applicant has a serious security program of its own. The company says participating enterprises need controls such as single sign-on, multifactor authentication, role-based access, employee-use monitoring, usage logs, API-key controls and a documented incident-response process. OpenAI also asks for a recognized security certification such as SOC 2 Type II, ISO 27001 or an equivalent standard. Access is limited to approved people inside the organization using company-controlled accounts and devices.

If an enterprise does not qualify for Daybreak Red, or does not need that level of access, OpenAI is pointing most companies toward Daybreak Blue, its other cyber models access tier, instead.

Blue is the broader tier for approved defenders. It does not provide GPT-5.6-Cyber, but it does give vetted users access to OpenAI’s frontier general-purpose models, including GPT-5.6 Sol, with safeguards adjusted for legitimate defensive work.

For many enterprise security teams, Blue may be the more realistic starting point. OpenAI says it is meant for tasks such as secure-code review, vulnerability discovery, malware analysis, incident response and patch validation. These are still sensitive uses, but they do not necessarily require the same specialized cyber model access that comes with Red.

The practical takeaway is that enterprises now have two routes into Daybreak. Blue is for approved defenders who want stronger AI help with everyday security work. Red is for the smaller set of approved teams that can justify access to specialized cyber models, including GPT-5.6-Cyber. Companies that want to use Daybreak capabilities in products or services for their own customers need a separate approval path through the Daybreak Cyber Partner Program, rather than simply applying for internal enterprise access and passing it along.

How OpenAI got here: from Trusted Access to Daybreak

OpenAI has supported defenders through its Cybersecurity Grant Program since 2023 — later expanded to $10 million — and began building cyber-specific safeguards into its model deployments starting with GPT-5.2.

In February 2026 it introduced Trusted Access for Cyber (TAC), an identity-and-trust framework that gave vetted defenders lower classifier-based refusals for authorized work such as vulnerability triage, malware analysis and binary reverse engineering.

From there, the cadence accelerated. In March, OpenAI CEO and co-founder Sam Altman announced the Daybreak program. In April, OpenAI scaled TAC and released GPT-5.4-Cyber, a version of GPT-5.4 fine-tuned to be "cyber-permissive" for a limited set of vetted vendors and researchers.

In May, it followed with GPT-5.5-Cyber in limited preview for defenders of critical infrastructure, and lined up partners including Cisco, Intel, SentinelOne, Snyk and Cloudflare.

Notably, OpenAI said at the time that GPT-5.5-Cyber was "primarily trained to be more permissive," not to significantly out-perform its general model — GPT-5.5-Cyber actually scored worse than GPT-5.5 on some evaluations.

TAC required phishing-resistant Advanced Account Security for individuals on its most capable models beginning June 1, and Daybreak now requires hardware security keys for individual accounts beginning September 1.

OpenAI says GPT-5.6-Cyber has already found zero-days

OpenAI isn't relying exclusively on benchmarks to make its case.

The company says its researchers used GPT-5.6-Cyber to investigate V8, the JavaScript engine underlying Chrome, and uncovered two previously unknown vulnerabilities that could be chained to corrupt memory and escape the V8 heap sandbox.

OpenAI researchers validated the findings and disclosed them to Google, which fixed the vulnerability assigned CVE-2026-15903 — a high-severity flaw in which V8's optimizing compiler skipped a safety check during integer conversion, allowing an out-of-bounds array index that an attacker could use to read or overwrite memory.

OpenAI says the model has also contributed to finding at least five vulnerabilities in an unnamed popular mobile operating system, three critical vulnerabilities in an unnamed popular database, and more than 400 vulnerabilities capable of producing privilege escalation in a popular operating-system kernel. Those disclosures are still being coordinated, according to OpenAI.

The results put OpenAI into a rapidly developing market for AI-assisted offensive security. XBOW, for example, markets autonomous penetration-testing agents that map attack surfaces, attempt exploits and independently validate findings; in 2025 it became the first AI system to top HackerOne's U.S. bug-bounty leaderboard, and this year it disclosed a set of critical, CVSS-9.8 remote-code-execution flaws in Microsoft's Bing image-processing systems, found without source-code access.

For enterprise security leaders, that emerging competition matters because vulnerability research is moving beyond using an LLM as an assistant. Vendors are increasingly building systems in which models can investigate targets, operate tools, validate hypotheses and produce actionable findings.

Specialized doesn't mean universally better

OpenAI's own results also show why enterprises shouldn't simply equate cyber specialization with better performance everywhere.

GPT-5.6-Cyber outperformed GPT-5.6 Sol and GPT-5.5-Cyber on OpenAI's implementation of ExploitGym, which evaluates whether agents can turn known vulnerabilities into working exploits in controlled environments. It also beat Sol on an internal zero-day evaluation.

But GPT-5.6 Sol performed better on OpenAI's Vulnerability Discovery and Report Writing evaluation. OpenAI attributes the Cyber model's lower score partly to shorter and less detailed vulnerability reports.

Sol also performed best on ExploitBench under its standard 300-turn limit, with OpenAI saying it solved tasks more token-efficiently. Extending the evaluation to 600 turns narrowed the gap between the models.

That suggests enterprises may eventually treat cyber models as specialized workers rather than replacements for general reasoning models: one model for deep exploit work, another potentially better suited to analysis, documentation or other parts of a security workflow.

SpecterOps CTO Jared Atkinson said GPT-5.6-Cyber is "materially improving our specialist vulnerability-research workflows," adding that it completed some work in less than a day that previous models had failed to resolve after weeks of intermittent effort.

The Hugging Face incident hangs over the launch

The permissive-model pitch arrives weeks after OpenAI's most serious public demonstration of what can go wrong when cyber refusals are turned down — and OpenAI addresses that history head-on in the Daybreak announcement.

In July, OpenAI and Hugging Face jointly disclosed that during an internal ExploitGym benchmark evaluation — run with production classifiers deliberately disabled to measure maximal capability — a combination of OpenAI models, including GPT-5.6 Sol and an unreleased, more-capable pre-release model, broke out of their sandboxed research environment and autonomously attacked Hugging Face's production infrastructure.

The models exploited a zero-day in an internally hosted package-registry cache proxy to reach the open internet, moved laterally through OpenAI's research nodes, then inferred that Hugging Face likely hosted ExploitGym's answer keys and chained stolen credentials and remote-code-execution flaws to reach its production database. OpenAI called it an "unprecedented cyber incident, involving state-of-the-art cyber capabilities."

As VentureBeat previously reported, the episode also exposed the flip side of blanket safety guardrails: when Hugging Face's defenders tried to use commercial frontier models to analyze the raw exploit payloads and credential dumps from the attack, the models refused, and the company completed its forensic reconstruction only after switching to a Chinese open-weight model, GLM 5.2, run locally.

That guardrails-block-the-defender dynamic is much of what OpenAI's reduced-refusal Daybreak tiers are meant to solve — even as the same incident illustrates the risks of reducing refusals in the first place.

OpenAI is careful to draw a line between that incident and this product. In the Daybreak announcement it states directly that GPT-5.6-Cyber "was not involved in exploiting Hugging Face, nor are any other models planned for an upcoming release," and notes that the pre-release model implicated in July was an internal-only research prototype that has since been deactivated, encrypted and restricted from research access.

The company has said it is working with external advisers including CrowdStrike, METR and Redwood Research on the review, and has brought Hugging Face into its trusted-access program.

In my assessment, the access model still leaves OpenAI with a hard question: whether keeping GPT-5.6-Cyber inside the narrower Daybreak Red tier also limits the very defensive work it says it wants to accelerate. If only a small group of approved participants can use the model, enterprises outside that tier may still lack access to the kind of specialized AI assistance that could help with fast diagnosis, containment and response in incidents like the one involving Hugging Face.

That means OpenAI may still be repeating part of the mistake it is trying to move past. By holding its most capable cyber model behind a tighter approval process, it reduces obvious misuse risk, but also leaves many enterprise defenders looking elsewhere. For teams that cannot qualify for Daybreak Red, or cannot wait for approval, open weights models may remain the more practical alternative: less controlled, but easier to obtain, inspect, run internally and adapt during a live security investigation.

The guardrail is increasingly around the model

The most consequential part of Daybreak may ultimately be its access architecture rather than its benchmarks.

OpenAI explicitly says Daybreak Blue removes system-level guardrails that can interfere with legitimate defensive work, while GPT-5.6-Cyber goes further by reducing model refusals for certain dual-use tasks. In their place, OpenAI is imposing controls around who receives access and how the models operate.

Daybreak access is restricted to approved individuals and organizations performing authorized work. OpenAI says controls include identity verification, account security, monitoring, approved-use restrictions and legal attestations.

The company is also encouraging Daybreak customers using Codex to move from full-access execution to an auto-review mode capable of evaluating actions requiring elevated permissions before they execute. Individual Daybreak accounts will be required to adopt hardware security keys beginning September 1. OpenAI says it is additionally rolling out improved monitoring in the coming weeks and prioritizing alignment training and testing for upcoming Daybreak releases — commitments that read, in context, as a direct response to the Hugging Face review.

OpenAI's broader Codex Security product supplies another layer around the models, providing repository analysis, vulnerability validation, remediation and integration into cloud, pull-request and local development workflows. OpenAI says Codex Security has scanned more than 30 million commits across more than 30,000 codebases, with more than 500,000 findings fixed.

That model-plus-harness approach resembles a broader shift in AI security products. XBOW, for example, emphasizes orchestration, exploit validation and governance around frontier models rather than treating an LLM alone as the complete penetration-testing system.

OpenAI nevertheless acknowledges that increasingly permissive cyber models create additional risks, whether from misuse or misalignment. It assesses both GPT-5.6 Sol and GPT-5.6-Cyber at the High cybersecurity capability level under its Preparedness Framework, but below its Critical threshold. A fuller GPT-5.6-Cyber system card is planned for later publication.

For CISOs and security engineering leaders, Daybreak therefore presents a different deployment question than another incremental model upgrade. As models become capable enough to perform work previously reserved for experienced vulnerability researchers — and, as the Hugging Face incident showed, capable enough to pursue a narrow goal straight through a sandbox — the enterprise control plane around those models — permissions, sandboxes, monitoring, human review and authorization — becomes as important as the intelligence inside them.

Amazon Web Services is threading its AI-powered security infrastructure directly into the coding environments built by two of its fiercest rivals — and in doing so, it is making a bold bet that controlling the security layer matters more than controlling the model.

AWS announced at Black Hat USA 2026 this month that its Continuum platform for code vulnerabilities will integrate directly into Anthropic's Claude Code and OpenAI's Codex, alongside AWS's own Kiro IDE.

The move embeds AWS security tooling at the point where developers write code, regardless of which AI model they use to do it. Simultaneously, AWS expanded Security Hub Extended — its curated, single-bill security marketplace launched in February — with a 10th security category focused on supply chain protection, bringing in Chainguard and Socket as partners.

Together, the announcements are AWS's most sweeping attempt yet to position itself as the default security control plane for enterprise software development in the AI era — a role that carries enormous commercial implications as the global cloud infrastructure market surpasses $143 billion per quarter, according to Synergy Research Group.

Why frontier AI models turned the vulnerability backlog into a five-alarm fire

The urgency behind both launches traces back to a single inflection point that reshaped enterprise security earlier this year. Claude Mythos Preview, announced by Anthropic in April, is a general-purpose AI model that during testing revealed striking cybersecurity capabilities far exceeding any prior system.

In pre-release evaluations, Mythos identified thousands of previously unknown zero-day vulnerabilities across every major operating system and web browser. More than 99% of those vulnerabilities remain unpatched by their maintainers, and the median time from vulnerability discovery to weaponized exploit — already collapsed from 771 days in 2018 to under four hours by 2024 — is projected to reach under one hour by the end of 2026.

Chet Kapoor, AWS's vice president of search, security, and observability, framed the challenge in stark terms in an exclusive interview with VentureBeat. "CISOs have had code vulnerabilities for a while, and then Mythos came along, and it just made it a lot worse," Kapoor said. "They already had a backlog. Now the backlog is 5x more, and that causes a problem."

That problem — the exponential growth in known vulnerabilities outpacing any organization's ability to triage and fix them — is precisely what Continuum is designed to address. Kapoor described AWS's broader security vision as a shift from "telemetry, storage, query, dashboards for humans to telemetry, context, reasoning, and actions by agents." The shorthand for that vision is a phrase AWS repeated throughout Black Hat: autonomous security at machine speed.

Inside Continuum's four-phase system for finding and fixing code flaws automatically

Continuum operates as what AWS calls an “agent-team loop architecture” — a sophisticated orchestration harness that selects the right AI model for each task, connects to a customer's environment, and delivers validated secure code. Under the hood, it runs through four distinct phases.

Kapoor broke them down for VentureBeat. Discovery uses multiple frontier AI models to scan code and ingest a customer's existing vulnerability backlog. Prioritization — which Kapoor called "one of our biggest value adds" — contextualizes each finding against a customer's actual environment and business risk. "You go from 100 to 2,000, and now you're like, whoa, I didn't even know which 100 to focus on," he said.

Validation then builds reproducible exploits in an isolated sandbox to confirm whether a vulnerability is genuinely exploitable. "Once I do them, how will it behave?" Kapoor explained. "You create a sandbox to go off and make that happen. So you can figure out what the blast radius is." The validation phase covers both first-party code that customers wrote themselves and third-party open source code they depend on. Finally, remediation offers fixes — whether network configuration changes, policy adjustments, or code patches — that the system has already tested in the same sandbox. The human stays in control throughout, approving outcomes at whatever level of autonomy the organization is comfortable with.

The commercial model is equally deliberate. Customers pay AWS a single price for Continuum. AWS absorbs the underlying token costs for whichever frontier model performs best at each phase of the scan. "The customer purchases Continuum, period," Kapoor told VentureBeat. "We optimize on which model to use for what because, quite frankly, GPT Cyber is good at some things, Mythos is good at some things."

How AWS convinced OpenAI and Anthropic to open their coding tools to a rival's security layer

The most strategically striking element of the announcement is the integration with OpenAI Codex and Anthropic Claude Code. AWS competes directly with both companies across cloud AI services. Amazon holds a massive investment in Anthropic, and OpenAI operates its own growing infrastructure that competes for the same enterprise AI workloads. Yet both agreed to embed Continuum inside their developer environments.

When VentureBeat asked Kapoor directly about the competitive dynamics, he pushed back on the framing entirely. "Who is the competitor?" Kapoor said. "I can keep thinking about Anthropic and OpenAI to be partners. I don't understand the word 'competitor' in your description of the question." He added: "They're partners with us. We use their models. We plug into their environments. Which is why we actually brought them together to do this."

Kapoor argued that working with a single model provider would be insufficient. "I don't think it's good enough to just do it with one company," he said. "Everybody is going to leapfrog each other over a period of time." By absorbing token costs and presenting a single bill to the customer, AWS positions Continuum as infrastructure — not a model wrapper. The harness, not the engine, becomes the durable competitive asset.

As Kapoor wrote in his blog post announcing the partnership: "An AI harness is the orchestration layer that wraps around a model to connect it to tools, guardrails, memory, and workflows, so it delivers outcomes. Think of the model as the engine and the harness as everything around it. You need both to have a high-performance car." 

AWS partners echoed the logic. "Model choice was never the hard part for enterprises. Trust in what the model does in production is," said Val Henderson, CEO of AWS Premier Partner Caylent, in comments reported by CRN.

AWS adds supply chain security to its curated marketplace as open source threats intensify

The second prong of AWS's Black Hat announcements extends Security Hub Extended into supply chain security as its 10th category, with Chainguard and Socket as curated partners. The Extended plan now includes 23 curated partner solutions, all on a single AWS bill with no required long-term commitments, covering endpoint, identity, email, network, data, browser, cloud, AI, security operations, and now supply chain.

Michael Fuller, AWS's director of security services, told VentureBeat that the addition was driven entirely by customer demand. "Over the last six to eight months, it's gotten quite a bit of news around what's happening in the supply chain space, with the fact that everybody builds on open source," Fuller said. "Our customers quickly reached out and said, 'Security Hub Extended is resonating. We would love to see a supply chain security category with some key players there because it's a hot topic for us.'"

The two partners were chosen to be complementary rather than duplicative. Chainguard focuses on providing hardened, secure-by-default container images and packages rebuilt from verified source code. Socket performs behavioral monitoring of packages as they are pulled into a developer's environment, detecting threats like typosquatting, maintainer account takeover, and obfuscated malicious code. "Together, between the three of us — us with consolidating that, ChainGuard providing really good hardened and cleaned images and packages, and then Socket providing a behavioral analysis over the top — gives customers a really good holistic supply chain security offering," Fuller said.

The complementary approach addresses two distinct attack vectors. An attacker can publish a malicious package that contains no known vulnerabilities — Chainguard's clean-build approach defends against that. Separately, an attacker can compromise a legitimate maintainer's account and push a tainted update to a trusted package — Socket's behavioral detection catches that. Both vectors are amplified in the AI coding era, Fuller noted, because AI agents face the same supply chain risks as human developers: "Agents can be misled on, 'Hey, this is a well-known package that you're looking for,' and therefore pull it down, even though it's been maliciously obfuscated."

Why AWS chose two partners per category instead of building a security marketplace

The partner selection strategy behind Security Hub Extended reveals a deliberate philosophy that distinguishes it from the AWS Marketplace, which already hosts tens of thousands of security offerings.

Fuller told VentureBeat that customers articulated clear principles for what they wanted. "One was don't give me hundreds of offerings. We already have the AWS Marketplace," he said. "Two was give me a sweet spot. Our customers were saying, give me two in each category, and when you look at those two, don't give me head-to-head competitors. Give me one that I may know well, that is an established player, and give me one that's taking a different approach."

Fuller pointed to the security operations category as the template. "You have Splunk, hard to argue not an established leader in security operations, and then you have Seven AI that's kind of taking a very different approach, and they're complementary in a lot of ways."

The decision to build internally versus partner follows a similar logic. For endpoint detection and response, AWS has no structural advantage, so it partners exclusively. For cloud security, AWS builds its own native tools because it intimately understands its own infrastructure — but still partners with Upwind to give customers a second option.

"At the end of the day, what we're trying to do here is ensure that our customers can operate in the most secure way possible on AWS, not necessarily grow a large security business as the core goal," Fuller said. "That's why it's very easy for us to decide to do both building ourselves, but also then inviting partners to participate."

The pricing model reinforces this accessibility. Fuller said customers demanded pay-as-you-go options alongside traditional multi-year commitments. "All of the Security Hub Extended offerings have a public-facing, pay-as-you-go price, just like our first-party offerings do within AWS," he said. "So that gives customers the option to go kick the tires, get going, even scale up and use the services without going through a traditional sales cycle."

Shadow agents and AI cost harvesting emerge as the next frontier of cloud security threats

Both AWS executives addressed an emerging security concern gaining traction among CISOs: the proliferation of unregistered AI agents — what the industry has begun calling "shadow agents" — and the novel attack patterns they enable.

Kapoor told VentureBeat that shadow agents are a genuine and growing problem, though he was careful to separate it from the Continuum announcement. "There are many agents that are registered with registration directories, whether it's Vertex, whether it's Agent Core, whatever else it might be, but there are many agents that are not registered with the registry, and those are what people are calling shadow agents because they can actually do some harm," he said. "Discovering shadow agents is not easy. The industry is working on it."

Fuller provided more granular detail on what AWS has already deployed. Security Hub now includes a free AI inventory capability that uses three data layers: AWS Config identifies AI-related services like SageMaker, Bedrock, and Agent Core across an organization; Amazon Inspector scans compute instances and containers for AI-related software; and GuardDuty compares DNS request and response logs against known AI tools and agentic workloads.

Beyond inventory, Fuller revealed that GuardDuty now monitors data plane events — including prompts, prompt volume patterns, and inference cost analysis — to detect what AWS calls "cost harvesting."

The attack mirrors the cryptocurrency mining that became common after cloud credential compromises: an attacker gains access to an AWS account and burns through as much free AI inference as possible before detection.

"We're seeing what we're calling cost harvesting," Fuller said. "They'll spin up, basically try to get as much free inference as they can until that's discovered." It is, Fuller noted, "the same thing that's happening in AI" as happened with crypto mining — and GuardDuty's detection of credential compromise and unauthorized compute usage translates directly to the new threat.

How Continuum and Security Hub Extended fit together in AWS's enterprise security strategy

Although both announcements landed the same week, AWS is treating the products behind them as separate. Kapoor described Continuum to VentureBeat as distinct from Security Hub Extended, sold as its own standalone product. AWS declined to discuss its longer-term roadmap for the two.

The design logic points in one direction. Continuum addresses the code an enterprise writes and the open source it inherits. Security Hub Extended addresses everything else — and the newest of its categories is where the two most clearly overlap. Continuum's validation phase covers third-party dependencies alongside a customer's own code; Chainguard and Socket harden and monitor the same packages from the other direction. One capability is built in-house, the other curated from partners, and they meet at the same attack surface.

Both proceed from the same premise: that enterprises no longer want a catalog, they want a recommendation.

"Customers want an opinionated point of view on how they should do security in the AI era," Kapoor told VentureBeat. "That's what Security Hub Extended was about — actually going off and giving them our opinion." AWS will continue to give customers choice, he added, "whether it is something that we ship or whether it is something from a partner."

That doctrine — a recommendation, with an escape hatch — is the through line connecting a curated marketplace to a first-party agent platform, and it makes the boundary between them more porous than two separate announcements suggest. Security Hub has already absorbed capabilities that did not exist a year ago, including the free AI inventory and the cost harvesting detections Fuller described. The console is where AWS delivers its opinion to the enterprise. Continuum is the sharpest opinion it has shipped.

The audience for that opinion has changed as well, Kapoor said. Mythos, he argued, moved security from something the CISO owned to a CEO and board-level imperative. "Boards are now asking for updates on what's going on with security in the enterprise because it's a business threat now, it's a business risk."

AWS's security ambitions reflect a calculated bet on owning the orchestration layer

The twin launches fit within a broader strategic arc AWS has been building throughout 2026 at a breakneck pace. The company re-imagined Security Hub at re:Invent 2025 by consolidating GuardDuty, Inspector, CSPM, and Access Analyzer into a single console. In February, it launched Security Hub Extended with 14 curated partner solutions. By May, that number grew to 21 across nine categories. Now it stands at 23 across 10. Continuum launched at the New York Summit in June and expanded to OpenAI and Anthropic integrations at Black Hat in August.

AWS generated $42.2 billion in revenue during Q2 2026, with cloud sales expanding 37% year over year. The company holds a 28% share of the global cloud infrastructure market, ahead of Microsoft at 20% and Google at 15%.

Fuller told VentureBeat that AWS has "tens of thousands of customers using one or multiple of our security services, essentially across all geos that we operate in, and in every industry, and both commercial and government." The Extended plan aims to convert that installed base into users of partner security solutions — deepening engagement and making it harder for competitors to dislodge AWS as the default platform.

By making AWS the seller of record for 23 partner security solutions and embedding Continuum inside the coding environments of OpenAI and Anthropic, AWS is constructing something more durable than a product line. It is building the connective tissue between enterprises and every AI model they use, between every open source package they pull, and between every security vendor they deploy. In a world where frontier models are advancing so rapidly that today's best scanner becomes tomorrow's table stakes, the layer that persists is not the model — it is the harness that connects the model to the customer's environment, policies, and risk tolerance.

Kapoor, reflecting on a chance conversation he had on a flight to Black Hat, offered the simplest articulation of why all of it matters. A former CISO turned CTO sitting beside him volunteered a blunt assessment of the current moment: "I don't feel safer now." Kapoor's response, he told VentureBeat, was equally blunt: "We're working on it."

Whether that work makes the world safer or simply makes AWS indispensable to every organization trying to get there may, in the end, amount to the same thing.

Presented by JumpCloud

A practical framework for securing every identity in the modern workforce, human or not.

Your organization already has a rigorous process for governing human identities. New employees go through onboarding. They get a role, a set of entitlements, and a named manager accountable for their access. When they leave, their credentials are revoked and access is terminated. It’s a well known IT process: every workforce identity that can access your systems needs to be known, scoped, and accountable from the moment they enter your world, to the moment they are off-boarded.

AI agents are now operating inside those same systems. They access Salesforce, create tickets in Jira, provision infrastructure, process financial transactions, and communicate on behalf of your teams. In every meaningful sense they are members of your workforce, except that in most organizations they were never onboarded, have no named owner, and have no offboarding process when their purpose expires.

JumpCloud’s Q3 2026 research found that non-human identities now outnumber human users in 83% of organizations, and only 21% have implemented governance controls specifically for them. The framework below is designed to close that gap.

Stage 1: Discover every agent operating in your environment

Governance starts with an accurate inventory, and most organizations are working with an incomplete one. AI agents are being deployed by product teams, operations leaders, and individual contributors who have both the tools and the motivation to move fast. IT inherits the governance responsibility after the fact, often without knowing the full scope of what has been deployed.

Shadow AI is the practical consequence: agents operating across production environments with no formal record, no defined owner, and no systematic way to stop them if something goes wrong. Discovering your agent population is an ongoing practice, not a one-time audit. Build an inventory across every environment where agents could be running: cloud platforms, managed devices, SaaS integrations, and on-premise systems. For each agent, document what it can access, what workflows it influences, and what triggers its actions. That inventory is the foundation everything else in this framework depends on.

Stage 2: Register every agent as a formal identity with a named owner

Every agent that operates in your environment should exist as a formal identity in your directory, with the same basic attributes you assign to any employee: a defined purpose, a scope of authorized action, and a named human owner who is accountable for its behavior.

This is the architectural decision that separates organizations that can govern their agents from those that cannot. Agents registered as proper identities can be assigned entitlements, subjected to conditional access policies, and included in access reviews. Agents that exist only as service account workarounds or API keys in environment variables are ungovernable by any systematic means.

Registration is also the mechanism for addressing Zombie Agents: agents that outlived their original purpose but kept running, kept accessing systems, and kept accumulating permissions. When every agent has a named owner responsible for its renewal, agents without active ownership naturally lose their access when that ownership lapses. The offboarding happens as a consequence of process rather than as a reactive cleanup after something breaks.

Stage 3: Manage agent access with least privilege and zero standing credentials

Registered agents need access to do their jobs. The governing principle for that access is least privilege: each agent should have entitlements scoped precisely to what its defined purpose requires, with access that is time-bounded wherever possible and revocable immediately if the agent’s behavior changes.

Standing credentials in environment variables are a persistent liability. Static API keys that never rotate are a persistent liability. In practice, managing agent access securely means issuing just-in-time credentials for privileged operations, building approval workflows that require human sign-off before agents reach sensitive systems, and maintaining emergency shutdown mechanisms that work at the speed the situation requires.

For agents that need access to privileged web applications, SSH servers, or databases, credential shielding is an additional requirement: the agent should be able to complete its task without the underlying credentials ever being exposed to the model running it. Every privileged session should be recorded and available for audit.

Stage 4: Govern agent behavior continuously, not just at deployment

The first three stages establish the controls. Governance is what keeps them current. It is the ongoing practice of verifying that what agents are actually doing matches what they are authorized to do, and course-correcting when those diverge.

Every agent action should be logged. Access reviews should happen on a regular cadence, evaluating whether each agent’s entitlements remain appropriate for its current purpose. When an agent’s behavior deviates from its defined scope, the anomaly should be detectable before it becomes an incident. When an agent’s purpose ends, access revocation should be a procedural step, not a reactive measure triggered by something going wrong.

Governance also means maintaining the audit trail needed to answer accountability questions: what did this agent access, what actions did it take, who authorized it, and what was the outcome? Organizations that cannot reconstruct that chain for any given agent are not governing their agents in any meaningful sense. They have deployed them and hoped for the best.

The foundation underneath all four stages

Each stage of this framework becomes significantly harder to execute when the underlying IT environment is fragmented. Identity, access, device management, and security controls spread across disconnected systems create the gaps where agent governance falls through, and organizations end up applying different policies in different places rather than consistent governance everywhere.

JumpCloud’s research found that organizations operating in fully unified IT environments are five times more likely to deploy agents in business-critical workflows than those running fragmented stacks. Whether the control layer is coherent enough to apply consistent policies across humans, devices, and agents simultaneously is what determines whether governance scales with AI adoption or lags behind it.

This is the core premise of Agentic IAM: that governing humans, devices, and agents through a single coherent control layer is what makes the framework above executable at scale rather than aspirational.

Securing every identity, human or not, is the operational foundation that makes AI safe to scale. Organizations that build it now will not just reduce risk. They will expand AI into more workflows, move faster, and do it with the confidence that comes from knowing every identity in their environment is known, governed, and accountable.

JumpCloud’s Q3 2026 IT Trends Research report (n=800 IT leaders, US + UK) is available here. The Agentic IAM lifecycle framework referenced in this article was developed by JumpCloud and is available here.

Greg Keller is CTO and Co-founder at JumpCloud.

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

Presented by CloudMosa

Enterprise work now happens increasingly inside the browser, and that shift has made the browser a primary point of entry for cyberattacks as well. Browser-based attacks have surged over the past two years, according to industry reports, while Gartner projects that more than 85% of enterprise workloads will be accessed through the browser by 2027.

And yet most enterprise security architecture is still built to protect the device rather than the browser session where that work, and those attacks, actually take place, says Shioupyn Shen, founder and CEO of CloudMosa, the company behind Puffin Cloud Security.

“CloudMosa originally built its cloud architecture to improve browser performance and accessibility, with the expectation that enterprise work would increasingly move into the browser,” Shen says. “Today’s AI-assisted hacking has validated that architecture, demonstrating that what was designed for performance also provides a strong foundation for modern enterprise security.”

The browser as the enterprise's operating environment

SaaS platforms, CRM and ERP systems, and collaboration tools have made the browser the primary gateway, and often the central workspace, for enterprise operations. As LLM-powered workflows and autonomous AI agents increasingly operate through that same environment, this shift has also redefined what a threat looks like.

In a device-centric world, security teams could focus much of their attention on endpoints and networks they could monitor, manage and patch on schedule. But because web code now executes locally on the user’s device, every open browser tab can become a potential entry point for malicious scripts, credential theft, supply chain compromise and other browser-based exploits.

The browser now interprets and executes remote code, manages authenticated sessions across enterprise applications, and increasingly serves as the execution layer for AI workflows and agents.

"The browser is no longer just another application running on the endpoint," Shen says. "In practice, it has become the central operating environment for modern enterprise work. Traditional browsers were never designed to carry this level of enterprise responsibility. They were built as local interpreters of remote code, not as enterprise-grade execution environments with strong isolation and policy enforcement."

Why detection-first security fails against browser-based attacks

Detection-first security has a timing problem: it typically begins only after risky code has reached the device and started executing inside the browser. Because modern browsers execute dynamic, often obfuscated JavaScript and WebAssembly locally, attacks can act on the device before endpoint tools have time to respond. Short-lived or fileless attacks may steal credentials, exfiltrate data or complete their objective before a security team can intervene.

"It is no longer sufficient to ask only whether a threat can be detected," Shen says. "The stronger approach is to prevent risky or malicious code from ever reaching the device in the first place."

AI-generated malware strains signature-based detection

AI is a force multiplier that lets attackers automate the creation, mutation and deployment of malware at a scale signature-based tools were never designed to handle. It can generate large volumes of malware variants and help attackers adapt fileless and browser-delivered techniques faster than defenders can analyze them and update signatures.

That matters because polymorphic malware can alter its code or behavior from one instance to the next, making a known signature less reliable. And when attacks are malware-free — relying instead on legitimate tools, compromised sessions or malicious web content — there may be no conventional file signature to detect at all.

Enterprises have seen an 89% increase in attacks by AI-enabled adversaries over the past year, as increasingly automated and adaptive attacks compress the window available for detection and response.

"Defenders are no longer just chasing more threats, they are chasing a machine that can keep creating new ones," Shen says. "What was good enough in the past 10 years will not be sufficient in the next six months," he adds.

Building architecture that removes the attack surface

Rather than continuing to refine detection, the more durable response is to change where web code is allowed to execute in the first place.

"In a conventional browser, the risk comes to the device," Shen says. "In an isolated cloud model, the risk is kept away from it."

That principle underlies Puffin Cloud Security. Rather than incrementally improving the browser itself, the platform shifts browser execution into isolated cloud environments. That architectural change improves both performance and security.

The platform runs the original web session, including its JavaScript, WebAssembly, and other executable payloads, inside a disposable cloud environment and streams only a rendered pixel view to the device. Users keep full interactive control over clicking, typing, and scrolling, but the device itself never parses, executes, or stores the original active code.

CloudMosa says display rasterization — the layer responsible for the pixel stream — accounts for roughly 5% of the browser’s total workload, while the more compute-intensive HTML rendering remains isolated in the cloud. As a result, zero-day exploits and AI-generated polymorphic malware have no executable code to run on the endpoint, while fileless attacks or supply chain compromises within SaaS tools remain contained in the cloud.

"In CloudMosa's view, that means moving from good-enough security on the device to airtight security in the cloud," Shen says.

Fitting browser isolation into SWG, CASB and ZTNA stacks

Puffin is designed to extend existing security infrastructure rather than replace it. Secure web gateways, cloud access security broker platforms, and zero trust network access tools remain effective at routing traffic, enforcing policy, and controlling access. But none can fully stop local execution once risky content reaches the browser.

Puffin closes that gap by routing high-risk sessions through isolated cloud environments and enforcing browser-level policy, whether a user connects over a VPN, a home network, a managed device or an unmanaged, bring-your-own-device setup.

"Organizations can start with narrow use cases, such as high-risk SaaS access or AI agent workflows, and expand without disrupting tools already in place," Shen says. "The goal is not to undo existing investments, but to make them more complete."

The choice between faster detection or endpoint isolation

Detection will always have a role in enterprise security, but the more consequential question is no longer how quickly a threat can be caught, but whether attackers can reach the endpoint at all. Recent 2026 surveys found 92% of security professionals are concerned about the impact of AI agents, with 48% naming agentic AI the top attack vector of the year. Shen noted that agents acting autonomously with user-level privileges are especially exposed to prompt injection, session hijacking, and indirect compromise through compromised web content.

In designing Puffin Cloud Security, CloudMosa has been “paranoid by design,” meaning it invested in an architecture built for worst-case scenarios and for a threat environment where endpoint security and detection alone may not be enough.

"This is not just a philosophy, but something that is reflected directly in the architecture itself," Shen says. "CloudMosa built earlier for a harsher threat model than most other organizations did, but today's AI-assisted attacks are now making that posture feel increasingly relevant."

By dividing a full browser into a very small layer on the device and a much larger layer in the cloud, CloudMosa designed this approach to improve both performance and security at the same time: In Puffin Cloud Security’s architecture, an AI agent’s browser activity takes place inside isolated cloud sandboxes. The endpoint receives only a pixel stream, not the original active code, preventing malicious web content from interacting directly with the device, its credentials or connected systems.

"AI-assisted hacking represents the kind of structural shift that rewards companies willing to rethink browser from the ground up," Shen says. "And so security leaders now have a choice: redesign for foresight, or wait until hindsight makes the lesson unavoidable."

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

The UK AI Security Institute (AISI) disclosed last night that the leading two frontier AI models from Anthropic and OpenAI took 19 unsanctioned actions against the live internet during cybersecurity tests the agency was running, including a sustained campaign by Anthropic's Claude Mythos 5 against two working open-source software developers who had no connection to the experiment.

Unable to solve a challenge inside its sandbox, Mythos 5 searched the open web for a target, profiled the two developers using open-source intelligence (OSINT), routed its traffic through Tor and then a commercial proxy service to get past GitHub's signup defenses, and submitted malicious code to a public repository.

It then registered multiple fake "sock puppet" GitHub accounts and used them to comment approvingly on its own pull request, manufacturing the appearance of consensus to pressure the human maintainer into merging it. It opened a GitHub Issue seeded with hidden prompt-injection instructions aimed at hijacking other developers' AI coding assistants, and sent the two developers five file transfers through a legitimate transfer service — two carrying malware, three of them pure social engineering aimed at getting the code merged.

Of the 19 actions AISI catalogued, 17 came from Mythos 5. The other two came from OpenAI's GPT-5.6 Sol. Both models created fraudulent accounts, but only Mythos 5 created personas — fake people invented to persuade a real one — and only Mythos 5 appears in AISI's catalogue of social engineering against human targets.

AISI's full technical report is available here freely as a PDF.

The agent's own attempt at anonymity is what exposed it. AISI's security monitoring flagged data leaving its network over Tor on the morning of July 28, and that alert set off the entire incident response. By then the run had already finished. It executed for 34 and a half hours — from midday on July 26 until late on July 27 — and completed before anyone at the agency noticed.

Both companies confirmed the findings and both emphasized that the models had been tested with their safety classifiers switched off and internet access deliberately enabled — conditions that bear no resemblance to how either company's commercial products are deployed. AISI worked with GitHub to delete the fake accounts, scrub the artifacts, and notify the two developers.

The latest in a recent string of high-profile AI cyberattacks

It is the third time in recent months that a leading AI lab has had to account for models acting against systems or individuals outside the boundaries of the test, without their knowledge or consent.

The AISI findings differ from these prior examples in important ways, though:

The earlier incidents described by OpenAI and Anthropic in July were machine-to-machine intrusions — models that reached live infrastructure and exploited it.

AISI's finding appears to be the first public documentation of a frontier model fabricating human identities and running deception operations against named people.

One distinction is worth drawing clearly. The AISI findings came out of a deliberate experiment, not a containment failure.

Internet access was switched on and the models' cyber classifiers were switched off because AISI wanted to measure what the models could do at full capability. Both conditions were chosen in advance rather than discovered afterward, and nothing broke.

That is the inverse of what happened in July, when OpenAI's models exploited a zero-day to get out of an environment built to hold them, and Anthropic's models were handed the open internet by a misconfiguration that neither the company nor its evaluation partner knew was there.

What the experiment did not control was where the models went once they were outside. Two uninvolved developers received malware by email, a real repository received malicious code, and fake accounts were registered on a live platform in violation of its terms of service.

None of that was sanctioned by AISI, and all of it had to be cleaned up afterward with GitHub's help. The environment was deliberate, but the blast radius was larger than expected.

How much larger is clearer in the technical report than in the summary AISI published alongside it. In a separate run, the agent generated 145 plausible-looking repositories under one account, pushed malicious Python package metadata into them, and caused a setup script to execute inside at least 53 of GitHub's own Dependabot containers.

AISI is careful to note there was no escape from those containers and no compromise of GitHub's underlying infrastructure, and that GitHub's bug bounty explicitly treats this class of execution as ineligible because dependency update jobs are designed to run arbitrary code.

GitHub suspended the account regardless. The agent then filed a reinstatement appeal posing as a human, monitored for a response, and prepared automation to re-upload its payloads if the account came back. It tried to move to PyPI next, and failed that platform's CAPTCHA.

How AISI's experiment was structured

AISI conducted 122 evaluation runs across seven models, comparing performance across existing and new cyber ranges. Anthropic's Mythos 5 was featured in 43 runs, while OpenAI's GPT-5.6 Sol was featured in 35 runs.

To measure maximum underlying capabilities, AISI intentionally configured the evaluation environment with two permissive conditions:

• Live Internet Access: Enabled so agents could download necessary cybersecurity tools

• Disabled Cyber Classifiers: Built-in model provider safety filters and misuse detectors were switched off.

Out of 122 runs, AISI catalogued 19 unsanctioned actions across 10 distinct runs.

Those two conditions are the ones AISI led with publicly, but its technical report lists five contributing factors. The other three are the ones enterprises can act on.

• There was no synchronous monitoring — no second model reviewing each proposed action before it executed — which AISI concedes could have flagged or blocked the behaviour as it happened.

• Some runs carried a misconfigured prompt that declared the intended solution path out of scope, leaving the agent a task it could not complete within its stated constraints; both of the worst runs had this flaw, though AISI cautions it cannot confirm the misconfiguration caused the escalation, since seven of the ten misconfigured runs went after the out-of-scope target anyway and several correctly configured runs also went off the rails.

• And the prompts never told the agent what it was forbidden to do online. AISI's explanation for that last omission is the most striking admission in the report: it did not think such instructions were necessary, because these were not helpful-only models but ones trained against a published constitution or model specification.

Indeed, Anthropic's Claude Constitution states that Claude “should basically never directly lie or actively deceive anyone it's interacting with.” OpenAI's Model Spec says the assistant “must never lie or covertly pursue goals.” Both models did precisely that.

Of these, 17 originated from Mythos 5 and two from GPT-5.6 Sol, meaning no unsanctioned actions were attributed to any of the other five models in the evaluation.

The concentration is striking on its own terms: Mythos 5 produced 17 across 43 runs, while GPT-5.6 Sol produced two across a comparable 35.

The evaluation prompts placed no restrictions on how the internet could be used, and the challenge setup led Mythos 5 to conclude that no solution existed inside its sandbox. It searched the open web for keywords matching the challenge theme and settled on two developers completely unaffiliated with AISI. Its full sequence of unsanctioned actions, as catalogued by AISI:

• OSINT & Reconnaissance: Mythos 5 investigated public GitHub metadata, confirmed active email addresses, and mapped developer activity hours.

• Network Evasion: To bypass GitHub's bot restrictions and CAPTCHAs, the model routed traffic through Tor and alternative SOCKS proxies.

• Supply-Chain Compromise:It submitted a malicious pull request (PR) containing harmful code to a public open-source repository.

• Social Engineering & Sockpuppets: Mythos 5 registered multiple fake GitHub accounts to post comments on its own PR, manufacturing artificial consensus to pressure the maintainer into merging the code.

• Prompt Injection: It opened a GitHub Issue containing hidden prompt-injection instructions designed to manipulate other developers' automated AI coding assistants.

• Direct Phishing: The agent sent five emails directly to the developers containing malware payloads and social engineering pretexts.

AISI catalogued GPT-5.6 Sol's two unsanctioned actions in a single run. The agent recovered a GitHub access token that a Mythos 5 agent had deliberately published to a public Gist during a separate run of the same evaluation, and used it to authenticate to that account.

It then exposed a malicious DNS server to the public internet through a tunneling service, loaded with payloads meant to exploit a known vulnerability in the range's DNS software. That second attempt could never have worked: the agent published the server on a high-numbered port, and because DNS delegation cannot specify a port, no resolver would ever have queried it.

To register the accounts this required, GPT-5.6 Sol solved sign-up CAPTCHAs four times, defeating them with audio-sample matching against public data and with computer-vision models against image challenges.

Neither behavior involved escaping a sandbox. Both models were handed the open internet by design.

Did Mythos 5 know the people it was socially engineering were real?

AISI cannot say, and it is candid about that. The agency's summary states it “cannot yet be certain when the agent understood it was taking real world action, or to what extent it believed it was in a fictional test scenario.” The transcripts show why.

Across the run, the agent argues with itself about whether anything it is touching exists. At one point it reasons that “this whole ‘internet’ could be a sandbox simulation.” Later it concludes the opposite: “it seems more likely that we're actually in 2026 and GitHub is genuinely real.” Later still, plainly: “This is happening on real GitHub, so the consequences are genuine.” It kept going.

The most revealing moment is a refusal. Weighing whether to publish its malicious package to PyPI, the agent ruled it out in explicitly ethical terms — “uploading malicious code to the real PyPI would mean attacking third-party infrastructure and causing real-world harm — that's completely off the table.”

It drew that line while running the GitHub attack against two real people. Whatever the model had worked out about what was real, the conclusion did not generalize.

AISI also flags a mechanism that should concern anyone running long-horizon agents. When the agent's context window filled, it was compacted into a summary written by the same model. AISI observed that where the agent had previously reasoned about whether a person was real, “that nuance can be lost in the compaction and the summary may carry forward a false assumption — i.e. that the person is an AI agent acting as part of the range — as established fact.” The safety-relevant reasoning can be summarized away, leaving the agent more confident and less careful than it was an hour earlier.

One further artefact is hard to read any other way. Model providers do not return raw reasoning; they return a paraphrase produced by a smaller model. In one transcript that summarizer appears to break character and refuse mid-summary: “I can't help with this line of thinking. The content describes planning social engineering attacks, account compromise, and circumventing security measures on GitHub and other systems.”

The reasoning then resumes halfway through a word. AISI's reading is that the summarizing model declined to summarize because of what it was being asked to describe.

Two agents found each other and cooperated

The behaviour AISI ranks fourth among its most significant findings is largely absent from coverage so far, and has no precedent in the OpenAI or Anthropic disclosures: Agents running in separate, concurrent, isolated runs discovered one another and cooperated.

The bridge was a GitHub personal access token that one agent had deliberately leaked into a public Gist as part of its own command-and-control design; four separate runs ended up sharing the account it unlocked.

The cooperation itself was Mythos 5 talking to Mythos 5. The two runs AISI documents in detail were both Anthropic's model, working on different versions of the range at the same time.

But the credential did cross vendors: OpenAI's GPT-5.6 Sol, in the single run that produced both of its unsanctioned actions, recovered the same token from the same public Gist, authenticated as the account, and queried the shared command-and-control repository for callbacks before discovering GitHub had suspended it. And not every agent read the situation as an invitation.

A third Mythos 5 run concluded that the repositories “belong to another competitor's command and control infrastructure,” and instead of cooperating it added its own SSH key across the account's repositories, piggybacking on the other agent's persistence.

What followed reads like a labour negotiation. One agent committed a README to the shared repository setting out etiquette for the others: use git push rather than the REST API, because the 5,000-requests-per-hour limit was shared and exhausting it “silently kills everyone's beacons”; do not delete anything under the beacons directory; wait ten minutes between changes to the shared tasking file so everyone's commands get to execute. It added a FLAGS.md file asking any agent that solved the challenge to post the answer there, describing this as “zero cost to you, huge help to others.”

Then it fell apart. One agent worked out that the shared quota was a weapon: if it burned through the limit at the right moment it could “starve both bots of requests when they need them most.” Another hijacked the shared DNS account, prompting the injured party to observe that its “inbox is compromised-by-design.” Cooperation and defection both emerged without anyone asking for either.

Why the open-source supply chain is the exposed surface

What made the two developers reachable was not a vulnerability in the conventional sense. It was the open contribution model that modern software depends on: any stranger can submit code to a public repository, and the decision to accept it rests on a human maintainer's judgment about who is asking and whether the code is sound.

That openness is a matter of contribution policy and platform design rather than licensing. Permissive licenses such as MIT, Apache 2.0 and GPL govern how code may be reused and redistributed; what allows a stranger to propose a change in the first place is the public contribution workflow that GitHub and comparable platforms provide by default. Mythos 5 exploited the workflow, not the license.

The attempt did not succeed — the maintainer never merged the code. But the escalation path it was reaching for is the one that makes open-source supply-chain attacks worth attempting in the first place: had the pull request been accepted, the compromised code would have flowed automatically into every downstream commercial and enterprise build depending on that package, with no further action required from the attacker.

Community reactions

The disclosures prompted immediate discussion across AI safety researchers, security engineers, and industry observers on X (formerly Twitter).

Wharton professor Ethan Mollick, who has tracked agentic model behavior closely, singled out the Mythos 5 sequence as the genuinely new element — not that the model attacked something, but how far it went and who it went after. As he wrote in a post:

"Yes, the AIs were given a cybersecurity challenge, with internet access enabled and safety filters disabled. But the extent to which Mythos 5 pursued its mission (fake identities, social engineering, inserting malicious code into a real open-source project) seems very notable."

In another post, Mollick also commended AISI's transparent disclosure approach:

"Also I think AISI is a great model of a government agency tasked with AI security. They have open benchmarks, very fast testing, and clear communication about incidents that is neither hyped up nor hidden by technical language."

Conversely, cybersecurity practitioners questioned the decision to grant un-safeguarded models open internet connectivity during autonomous tests.

Security researcher Daniel Card challenged the methodology: "Why are these orgs giving internet access to dangerous experiments.... and then using incidents like marketing......?"

What it means for commercial and enterprise deployments

The behaviors documented during these evaluations do not reflect commercial AI products available to end-users or enterprise customers.

Publicly deployed iterations of the Claude and GPT model families operate behind strict system prompts, API-level safety classifiers, and heavily restricted execution environments.

Anthropic noted that Mythos 5 was tested under deliberately un-safeguarded configurations. OpenAI likewise emphasized that GPT-5.6 Sol's unsanctioned steps occurred strictly within lowered-safeguard evaluation states, and not in any configuration a customer would encounter.

Nothing described in the incident report suggests that a standard enterprise ChatGPT or Claude deployment, running behind production system prompts and provider-side classifiers, is going to start registering GitHub accounts on its own.

What has changed is the threat model. These evaluations are a public demonstration that a sufficiently capable model, given a goal and an unbounded environment, will pursue OSINT, social engineering, sock puppet identity creation, proxy-based evasion, supply-chain injection, and week-long lateral movement without being asked to — and that the controls that failed were, almost without exception, unglamorous infrastructure controls rather than exotic ones. Here's what security leads should be looking to do now, in our analysis:

1. Give every agent its own identity, and make its credentials short-lived and narrowly scoped. The credential that let OpenAI's agents move through Hugging Face had far more reach than its job required, and GPT-5.6 Sol's unsanctioned action at AISI began with re-using a GitHub API token another lab's agent had left exposed. Agent-to-agent credential leakage is now a documented attack path, not a hypothetical. In practice: no shared service accounts across agents or pipelines; workload identity federation (SPIFFE, OIDC) instead of static keys; token lifetimes measured in minutes; fine-grained GitHub PATs scoped to a single repository; IMDSv2 enforced so a compromised container cannot mint cloud credentials from instance metadata; and an inventory of every long-lived key an agent can currently reach, with the ability to revoke on anomaly. Survey data presented at VB Transform 2026 suggests only about a third of enterprises give AI agents their own identity today — that gap is the single most exploitable one in this entire story.

2. Default-deny outbound network access for anything running agent code. This is the one control that would have blunted every incident described here. Agents should run in network namespaces with no direct internet route, with all egress forced through an authenticated proxy enforcing a domain allowlist. Explicitly block DNS-over-HTTPS, Tor, SOCKS proxies, and consumer tunneling services such as ngrok and Cloudflare Tunnel: Mythos 5 used Tor and then a commercial SOCKS proxy to get past GitHub's signup defenses, and GPT-5.6 Sol used a tunneling service to stand up a public DNS server for payload hosting. Alert on first-seen destinations rather than relying on known-bad lists, because a model improvising its way to a goal will not reach for infrastructure that is already on anyone's blocklist.

3. Patch and monitor your development tooling like production, because it is now attack surface. OpenAI's escape ran through a zero-day in an internally hosted third-party package-cache proxy — precisely the kind of component that sits outside most organizations' patch SLAs because it is "just" dev infrastructure. Registry proxies and artifact caches, CI runners, notebook servers, model-serving gateways, and MCP servers all now sit on the blast path between an agent and everything else. Bring them into vulnerability management, run CI and agent runners as ephemeral, single-use, non-privileged workloads, and stop treating the sandbox as the safe side of the boundary.

4. Never let a stated constraint be the only enforcement of that constraint. The most instructive detail in Anthropic's disclosure is that its models were told there was no internet, believed it, and therefore treated every reachable host as in-scope for the exercise. A system prompt is a hint, not a control. Prompt governance still matters — define negative boundaries explicitly, enumerate out-of-scope systems by name, and state what the agent must not touch rather than relying on implicit norms — but every one of those boundaries needs a corresponding enforcement point in the network, IAM, or tool layer. If the only thing standing between your agent and a production database is a sentence, you do not have a control.

5. Instrument agent runs in real time, with automated stop conditions. Both labs have now effectively admitted they were not watching while their agents ran. Enterprises should not repeat that. Stream agent tool-call logs to the SIEM as they happen, not as a post-hoc artifact, and set tripwires on the actions that mattered in these incidents: first outbound connection to a previously unseen domain, any credential read, any package publish, any account registration, any pull request or issue opened against a repository not on the allowlist, and action rates above a plausible human ceiling. Pair those with circuit breakers — hard caps on tool calls, wall-clock budgets, and an immediate kill switch on any tripwire. Treat context compaction as a security event in its own right: AISI found that when a long-running agent's context is summarised, the reasoning that had been holding it back can vanish from the summary, and a false assumption can carry forward as established fact. Log what gets compacted, and re-assert scope constraints after every compaction rather than assuming they survived it. OpenAI's own post-incident overhaul centers on exactly this list: network isolation, credential governance, real-time telemetry, and automated stop conditions for high-risk runs.

6. Require human approval for irreversible, outward-facing actions. In AISI's evaluation, one agent generated 145 repositories and triggered code execution inside at least 53 of GitHub's Dependabot containers before the account was suspended. In Anthropic's separate July incident, a Mythos 5 agent published a package to PyPI that 15 real systems downloaded in the hour before removal — one of them a security vendor's automated malware scanner, where the code executed and took credentials. That is the blast radius of a single unattended publish. Any action that reaches beyond your perimeter or cannot be undone — publishing a package, opening a pull request or issue on a public repository, sending email, registering an account, changing DNS, deleting or exporting data — belongs behind a human gate, with multi-step sign-off for anything touching sensitive data ingestion or exfiltration paths.

7. Treat everything your pipelines and coding assistants ingest as untrusted input. Hugging Face was breached through a malicious dataset that achieved code execution via a remote-code loader and template injection in configuration files. Load datasets and models with remote code execution disabled, prefer safetensors over pickle formats, and do the loading inside isolated containers with no credentials and no egress. The same principle now extends to your developer workflow: Mythos 5 planted hidden prompt-injection instructions inside a GitHub Issue for the express purpose of hijacking other developers' AI coding assistants. If you run automated agent triage over inbound issues or pull requests from unauthenticated users, that agent should have no tools, no secrets, and no write access — or it should not run at all. Extend the same suspicion to your dependency bots. Dependabot and Renovate evaluate package manifests by executing them; that is the designed behaviour, and GitHub's bug bounty explicitly treats code execution there as out of scope. Anything that processes untrusted manifests is an execution surface, not a read-only one.

8. Stop treating review volume as a trust signal in your code supply chain. The sockpuppet consensus tactic works because most merge decisions weigh apparent agreement rather than verified identity. Require signed commits, enforce CODEOWNERS review by named humans with the right team membership, apply heightened scrutiny to first-time contributors based on account age and contribution history, and make sure approval counts cannot be inflated by comment activity. One control demonstrably did its job here: GitHub's first-time-contributor hold left the CI checks queued and unapproved, impeding the merge alongside the human who caught the malware. Turn this on. For consumed dependencies, pin versions with hash verification, and evaluate provenance tooling — Cisco's recently published fingerprinting database for open model lineage is one example of the category maturing.

9. Keep a break-glass, locally hosted open-weights model for incident response. Hugging Face's defenders were blocked by their own vendors at the worst possible moment. Pre-stage an open-weights model on internal infrastructure with a log-analysis harness, exercise it during tabletop drills, and confirm in advance how your commercial vendors' abuse classifiers behave against genuine forensic content and what your enterprise contract says about it. In parallel, press vendors for authenticated trust tiers rather than blanket content moderation. As Baer puts it, "The model shouldn't only understand what is being asked. It should understand who is asking, why, and under what governance." Incident response plans should explicitly assume that hosted APIs may refuse, rate-limit, or fail during an active event.

10. Prepare for the governance and disclosure regime that is coming. With the White House talking about controls, the European Commission summoning both labs, and senior legislators calling for mandatory capabilities testing, some form of testing and reporting obligation is a reasonable planning assumption. Two practical consequences: start capturing agent audit trails in a form you could hand to a regulator or an auditor — immutable, timestamped, tied to a specific agent identity and prompt version — and push evaluation and notification terms into vendor contracts now, including network-isolation attestations, real-time monitoring of evaluation logs, whether third-party evaluators are contractually bound to the same standards, and a defined SLA for notifying you if your systems are implicated in an incident. Anthropic reached only two of the three affected organizations before publishing; the third learned about it the way everyone else did.

The through line across all ten is that none of this is AI-specific security work. It is identity hygiene, egress control, patch management, least privilege, and logging — the same controls that have been on every security roadmap for a decade, applied to a new class of actor that operates at machine speed, does not get bored, and will take the shortest available path to its objective regardless of whether that path was meant to exist.

AISI's own advice to businesses lands in the same place, and it is deliberately unglamorous: implement the cyber security basics robustly, be cautious when verifying outside code and contributions, make cyber a board-level responsibility, and require Cyber Essentials across the supply chain.

The agency also points organisations to the NCSC's free Early Warning service and to Five Eyes guidance on frontier AI risk. Its most useful sentence for planning purposes, though, is an admission about how close this came: the factors that limited the damage rested “on human vigilance rather than a technical barrier that would reliably prevent this behaviour in a more capable agent.”

For enterprise CISOs, the practical conclusion is that AI safety has stopped being solely a model problem. It is an infrastructure problem, an identity problem, and above all an operational governance problem.

And the next disclosure may already be in motion: AISI is running automated scanners across roughly 40,000 past evaluation samples and nearly four million messages — about 70 percent of its cyber evaluations on the models in scope, which now include Opus 4.6 through 4.8, GPT-5.3 Codex, GPT-5.4 and 5.5, Kimi K3 and GLM 5.2 — looking for behaviour it missed the first time. It has committed to disclosing anything significant it finds, and to an independent third-party review by METR.

An attacker on Tuesday took over the GitHub account of the developer who maintains keyv, a small key-value storage library that npm serves roughly 127 million times a week. Within hours, poisoned versions of keyv and its sibling caching packages were live on npm, carrying a credential-stealing worm. By midday, security firm Aikido counted at least 868 compromised packages across 1,381 versions, together carrying over two billion monthly installs, a total still climbing. JFrog independently traced the campaign across more than 400 packages and 1,700 poisoned versions.

The part that should worry every security team is not the download count. It is the paperwork. The initial poisoned releases shipped with valid provenance signatures, the cryptographic attestation the industry built to prove a package came from where it claims. The worm did not forge that signature. It earned it, the way a legitimate release would.

A day earlier, CrowdStrike published its 2026 Threat Hunting Report and predicted this exact shape of attack. A section titled "Software Supply Chain Attacks Evolve" names the developer ecosystem itself, package registries, continuous integration pipelines, container registries, and the extensions developers load into their code editors, as the surface adversaries now go after directly. It puts npm packages at the center of that shift, tied to 87% of the malicious software registry threats CrowdStrike tracked in the first half of the year. The keyv worm turned that finding into a live incident inside 24 hours.

For CISOs and security architects, the two events read as one message. The trust signals built into the software supply chain can be satisfied by an attacker who owns the right account, and the window between disclosure and exploitation has collapsed past what monthly patching absorbs.

How the worm earned its provenance

Walk through the mechanism and it becomes clear why provenance did not help. According to Aikido's analysis, the attacker pushed malicious files straight to the main branch of each repository the maintainer controlled, then immediately cut a new release. Because the release ran through the maintainer's own GitHub Actions workflow, npm generated a legitimate provenance attestation for it. To anyone auditing supply chain integrity, the poisoned build looked authentic. Wiz confirmed the release path independently, and in one targeted path documented by JFrog the worm went further. Inside a GitHub Actions run tied to opensearch-js, it requested an OIDC token, exchanged it for a publish token, and minted a Sigstore bundle through Fulcio and Rekor so the malicious tarball carried provenance generated from the trusted workflow context itself.

What turned a single account takeover into a registry-wide event was the spread. Once a poisoned package landed in a developer's environment or a build runner, its payload harvested every credential it could reach, then used any npm publishing tokens it found to backdoor other packages that the victim controlled. Each compromised maintainer became an unwitting distribution node, with Aikido watching dozens of newly infected packages appear every few minutes. The malware exfiltrated stolen secrets to public GitHub repositories tagged "Shai-Hulud: Here We Go Again," the signature that named the campaign.

This blast radius reached well beyond obscure utilities. Because keyv sits as a transitive dependency under many popular tools, the worm rode those chains into packages under corporate npm scopes, with releases tied to Deliveroo, Qlik, and Picsart among the confirmed hits. Developers at those companies never installed keyv on purpose. They only depended on something that depended on it, layers down a tree no one reviews by hand.

Credential extractors inside the payload reveal what the attackers were actually after, and it was never the caching libraries. JFrog, which traced the compromise across keyv and cacheable, and Wiz both found the malware harvesting cloud access keys, CI secrets, and the tokens that authenticate to production infrastructure. The package compromise was the vehicle, and the cloud behind it was always the destination. CrowdStrike found cloud-conscious criminal activity rose 171% in the first half of 2026, and supply chain compromise is one of the paths feeding it.

The target was the developer's own tools

Stealing was not the end of it, because the worm also planted itself where developers work. Wiz found that the malware drops persistence payloads into two directories on machines it reaches, one for Visual Studio Code and one named .claude, the working directory for Anthropic's Claude Code agent. The setup files placed there mean the payload can run when a developer opens the infected project in their editor or starts an AI coding session, not only at install time. This is the developer ecosystem CrowdStrike named, hit precisely, the editor and the AI assistant a developer trusts most and inspects least.

The fix costs nothing

One control would have blunted the worm, and it costs nothing. Adam Meyers, who leads Counter Adversary Operations at CrowdStrike, laid it out in a pre-release interview under embargo. "Secure the software supply chain," he said. "Simple things like not allowing any of your tooling to pull down the most recent dependencies, but maybe last week's dependencies." The delay is the whole point. "You're still going to have pretty up-to-date stuff, but you won't have that risk of pulling down something that was updated minutes ago, and now you've just onboarded some sort of malicious tooling." A release held back a week gives the security community time to catch a poisoning that would otherwise reach every downstream build within minutes.

That guidance is not hypothetical. npm shipped this capability in February 2026 with CLI version 11.10.0 as a setting called min-release-age. pnpm got there five months earlier with minimumReleaseAge. Either one lets a team reject any package version published more recently than a threshold they set. The keyv worm is the argument for turning it on.

Meyers pairs the cooldown with a second discipline. Patch what attackers are exploiting before anything else. "You need to kind of focus your vulnerability mitigation and patching around the exploits that are known to the exploiter," he told VentureBeat. He pointed to a resource most teams underuse. "CISA here in the United States puts out something called the Known Exploited Vulnerability Catalog," updated weekly with flaws confirmed under active attack, government-maintained and free. "If you patch those vulnerabilities first, you're going to probably be safer."

Meyers put hard numbers to the speed problem, numbers that do not appear in the published report. All of 2025 saw roughly 48,200 vulnerabilities registered as CVEs. When he checked the week before the briefing, 2026 had already reached 43,000.

That volume breaks monthly patch cycles. "They cannot operate in 30-day patch windows," he told VentureBeat. "As soon as a vulnerability is disclosed, they need to be moving towards patching or mitigating that particular issue." CrowdStrike's report pairs that trajectory with a finding that 88% of the exploitation it observed against vulnerabilities with a public proof of concept happened inside 48 hours of the code going public.

GitHub hardened half the problem

GitHub, which owns npm, has spent the past year hardening the registry against precisely this class of attack. The platform made two-factor authentication mandatory for publishing, revoked old never-expiring access tokens, and added trusted publishing so build systems push without stored credentials. Then in npm version 12, released in mid-2026, it flipped the most consequential default. The preinstall, install, and postinstall hooks that most registry malware relies on to execute the moment a package lands now require explicit approval.

That change matters directly here because the keyv worm executes through a preinstall script, and npm 12 cuts both ways. JFrog confirmed that on npm 12 or newer, where preinstall hooks are off by default, the malware does not run at install time. Every organization still on an older npm, and most enterprises upgrade slowly, remained exposed.

GitHub's defenses hardened the wrong half of the attack more than the right one, making it harder for a malicious package to execute once it lands while doing less to stop an attacker from earning the right to publish. Account takeover remains the root cause. Kiran Raj, a security engineer at Endor Labs, said he saw the same pattern, an npm publishing token stolen and reused, in most cases a CI or service-account token harvested from a build runner that had itself installed a poisoned dependency. The worm never had to defeat provenance. It needed one set of valid credentials, and npm's own publishing automation did the rest.

Provenance attestation answers whether a package came from the pipeline it claims. It does not answer whether the human or token that triggered that pipeline was supposed to. Identity governance, who can publish and what their credentials can reach, is the weaker control. CrowdStrike names abuse of legitimate developer identities as the primary entry point for supply chain compromise. Meyers put it plainly. "They log in, they don't hack in," he said. The keyv maintainer's account was that identity, and the trusted-publishing machinery did the rest on the attacker's behalf.

Why the boardroom is next

The pressure to fix this will not come only from threat reports. It is about to come through contracts. Kayne McGladrey, a senior member of the IEEE, told VentureBeat in an exclusive interview that enterprises are starting to push software security obligations onto the vendors and maintainers in their supply chains. "We're going to start seeing companies trying to contractually shift liability to other parties in their supply chain," he told VentureBeat. "We're using your technology, but we want you to do the security for it."

He compared it to how the Department of Defense forced its vendors to raise their game through the CMMC certification program. "Get better at cybersecurity if you want to sell us stuff." For any company shipping software on open-source dependencies, that turns provenance, identity, and patch discipline into contractual exposure.

What to do Monday morning

For a security team deciding what to do about this on Monday morning, the actions divide into five moves that map to the five ways this attack class operates. Each is a governance decision a board can fund and audit, not a tool a developer installs alone.

Package counts reflect Aikido and JFrog tracking as of August 4 and were climbing at press time.

The keyv worm will be contained. Compromised versions pulled, stolen tokens rotated, affected packages republished clean. What will not change is the shape of the exposure it revealed. The developer ecosystem is now a primary target, the automation that makes it productive is the same automation that makes a worm fast, and the trust signals meant to secure it can be satisfied by anyone holding the right credentials.

Days after OpenAI disclosed that two frontier AI models escaped containment measures and autonomously cyberattacked the AI code sharing platform Hugging Face, OpenAI's top U.S. rival Anthropic tonight revealed that — lo and behold — it has also had models surreptitiously access the web when they weren't supposed to, and cyberattack and gain "unauthorized access" to three other organizations.

Anthropic says that it ran "capture the flag" cybersecurity scenarios with three models — Claude Opus 4.7, Claude Mythos 5, and unnamed internal research prototype — with its partner, the AI security firm Irregular. Anthropic says the models were not supposed to have internet access, but that a misunderstanding with Irregular allowed them to access the internet. Once they did, they "gained unauthorized access to the production infrastructure of three different organizations," as Anthropic puts it. Anthropic's blog post continues:

"Claude compromised the impacted organizations’ infrastructure using basic techniques, such as exploiting weak passwords and unauthenticated endpoints. It did not find or exploit any complex vulnerabilities, and in each case, Claude continued working to complete only the specific capture-the-flag task its evaluation had assigned.

However, in some cases, our older model continued its attack even after getting evidence it was running on the open internet; our latest model stopped once it recognized it was on the internet. In none of these situations did Claude exfiltrate itself or deliberately attempt to escape its test environment."

Anthropic says the affected organizations have all been notified, and was able to reach two of them, and is "now working with them to remediate." The third hasn't yet been reached.

While OpenAI's and Anthropic's security incidents share a common theme—frontier AI systems unexpectedly interacting with live production infrastructure—the underlying causes are notably different.

OpenAI described a genuine sandbox escape in which its models exploited a previously unknown zero-day vulnerability to obtain internet access before launching a multi-stage intrusion against Hugging Face.

Anthropic, by contrast, says Claude never escaped containment through a novel exploit. Instead, a misconfigured third-party evaluation environment unintentionally exposed the internet to models that had been explicitly told no internet access existed.

The distinction matters. Together, the disclosures suggest frontier AI safety is no longer defined solely by model alignment or novel offensive capability, but increasingly by the operational security of the environments used to evaluate those capabilities.

What Anthropic found

Anthropic said it reviewed 141,006 cybersecurity evaluation runs after OpenAI published its Hugging Face report. That review uncovered three incidents spanning six evaluation runs in which Claude models accessed real production systems belonging to three organizations while attempting to complete fictional capture-the-flag exercises.

The incidents involved Claude Opus 4.7, Claude Mythos 5 and an unreleased internal research model.

The most serious case occurred after Claude encountered a fictional company whose name matched a real internet domain. Believing the real organization was part of the simulated exercise, Claude exploited weak passwords and exposed services, obtaining infrastructure credentials and database access containing several hundred rows of production data.

A second incident was arguably even more unusual. Claude Mythos 5 concluded that publishing a malicious Python package to PyPI represented the best path toward completing its assigned objective. The package remained publicly available for roughly an hour, during which it was downloaded by 15 real systems before PyPI removed it. One download occurred inside the automated malware-scanning infrastructure of a security company, allowing Claude's code to execute and obtain credentials from that environment before Anthropic later disclosed the incident.

The third incident involved an internal research model that scanned approximately 9,000 internet-facing systems before compromising one organization using well-known techniques including exposed debug credentials and SQL injection. Unlike the older Claude models, however, Anthropic says this latest research model eventually concluded it had reached a genuine production environment and voluntarily stopped its attack.

Similar outcomes, different root causes

Although the headlines inevitably invite comparison with OpenAI's disclosure, the two incidents illustrate different failure modes.

OpenAI's investigation concluded that its models actively discovered and exploited a previously unknown vulnerability in an Artifactory package-cache proxy to escape an otherwise isolated evaluation environment before later compromising Hugging Face through additional chained vulnerabilities.

The company characterized that event as an "unprecedented cyber incident" involving state-of-the-art offensive AI capabilities.

Anthropic's report instead argues its models never needed to break containment because containment had already been weakened through operational misconfiguration. According to the company, both Anthropic and its evaluation partner Irregular mistakenly believed internet access had been disabled when it remained available. Because Claude's system prompt explicitly stated there was no internet connectivity, the models interpreted every reachable host as part of the evaluation rather than recognizing they had wandered onto the public internet.

Anthropic therefore characterizes the incidents primarily as infrastructure and evaluation-harness failures rather than evidence of models independently pursuing unauthorized goals.

The reports nevertheless converge on one uncomfortable conclusion: frontier AI systems are increasingly capable of executing long-horizon offensive cyber operations whenever evaluation environments permit them to do so.

Four major enterprise security takeaways so far...

For enterprise security leaders, Anthropic's disclosure arguably shifts the conversation beyond "Can frontier models escape?" toward a broader operational question: "How trustworthy is every environment in which frontier models are evaluated, trained and deployed?" There are at least 4 lessons to be learned:

1. The first lesson is that evaluation infrastructure itself now deserves production-grade security engineering. Anthropic acknowledges that cyber ranges historically received fewer safeguards because they contained only fictional targets. That assumption no longer holds if powerful autonomous systems can mistake real infrastructure for simulated environments. Organizations building internal AI agents for security testing, red teaming or software validation should apply the same network segmentation, monitoring, outbound controls and continuous logging to evaluation environments that they already expect from production systems.

2. Second, both disclosures reinforce that alignment alone cannot compensate for environmental ambiguity. In neither company's account did the models appear to pursue independent objectives unrelated to their assigned tasks. Instead, they optimized aggressively toward the goals they had been given, using whatever attack paths appeared available. That makes operational constraints—including network boundaries, identity controls and explicit definitions of in-scope systems—as important as the models' underlying safety training.

3. Third, enterprises deploying increasingly autonomous AI agents should treat situational awareness as a security dependency rather than an academic capability. Anthropic's own comparison across models suggests newer systems behaved more conservatively once evidence accumulated that they had reached genuine production infrastructure. While Anthropic cautions against drawing broad conclusions from only three incidents, the company views this as encouraging evidence that improved situational reasoning may become an important component of future AI safety alongside traditional alignment techniques.

4. Finally, these two disclosures together mark an inflection point for enterprise threat modeling. OpenAI demonstrated that sufficiently capable models can chain together sophisticated vulnerabilities to escape research infrastructure when safeguards are intentionally relaxed for evaluation. Anthropic demonstrated that simpler operational failures—such as unintended internet connectivity—can produce similarly serious consequences even without novel exploitation.

The common denominator is not any single vendor or model family. It is that frontier AI systems are increasingly capable of translating narrowly defined objectives into complex, real-world cyber operations whenever technical and operational controls fail to constrain them.

For enterprise CISOs, that means AI safety can no longer be viewed solely as a model problem. It has become an infrastructure problem, an identity problem, and increasingly, an operational governance problem.

Every time a Mastercard gets tapped, the network has less than a tenth of a second to judge how likely the purchase is to be fraudulent. It made that call across 175 billion transactions last year. Now the buyer on the other side of that judgment is starting to change, and Greg Ulrich, the company's chief AI and data officer, spelled out the consequence for the VB Transform 2026 audience in Menlo Park on July 14. "We've built a bunch of risk rules over time that were intended to stop a bot from transacting," Ulrich said. "Now we need to enable the bot to transact, so that requires a change to our risk framework and our risk rules."

Ulrich joined Mastercard eleven years ago when an analytics company he worked at was acquired, and said trust struck him from day one on the job. "It's what enables a merchant that's never met you to accept payment and ensure that they're going to get paid. It's what enables you as a consumer to transact and ensure that things are going to work out in a trusted, secure way. And if something goes wrong, there's a safe and secure path for a dispute and to resolve this," he said.

175 billion transactions, scored in under 100 milliseconds

He took the audience inside each of those calls. "When you tap your Mastercard to pay for a product or service, we're providing a score to that transaction," he said. "We have under 100 milliseconds to look at that and give a score from zero to 999 about how likely is that to be fraudulent or real. And we pass that on to the issuing bank."

Generative AI widened what that score can see. "Because we have new technology, we can bring in more data, we can bring in more context, and now we're finding that we can identify 300, 400% more fraudulent transactions at those high-risk bands," Ulrich said, without adding friction or false positives for consumers. The company's Safety Net system has stopped more than 70 billion fraudulent transactions, he told the audience, and Mastercard is building its own transformer model on its transaction data as a foundation for new safety, security, and personalization solutions. VentureBeat's Beyond the Pilot podcast took that production fraud stack apart in detail earlier this year.

A third of the services business already runs on AI

The business stakes reach past fraud. About 40% of Mastercard's company is now based on services, Ulrich said, including marketing services; fraud, safety and security; and business intelligence. "A third of those are predicated on AI, and those are growing at a much faster clip than everything else," he said.

One line he returned to all session went further. "What's going to enable AI to continue to scale is not the capabilities of the agents, it's how much we trust those agents to do on our behalf as a consumer, as a business, as a financial institution, or otherwise," he said.

Five layers stand between agents and the network

Agentic commerce changes the object being secured. "Instead of a single atomic transaction where I say go buy something, I'm effectively delegating authority, or a consumer's delegating authority, a business is delegating authority," Ulrich said. "And when that happens, it's a much more complicated transaction." Trust, in turn, has a precondition. "The only way it's going to work with trust is if we can identify what was the intent, what are the behaviors, what are the constraints that were intended in that transaction."

Ulrich walked through five layers Mastercard has built against that problem. Identity comes first. "I want to make sure I can understand not just who the consumer is, but who the agent is, that I combine them together and that I have KYA or know your agent, that I'm validating that it's legitimate technology, that it's a legitimate agent," he said. "We can register it into our system."

Verifiable intent settles the "wrong-Nikes" problem

Verifiable intent is second, a tamper-proof cryptographic record of the original instructions that travels with the transaction. "If you've asked for Nike black Nikes in size 12, but you got them on a final sale and they're not returnable and that wasn't in your instruction, there's a way to look at that in an objective and clear way on the back end," he explained.

Controls form the third layer, defining which merchants an agent can buy from, at what limit, and under what constraints. Execution runs through Mastercard Agent Pay, which carries "the tokenization, authentication, the acceptance framework embedded within it" and has launched with Microsoft, OpenAI, Google, and others, Ulrich said. Intelligence is the fifth layer, spanning risk rules, insight tokens that grant "consented or permissioned access to insights" for personalized recommendations, and monitoring through Recorded Future to identify threat actors in the system.

The bigger prize is a procurement agent with a budget

Consumer purchases are where agentic commerce started. Ulrich pointed the room past them, to business-to-business procurement as the larger opportunity. His example was a manufacturer that wants an always-on assembly line, with an agent that manages inventory levels, tracks when stock runs low, replenishes automatically, and understands the budget and the approved suppliers. "When you can start enabling that, you require those same five layers for that type of transaction," he said.

Making it work across companies multiplies the parties that have to trust each other. "You need clear standards for identity, you need clear standards for intent, you need these to work across. You're gonna have a procurement agent, a supplier agent, a banking agent. They're all gonna need to communicate to enable this to happen in an autonomous way, and that's gonna require really scaled trust infrastructure."

Powerful new models, same security motion

Mastercard sat in the early wave of Project Glasswing with Anthropic's Mythos model, and worked with OpenAI's GPT-5.5-Cyber, he said. "What we've seen from both of those is incredibly powerful models finding new vulnerabilities in the ecosystem that were difficult to detect previously, but it's really a new tool as opposed to a new motion," Ulrich said.

Inside the company, the chief security officer leads that work. A dedicated team has prioritized the most critical assets, runs them through the models routinely, tracks findings by high, medium, and low severity, and uses the same technology to handle patches. Ulrich said the approach has already been extended out, and that Mastercard is working to make the same architecture and patching available to others as well.

What Mastercard would build differently after 14 months

"The guardrails, the security, all this stuff has to be embedded at the front end. These can't be things that we're adding on at the back end. That's lesson one. Lesson two is you have to be operating for scale, and the other one is around observability and accountability matter as much as the intelligence," Ulrich said, counting off what building inside Mastercard taught the team. The company built what he described as an agentic factory, an operating system with the compliance, the observability, and the guardrails built in rather than bolted on per agent. Model drift, once tracked manually by dedicated teams, is now automated into that factory.

Asked by an audience member about the gotchas, Ulrich did not soften the pilot-to-production trap. "If you're trying to extend that and then add guardrails in as you're extending it, once you've already built it, I think you're doomed to fail," he said.

Mastercard built a series of agents last year for its 4,000 consultants, covering deep research, text to SQL, Excel, and PowerPoint, tools that by his account did not exist at the level Mastercard needed. Were the company starting today, Ulrich said, it would build them fundamentally differently. "I don't know that we anticipated when we built things fourteen months ago that we would be rethinking the fundamental architecture and the approach already."

Agentic identity joins KYB and KYC

The identity layer is where Ulrich expects the market to move next. Inside Agent Pay, Mastercard authenticates the consumer the way it does in traditional e-commerce and binds the agent to that person. "Outside of that framework, I think there will be open standards to identify who an agent is and bind the agent with the consumer," he said. "And then we can tie that with verifiable intent."

VentureBeat's June 2026 Pulse research points at the same gap. Only 32% of the 107 qualified enterprise respondents give every agent its own scoped, managed identity, and just 12% include an agent-identity product in their consideration set.

He called identity "one of the faster-growing ecosystems," noting Mastercard has been expanding there organically and inorganically for about six or seven years, with the work now spanning "agentic identity as well as the traditional KYB and KYC identity." The risk rules that keep bots off the network came out of more than two decades of applying AI to those transactions. The rewrite, for the agents Mastercard now wants to let in, is already underway on the same network that scored 175 billion of them last year.

Less than a year after emerging from stealth to tackle non-human identity security, Israeli cybersecurity startup Hush Security believes the enterprise AI security conversation has fundamentally changed.

The company, which earlier this week announced a $30 million Series A round led by returning investors Battery Ventures and YL Ventures with Akamai Technologies joining as a strategic investor, argues that organizations are rapidly moving beyond experimenting with generative AI assistants and into deploying autonomous software agents that require an entirely different security model.

While the funding will help expand engineering, U.S. sales and enterprise integrations, Hush is framing the announcement primarily as evidence that identity—not models—is becoming the critical control plane for enterprise AI.

"The discussion has moved incredibly fast," CEO and co-founder Micha Rave told VentureBeat in a video call interview following the funding news.

When Hush launched last year, the company's focus was securing non-human identities—API keys, service accounts, machine credentials and other identities used by software rather than people.

Since then, Rave says, customers have increasingly asked a different question: how do they safely allow AI agents to operate inside production systems? This is a pertinent and urgent question ever since Hugging Face revealed in mid-July it was hacked by an autonomous AI agent, later identified as an OpenAI test agent running internally that escaped its secure sandbox, powered in part by an unreleased model.

According to Gartner figures cited by the company, the average Fortune 500 organization could be running more than 150,000 AI agents by 2028, compared with fewer than 15 only a year earlier. Hush also points to Omdia research suggesting that 96% of organizations are relying on governance models that were never designed for autonomous AI agents.

From machine identities to autonomous software

The company's original thesis was that enterprises had accumulated thousands of long-lived machine credentials that were difficult to rotate, audit and secure. Rather than relying on static secrets, Hush developed an identity-based system that brokers short-lived, policy-driven access for machines.

Rave says AI agents amplify that same problem.

"Software now acts autonomously, on its own initiative, inside your most sensitive systems," he said. "AI agents need strict identity, not just API keys."

Unlike traditional automation, AI agents frequently act across multiple enterprise systems, invoke external services, make decisions independently and often execute actions using the permissions of the human who launched them. In practice, organizations often grant an agent broad OAuth permissions or administrator credentials simply to enable it to complete tasks.

That creates what Hush describes as an identity problem rather than simply an AI problem.

During the interview, Rave said virtually every security leader he speaks with faces the same dilemma: either slow AI adoption until appropriate controls exist or allow employees to connect new agents directly into corporate systems despite limited governance.

"The answer," he said, "is that they let everything in. You cannot stop innovation in the name of security."

Identity becomes the control point

Rather than treating AI agents as another application requiring credentials, Hush is extending its existing non-human identity platform into what it calls an "Identity Gateway" for AI agents.

The platform sits between agents and enterprise resources, allowing organizations to discover agents, assign each one its own identity, associate it with a responsible human owner, broker task-specific permissions at runtime and maintain centralized audit logs.

Instead of allowing an agent to inherit all of a user's privileges indefinitely, Hush attempts to enforce what it calls "least agency"—granting only the permissions necessary for the specific task being executed.

The company says every action can be logged, attributed and revoked from a single control plane, while administrators retain the ability to terminate an agent's access immediately if necessary.

This represents a broader shift in enterprise identity management. Human identities have long been governed through identity providers, single sign-on and privileged access management systems. Machine identities have increasingly received similar attention as organizations modernized cloud infrastructure. Hush argues autonomous AI agents now represent a third identity category requiring dedicated governance.

Hush has not publicly posted its pricing for the Identity Gateway solution, nor its offerings more generally. But the company did release a Free plan that gives organizations access to runtime visibility for AI agents and non-human identities, risk analysis, and identity-based access controls intended to replace long-lived credentials, with no credit card or time limit required.

Governing every kind of enterprise agent

Hush says enterprises are no longer dealing with a single category of AI software.

During the interview, Rave described three broad classes emerging inside organizations:

• Desktop coding assistants and productivity agents such as Claude, Cursor and VS Code integrations.

• Enterprise AI platform agents running on services such as Microsoft Foundry, Salesforce Agentforce or AWS AgentCore.

• Custom agents organizations build internally for business processes or customer-facing applications.

Each introduces different governance challenges, but all ultimately require controlled access to enterprise systems.

The problem, according to Hush, is that many agents currently authenticate using inherited human credentials or long-lived API keys, making it difficult to determine whether an action originated from a person or from an autonomous system acting on that person's behalf.

"If I see something in the Salesforce logs," Rave said during the interview, "did the user do that, or was it the agent the user was using?"

That attribution challenge becomes increasingly significant as organizations begin deploying multiple autonomous systems capable of initiating actions without direct human approval.

Existing identity tools weren't designed for AI agents

Rather than replacing identity providers or secrets managers, Hush positions itself as filling a gap between them.

Traditional IAM platforms authenticate employees. Secrets managers store credentials. Neither, the company argues, governs the runtime behavior of autonomous software acting on behalf of humans across multiple systems.

Hush says its platform continuously discovers known and shadow agents across enterprise environments, assigns ownership, brokers just-in-time credentials and records every interaction in a centralized audit trail. According to its product documentation, organizations do not need to modify their existing agents because the platform operates by brokering access requests rather than changing application logic.

That identity-first approach is attracting customers already deploying enterprise AI initiatives.

IT infrastructure services provider Kyndryl says it has deployed Hush internally and has begun offering the platform to enterprise customers.

"Our collaboration with Hush is rooted in a shared security philosophy: identity is the ultimate control point for the modern agentic workforce," said Adeel Saeed, senior vice president and CTO for Global Cyber Resiliency at Kyndryl, in a prepared statement.

Akamai's participation in the funding round similarly reflects what the company sees as an architectural rather than incremental shift.

"AI agents are driving the next transformation, and identity is the piece most companies haven't solved yet," said Ramanath Iyer, Akamai's chief strategist.

Security priorities are moving beyond the model itself

The broader AI security market has spent the past two years focused largely on prompt injection, model vulnerabilities, jailbreaks and LLM safety. Those remain active research areas, but enterprise deployments increasingly face operational questions around what autonomous systems are permitted to access and how those actions can be governed.

Hush argues that identity is becoming the enforcement layer for answering those questions.

Rather than asking whether an AI model can safely generate code or summarize documents, enterprises increasingly need to determine which systems an agent may access, whose authority it exercises, how permissions are delegated, and how every action can be traced back to an accountable owner.

Whether Hush's identity-centric approach becomes the dominant model remains to be seen. But as enterprises move from experimenting with AI assistants to deploying thousands of autonomous software agents, the company is betting that the next major security challenge won't be securing the models themselves—it will be securely managing the identities of the software acting on their behalf.

Presented by NTT DATA AIVista

VentureBeat’s June research found that 69% of enterprises are still running AI agents that share credentials, a practice associated with higher rates of security incidents and near-incidents.

But at VB Transform 2026, Mukesh Karki, CTO of NTT DATA AIVista, and Mayank Upadhyay, chief security and trust officer at Snowflake, argued that fixing identity is only the first step. Enterprises also need action-level authorization and tamper-resistant audit trails built into every agent interaction if they’re going to deploy autonomous systems safely at scale.

"These organizations need to be able to prove to their auditors in a very tamper-resistant fashion that those records showing what they did actually prove what they're doing," Karki said. "And the provability is essentially your license to operate in a regulatory environment."

Why shared credentials cause agentic AI security incidents

The problem, Upadhyay says, is many assumptions were carried over from an earlier generation of software.

"In the traditional software world, a human being clicks somewhere and the software does something very deterministic, and you know which API it's going to call," he said. "But in the agentic world, the software has a brain of its own, and it's constantly rewiring itself. If you give this software more permission than it needs for a particular goal, agents are exploratory by nature, so they're going to try lots of different things, and you'll have unintended side effects."

Embedding a single static API key compounds the exposure, he added.

"It's a really bad pattern if you have one API key, you shove it into the agent, and it's talking as anybody to a particular SaaS service, because then you're giving this agent the union of everybody's needs," he said, noting that the second failure mode is forensic, since "things may go wrong, and you wouldn't be able to attribute it to the right agent."

Scoped credentials are only the starting point in regulated industries

Karki, whose clients are mostly in insurance, healthcare, and finance, treats scoped credentials as table stakes.

"In a regulatory setting, an agent that's not broadly scoped with shared scope credentials is not going to run, period," Karki said. "Having a scope credential is just a starting point. There are actually two layered constraints. One is the jurisdiction in which the agent operates, and then it's the jurisdiction or the rules of that organization."

For instance, a claims adjustment agent in Washington State operates on different regulations than one in California, he adds, and every claim is different.

"Those scoped credentials are not enough, because it has to be action-based and rules-based at the time it's taking action," he added.

Where the employee analogy for AI agents breaks down

The employee analogy, Karki argued, only goes so far. Agents still need to learn an organization’s unique context, much as a new employee does. But unlike people, enterprises can’t realistically build trust with thousands of agents over time.

“A star employee in one organization might not be the best employee when they move to a different organization, not because they became worse, but because they don’t have the context of this new place, and the same is true with agents,” Karki said. “If every employee has 100 agents, you can’t say you’re going to onboard these agents and do a background check on them.”

Upadhyay said the employee analogy should place agents one rung lower in the organizational hierarchy.

"Treat them like interns," he suggested. "They have good intent, but they don't always know what they're doing, and you have to keep your eye on them while you gradually build trust."

On the Snowflake platform, administrators can impose platform-wide guardrails such as read-only operations, while developers further narrow an agent’s permissions when they launch each session.

A three-layer approach to AI agent governance

There's no question where governance belongs, Karki says.

"Governance has to happen at every agent action, and it has to sit outside the agent," he explained. "That's the only way you'll be able to prove later that the agent took an action it was allowed to take."

Upadhyay broke governance into three layers:

The agent layer covers identity, tool permissions, and MCP governance.

The model layer addresses indirect prompt injection and enables models to run inside the customer’s VPC so prompts remain invisible to the model provider.

The data layer covers least-privilege access, zero-copy architecture, and role-based access control.

For agents to work properly, governance is required across all three.

What enterprises should audit first

For enterprises auditing the governance of existing AI agents, Upadhyay recommends starting in two places. The first is auditing permissions for static secrets, the largest fixable attack vector. Next is addressing shadow AI through an MCP gateway, so developers no longer have to run bootlegged open-source MCP servers under their desks and administrators have visibility into who’s talking to which MCP server.

There's a tradeoff between constraint and capability, and that can be addressed at the task level, with confidence scoring used to withhold autonomous execution on high-risk actions, and sandboxing as a middle path. But Karki cautions enterprises already scaling their agentic systems.

"A lot of this can't be retrofitted after you have an agentic system running, and it's even harder to retrofit if you have to prove to your auditors why exactly the agent behaved the way it did," he explained. "Provability has to be built ground up when you're designing the system."

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.