The report flags what most enterprise security programs have not yet structurally addressed: employee use of shadow AI tripled to 45% of the workforce in a single year, with the most common data type submitted to unauthorized external AI models being source code, while Verizon explicitly called out service and machine accounts as the identity class to watch, stating that those will likely be the ones leveraged in an agentic AI future. A compromised service account used by an agent is not a single-user breach, but an autonomous actor with persistent access and a blast radius that existing IAM models were not designed to contain.

That is precisely the governance gap Mahesh Kumar Goyal, senior data and AI engineer at Google, walks through in today’s issue.

THIS WEEK’S GEO-POLITICAL NARRATIVE

Moonlight Maze Explains Autonomous AI Dangers Today

Between 1996 and 1998, attackers linked to Russian intelligence exfiltrated classified data from US government networks for two years undetected, because authorized access and systematic exfiltration looked identical to the monitoring infrastructure in place - the same structural blind spot that ungoverned autonomous agents produce in enterprise environments today.

Narrative Link: Moonlight Maze Explains Autonomous AI Dangers Today — InfoSec Relations

The Insider View

Featuring Mahesh Kumar Goyal, Senior Data and AI Engineer at Google.

The shift from passive AI to autonomous agents changes the security problem in a way that most enterprise security architectures have not yet caught up with. A traditional application is predictable and stateless - it receives an input, executes a defined set of operations, and produces an output, and that sequence is the same every time. An autonomous agent does something fundamentally different: it browses the web, executes API calls, writes and runs code, maintains memory across sessions, and makes decisions about what to do next with minimal human intervention at each step. That combination of non-determinism, persistent memory, and broad tool access creates a threat surface that conventional governance frameworks were not designed to handle, and the gap between what existing security tools can see and what agents are actually doing is where the risk accumulates.

Mahesh Goyal, a senior data and AI engineer at Google specializing in advanced agentic AI systems and responsible AI architecture, spoke with Offensive Engineering to walk through what that risk surface actually looks like, where enterprise security teams are consistently getting the governance model wrong, and what the mandatory controls are before any agentic system should move into production.

Agents Are Not Smarter Scripts

The most consequential misconception Goyal encounters in enterprise environments is the assumption that an autonomous agent is essentially a more capable version of an existing automated script, and that the monitoring and observability tooling already in place is sufficient to secure it. It is not, and the reason comes down to what agents do that scripts do not: they move data across multiple systems without human intervention, they maintain state between interactions through persistent memory, and they interact with external tools and APIs in ways that are not fully predictable at the time of deployment.

“The threat of data leakage in autonomous AI agents is significantly larger than in traditional applications,” Goyal explains. “Unlike traditional applications, which are predictable and stateless, agents are non-deterministic, possess memory, interact with various tools, and move data across multiple systems without human intervention, making them difficult to secure.” The practical implication of that non-determinism is that an agent can function correctly for thousands of iterations before encountering a condition that causes it to behave in a way nobody anticipated, and by the time that condition surfaces, the agent may have already moved sensitive data somewhere it should not have gone.

The tools that enterprise security teams rely on - endpoint detection and response, identity and access management, data loss prevention - were built for human-driven or static services, where behavior is predictable enough that anomalies stand out. An agent operating across multiple systems and APIs does not produce the kind of consistent behavioral baseline that anomaly detection depends on, which means the signals those tools are looking for are not the signals an agent compromise would generate.

The Governance Gap That Agentic AI Exposes

Conventional access control frameworks assume that the thing being controlled has a defined, stable identity with a predictable set of permissions attached to it. Role-based access control, column-level access control, and least-privilege implementations all work on that assumption. Agents break it because they blur the boundary between code and data - an agent does not just execute instructions, it can interpret and act on content it retrieves from external sources, which means the boundary between what the agent is authorized to do and what it can be made to do is not enforced by its role assignment alone.

Goyal points to a structural problem that compounds this: most organizations keep their AI strategy separate from their broader data governance strategy, which means the agentic systems being built by AI and data engineering teams are not subject to the governance oversight that applies to everything else. “Companies often keep their AI strategy separate from their broader data governance strategy, and these new systems lack the established oversight required to manage dynamic interactions between agents and external APIs,” he explains. The result is agentic systems entering production with no centralized inventory, no defined ownership, and no security review process that accounts for the specific risks they carry.

Prompt Injection Is the SQL Injection of Agentic AI

SQL injection worked because applications trusted user-supplied input and passed it directly to a database query without validating whether the input was data or instruction. Prompt injection works on the same principle, applied to agents: because an agent processes the content it retrieves from external sources as part of its reasoning context, a malicious prompt embedded in a web page, a document, or an API response can influence what the agent does next.

The memory dimension makes this significantly more dangerous than a stateless injection attack. “Because agents maintain long-term memory, a single malicious prompt can poison the agent’s history or output,” Goyal explains, and because that memory persists across sessions, a successful injection does not just affect one interaction - it contaminates the agent’s context in a way that can influence subsequent behavior until the memory is explicitly cleared or the contamination is detected.

Goyal argues that organizations need specialized architectural controls to address this, specifically sandboxing to isolate agent execution environments, provenance verification to validate the sources of content the agent is processing, and agent gateways that can filter prompts before they reach the agent’s reasoning context - controls that have no direct equivalent in the security tooling built for traditional application architectures.

Managing Agent Memory Like a Database

Agent memory is not a log or a cache in the conventional sense - it is an active input to the agent’s decision-making process, which means it carries the same security requirements as any other data store that influences system behavior. Goyal’s framing is precise: agent memory should be managed like a database, with encryption at rest, version control to track what has been written to it and when, and strict scoping of read and write access so that an agent can only interact with the memory partitions its task actually requires.

The session isolation requirement adds another dimension that most current implementations are not accounting for. Without explicit context isolation between user sessions, an agent serving multiple users can carry context from one session into another, creating a data leakage path that does not require an external attacker to exploit — it is a design condition that produces the leak on its own. Goyal recommends making agent memory ephemeral where possible and using context summarization techniques to prevent contamination from accumulating across sessions.

What Mandatory Governance Actually Requires

Before any agentic system reaches production, Goyal argues there are governance requirements that are not optional and not addressable after the fact. The first is a centralized inventory of every agentic system in the organization’s environment, including Model Context Protocol servers and retrieval-augmented generation agents, with defined ownership, data classification, and documented tool access for each one. Without that inventory, an organization cannot assess the blast radius of a compromise — which is the second requirement Goyal identifies as mandatory: explicitly estimating how far an exploit of a given agent could reach across connected systems and data stores before deploying it.

The third requirement is cryptographic identity. Every agent needs a unique cryptographic identity with its own dedicated key pair, and those keys must not be shared between agents. “Assess the blast radius of an exploit and implement unique cryptographic identities for every agent to ensure that keys are not shared,” Goyal explains. The reason this matters operationally is that shared keys make it impossible to attribute actions to specific agents after the fact and impossible to revoke access for one agent without affecting everything else using the same credential.

Zero Trust Applied at the Agent Layer

Zero Trust as a security principle means that no action is implicitly trusted because of where it originates - every action must be authenticated, authorized, and verified regardless of whether it comes from outside or inside the network boundary. Applying that principle to agentic AI means extending it to agent-to-agent communication, which most current implementations treat as implicitly trusted once the orchestrating agent has been authenticated.

Goyal argues that this is a critical gap: if an orchestrating agent’s memory has been poisoned through a prompt injection, the downstream agents it communicates with will receive and act on that poisoned context unless they independently verify what they are receiving. “Even in agent-to-agent communication, authentication is necessary to prevent downstream agents from being impacted by poisoned memory,” he explains. The practical implementation he recommends moves away from hard-coded API keys, which are routinely exposed accidentally in log files and test cases, toward short-lived tokens and Mutual TLS for authentication, which limit the window of exposure if a credential is compromised.

Human Oversight Remains a Non-Negotiable Control

The efficiency argument for autonomous agents rests partly on reducing the number of human decision points in a workflow, but Goyal draws a clear line between the decision points that can be automated and the ones that cannot. For high-risk tasks — financial calculations, actions with irreversible consequences, decisions that affect sensitive data at scale — human-in-the-loop approval is not an optional safeguard that can be traded off against operational speed, it is a mandatory architectural control that prevents the kind of cascading error an autonomous agent can produce before any monitoring system has time to flag it.

Looking at the next three to five years, Goyal sees runtime monitoring and rigorous protection of sensitive data as the two capabilities that will determine whether enterprise adoption of agentic AI is sustainable or produces a series of high-profile failures that force organizations to rebuild systems they deployed without adequate governance.

The organizational dimension of that challenge is quite significant as many organizations discover the need for governance only after an agentic system has already reached production, at which point the cost of re-evaluating the entire codebase and workflow is substantially higher than building the governance model from the start. Treating security as a foundational element of agentic AI deployment, rather than a late-stage review, is the condition under which the rest of the architecture holds.

You can also watch the full live session here.

THIS WEEK’S PERSON OF INTEREST

George Kurtz - CEO and Founder, CrowdStrike

George Kurtz has been at the center of two of the most consequential software deployment failures in cybersecurity history - as CTO of McAfee in 2010, when a faulty antivirus update deleted a critical Windows system file across millions of enterprise machines, and as CEO of CrowdStrike in 2024, when a defective Falcon sensor update crashed 8.5 million Windows systems globally - both originating from an update that bypassed the validation controls designed to catch it before it shipped.

Kurtz frequently warns organizations about the dangers of ungoverned automated systems and advocates for rigorous security governance. But the security community continues to note the obvious tension of this dynamic as one of the industry’s loudest voices on the necessity of strict deployment controls is the exact same executive behind two of the largest uncontrolled software deployment disasters on record.

SECURITY BRIEFS

A look at recent critical vulnerabilities where autonomous agents turned prompt injections into system-level breaches.

Semantic Kernel: Prompt to Shell

Two critical CVEs (CVE-2026-26030, CVE-2026-25592) in Microsoft’s Semantic Kernel allowed a single crafted prompt to achieve host-level remote code execution — no exploit chain required, just an agent doing its job. Patched in SDK v1.71.0.

Source: Microsoft Security

Comment and Control: AI Agents Leaking CI Secrets

A CVSS 9.4 Critical prompt injection attack across Claude Code, Gemini CLI, and GitHub Copilot exploited pull_request_target workflows to steal credentials through comment fields, with no vendor publishing injection resistance metrics for their agent runtimes.

Source: VentureBeat

CrewAI: Four CVEs, One Exploit Chain

Four CVEs in CrewAI’s default configurations allow prompt injection to chain into RCE, SSRF, and arbitrary file reads within the same sequence — a compound attack path that component-level security reviews would not surface.

Source: Carnegie Mellon University

Azure SRE Agent: Unauthenticated Access to Live Commands

CVE-2026-32173 (CVSS 8.6) exposed live Azure SRE Agent command streams to any Entra ID account holder through an unauthenticated WebSocket endpoint, a direct result of deploying a privileged agent before its access controls were fully scoped.

Source: CSO

MemoryTrap: One Injection, Many Sessions Poisoned

A vulnerability in Claude Code’s memory system allows a single malicious input to contaminate the agent’s persistent memory and propagate across multiple user sessions, exposing the cost of deploying agent memory without strict scoping and session isolation.

Source: Help Net Security

Thank you for reading this issue of Offensive Engineering on Securing Agentic AI Against Data Leakage featuring Mahesh Kumar Goyal.

Stay Curious, Stay Secure!

S Pattnaik

Data Practitioner

Technical Contributor, Offensive Engineering — InfoSec Relations

In this session of Offensive Engineering Live Sessions, Mahesh Kumar Goyal, a Senior Data and AI Engineer at Google specializing in advanced agentic AI systems and responsible AI architectures, walks through the mechanics of governing and securing autonomous workflows. He’s speaking independently, and the views he shares are his own.

The conversation covers:

• Why the non-deterministic nature of agents breaks traditional identity and access management (IAM) frameworks

• How the line between data and code blurs when documents and log files become instructions for an AI

• Why prompt injection is evolving into the SQL injection of the agentic era, capable of poisoning long-term memory

• The critical need to treat an agent’s memory like a database with isolated, ephemeral context windows

• Why relying on standard enterprise observability and EDR tools for agentic workflows is a dangerous enterprise misconception

• Mandatory governance controls for production, from centralized agent inventories to unique cryptographic identities and short-lived tokens

What this incident brings to light is a breach path that runs entirely through valid credentials and legitimate API calls: no zero-days, no perimeter breach, just a trusted OAuth token presented to a system that had no way of knowing the human behind it had been compromised two months earlier. That path leads directly to the question that this issue examines - how attackers reach the cloud control plane not by attacking it directly, but by acquiring the secondary credentials that sit adjacent to it and carry enough access to make the distinction irrelevant.

Siri Varma Vegiraju, Tech Lead at Microsoft Azure Security, walks through exactly this architecture in today’s feature. You can also watch the full live session on Attacking the Control Plane.

THIS WEEK’S GEO-POLITICAL NARRATIVE

Operation Cloud Hopper Was Never About the Target

Between 2014 and 2018, APT10 breached managed service providers across twelve countries rather than their actual targets — because MSPs held persistent administrative access to every client environment they served. One compromise meant access to all of them, through legitimate tools that left nothing anomalous to detect. The operational logic is identical to what makes the cloud control plane the primary objective today: the highest-value target is the trusted layer that’s between the attacker and everything they want to reach.

Narrative Link : Operation Cloud Hopper Was Never About the Target — InfoSec Relations

The Insider View

Featuring Siri Varma Vegiraju, Tech Lead at Microsoft Azure Security.

Attacking the Cloud Control Plane

The control plane is not where your data lives - it is instead the layer that governs who can reach it, enforcing identity policies, managing resource provisioning, and controlling privilege boundaries across every workload running beneath it, which means that compromising it does not give an attacker access to one system but administrative authority over the entire environment, using the cloud provider’s own tooling against every resource and identity it manages simultaneously.

That is what makes it the primary objective for any serious attacker, and understanding how they actually reach it - through the credential gaps, misconfigured identities, and forgotten API surfaces that most security teams are not actively governing , would actually be the practical starting point for anyone building or securing cloud systems today.

Siri Varma Vegiraju, Tech Lead at Microsoft Azure Security, brings years of hands-on experience analyzing and securing cloud control plane environments. This conversation covers the architecture of a control plane compromise, the specific failure modes security teams miss, and why the rise of agentic AI is introducing a new category of identity risk that most cloud security models were not designed to handle.

The Control Plane Is Where Risk Concentrates

The strategic value of the control plane has grown proportionally as global workloads consolidated onto a small number of major cloud providers. When most of the world’s enterprise infrastructure runs on five or six platforms, a successful compromise on any one of them can cascade across every organization operating on that infrastructure.

Vegiraju explains that “from a cloud infrastructure standpoint, there are majorly five or six providers where most of the workloads are hosted, and that is what becomes the primary target for attackers because, if they are able to infiltrate one of them, they get huge access to all these company resources or whatever platforms are deployed on these resources”.

Vegiraju also points as to how attackers are now operationalizing the concentration risk, arguing that AI-assisted tooling has substantially lowered the cost and time required to scan a cloud environment, enumerate resources, and identify exploitable conditions. He goes on to explain that attacks have become cheaper with the rise of large language models and agentic AI, where spinning up an agent with expertise in carrying out a network or cybersecurity attack and pointing it at a set of resources to scan and enumerate is now well within the operational reach of most threat actors.

He identifies three structural shifts widening that exposure window simultaneously: identity architectures moving from flat to hierarchical as agentic systems replace individual user accounts, passwordless authentication replacing key-based systems and introducing new access control gaps in the process, and the rise of Model Context Protocol APIs enabling agents to interact with cloud resources without the operator fully understanding the underlying API surface - each of which creates entry points into the control plane that older security models were not designed to account for.

Attackers Rarely Start at the Control Plane

Most practitioners new to cloud security assume the control plane is where attackers begin, but in practice it is almost never the initial access vector - it is the objective that the entire breach path is working toward.

What attackers actually target first are secondary accounts and credentials with high privileges: developer tokens left in repositories, JWTs with long validation windows, service accounts granted broad access to solve a specific problem and never had their scope reviewed. These credentials are easier to find, easier to acquire, and sufficient to reach the control plane through a completely legitimate path.

“If you look at a typical breach path, these secondary targets are the ones that lead to the control plane,” Vegiraju explains. “You have a private or public key that is in a GitHub repo, or a JWT token with seven days of validation, or some developer accounts. These accounts have high privileges, and once you get access to them, you can query the control plane directly.”

What makes this breach path so effective is that control plane APIs are publicly available and designed to respond to valid tokens, which means an attacker with a legitimate credential does not need to break anything - they hand the token to the API and it does exactly what it was built to do, listing the resources, enumerating the infrastructure, and returning a complete map of everything that account can reach.

“Control plane APIs are publicly available,” Vegiraju notes. “You give that token to the control plane, and the control plane lists all the resources under that account. With that structure, you can do a targeted attack and reduce your targets to the specific storage buckets or resources you actually want.”

The path from a leaked developer credential to a full inventory of an organization’s cloud infrastructure is a single authenticated API call. This is the gap most organizations are not closing, because the focus stays on hardening the control plane perimeter while the actual breach path runs through credentials that predate the perimeter controls entirely.

What a Real Attack Path Looks Like

Walking through a concrete example is the clearest way to make the mechanics visible, and Vegiraju reaches back to an attack pattern from the early cloud era, around 2012 to 2013, whose underlying conditions show up in modern environments with different names but the same exploitable structure.

The attack centered on webhooks deployed on cloud instances. A webhook, for context, is a service that accepts an incoming HTTP request, performs a task, and sends a callback to a destination the caller specifies. Common in cloud architectures, and in themselves a completely normal operational tool.

The cloud instances running these webhooks had access to the Instance Identity and Metadata Service, or IDMS. This is a local endpoint available on every virtual machine in a cloud environment. Its purpose is to give services running on the VM a way to obtain authentication tokens for other cloud resources without storing credentials locally. The pattern works in a manner where a VM needs to read from a storage account, calls the IDMS endpoint, receives a token, and passes it to the storage service to authenticate without requiring to store credentials.

The IDMS endpoint was accessible via localhost with no authentication requirement, because the design assumption at the time was that anything running on the VM was already operating within a boundary that could be relied upon - which held true until an attacker found a way to make something outside that boundary call it anyway.

An attacker submitted a cURL request to the publicly exposed webhook. The webhook executed the cURL call against the local IDMS endpoint, retrieved a valid authentication token, and returned it to the attacker in the response. From there, the attacker called the storage bucket APIs with a token that carried broad access privileges, enumerated every bucket and object in scope, and exfiltrated data without triggering a single authentication failure because every action was legitimate from the API’s perspective.

“The control plane was indirectly involved, but it was not a direct attack on the control plane,” Vegiraju explains. “It was by getting the token and the combination of network security missteps plus broader access level that let the data be exfiltrated from storage buckets.”

Three conditions made this attack possible: an unauthenticated local endpoint, an overprivileged token, and no network controls restricting what the webhook could call outbound. None of those conditions is necessarily dangerous in isolation. Together, they created a complete breach path. This compound vulnerability pattern is what practitioners need to learn to look for, because fixing one condition while leaving the others in place does not remove the risk.

Three Places Cloud Security Teams Leave the Door Open

Vegiraju has identified three recurring gaps in how security teams approach control plane defense. Each is common enough to be structural rather than incidental.

API proliferation without inventory

Control plane APIs are not just CRUD endpoints. They include administrative APIs carrying elevated privileges, often created quickly to solve an operational problem and never formally tracked afterward.

“Sometimes these APIs have admin access,” Vegiraju explains. “In order to quickly solve a problem, a team creates an admin API with administrative privileges to what the control plane can do. When they expose it through the management API layer, only the CRUD operations are exposed. But unintentionally, the admin APIs sometimes get exposed as well.”

The deeper issue is the absence of a central inventory. “You end up spinning a bunch of these APIs and forget about them because there is no central place where you know what all APIs are available. Once you forget about them, these are publicly accessible but just not documented or listed to outside users.”

An undocumented API is still a reachable API. A human attacker working manually might miss an obscure endpoint. An agent scanning the full API surface methodically will not.

Overprivileged identities

Managed identities solve the credential rotation problem automatically, which is a real improvement over static keys. But rotation frequency does not determine access scope. The scope is still set by the operator, and it is consistently set too broadly.

“The access control still lies with me,” Vegiraju notes. “Each managed identity needs as restrictive permissions as possible. Basically, least privileges.”

An identity that can delete a storage bucket when it only needs read access to a single API endpoint is an identity an attacker can turn against its own environment without needing to escalate privileges at all. The damage potential is already built into the original configuration.

Broken regional isolation

Cloud providers organize resources into regions, and security teams often treat regional boundaries as access boundaries. They are not, unless explicitly configured to be.

“One API can access data from another region,” Vegiraju explains. “Region A has its own control plane, Region B has its own control plane, but a control plane in Region A can have permissions to access Region B, breaking the isolation factor. When a compromise happens, it becomes very hard to contain the attack and stop it.”

Regional isolation is a containment mechanism before it is a compliance concern. When a credential is compromised in one region, whether the attacker can pivot to another is entirely a function of how access scope was configured. Most organizations have not explicitly designed that boundary.

Agentic AI and the New Identity Architecture

Agentic AI systems introduce a structural challenge that flat cloud identity models were not built to handle. Understanding why requires a brief look at how cloud identity architecture has historically worked and where the new model diverges from it.

Traditional cloud identity is flat: a tenant contains accounts, each account carries a permission set, and security teams govern the scope of each permission set. The model works reasonably well when the number of identities is bounded and access patterns are predictable.

Agentic systems break both of those assumptions. An orchestrator agent directing multiple sub-agents creates a hierarchy of identities, each with its own access requirements and each representing a distinct failure point. If sub-agents share the orchestrator’s identity, a compromised sub-agent carries the full scope of the orchestrator’s permissions. The blast radius of a single compromised sub-agent becomes the blast radius of the entire system.

Vegiraju frames the principle through a practical example. “Let’s say I need to order food. The orchestrator agent knows how to do it: look at the menu, select the food, do the payment. Each of those tasks has its own sub-agent. The agent viewing the menu should not have permissions for any payment-related activity.”

The solution has two components. First, sandboxing at the AI layer establishes explicit API access lists for each agent, defining what it can reach and what it cannot. Second, each sub-agent gets its own managed identity scoped to its specific task. “Each sub-agent should get its own managed identity. You are able to control what the sub-agent can do because of what the managed identity has access to.”

Model Context Protocol APIs introduce a related complication. Agents interacting with cloud resources through MCP do not need to understand the underlying API surface. The MCP layer handles the translation. But that abstraction creates a risk: if the MCP API’s access is not explicitly scoped, an agent can reach resources it was never intended to interact with, and neither the operator nor the agent necessarily knows it is happening.

“If you are not controlling the access of this MCP API, it can lead to isolation problems where your API might result in access to resources it should not have access to,” Vegiraju explains.

The convenience and the risk are the same property. MCP makes agents powerful by abstracting away complexity. That same abstraction obscures the access boundaries that security depends on.

When the Stakes Scale Up

The security principles Vegiraju describes, network isolation, least privilege, and a complete API inventory, apply regardless of what the infrastructure supports. But the consequence of getting them wrong is not uniform across all deployments.

A compromised control plane governing a restaurant ordering platform is a recoverable incident. A compromised OAuth infrastructure governing emergency dispatch, 911 services, or financial systems operating at national scale is a different category of problem entirely.

“If the core infrastructure that governs your identities across emergency services, 911 services, fire services gets compromised, that is definitely a sovereignty problem,” Vegiraju says. “Either you are operating an emergency service or operating as simple as an inventory service. In any of the cases, the three security fundamentals stay.”

The fundamentals do not change with the stakes. What changes is the cost of every gap left unaddressed. The control plane does not know what it is governing. The teams designing and securing it do, and that is where the accountability sits.

You can also watch the full live session here.

THIS WEEK’S PERSON OF INTEREST

Danny Brickman — Co-founder and CEO, Oasis Security

Danny Brickman served in the Israeli Defense Forces in cyber research and development before co-founding Oasis Security in 2022 to address a class of identity risk associated with non-human identities which the security industry had not yet treated as a primary concern. In March 2026, Oasis raised a $120 million Series B led by Craft Ventures with participation from Sequoia Capital and Accel, following five times year-over-year ARR growth with a client base drawn predominantly from the Fortune 500.

The timing reflects a structural problem that has been building across enterprise environments. According to data cited by Palo Alto Networks, machine identities now outnumber human identities at a ratio of 82 to one, and that ratio grows with every new agent deployment, while the IAM systems governing them were designed for humans who log in, hold sessions, and get reviewed quarterly rather than for agents that act autonomously and continuously at machine speed.

At RSAC 2026, Brickman argued that the security model needs to shift from role-based to intent-based access control, because a static role assigned at deployment drifts from an agent’s actual behavior the moment its task changes, and the Vercel breach — where a developer authorized a third-party OAuth application with full read access and never reviewed it again — illustrates precisely what that governance gap costs in practice. (GovInfoSecurity, March 30, 2026)

SECURITY BRIEFS

Cloud credential theft, supply chain poisoning, and identity abuse across five incidents from the past six weeks.

UNC4899 Drains Crypto Wallets via Cloud SQL Manipulation

North Korea’s UNC4899 (TraderTraitor/Slow Pisces) opened with a trojanized Python file AirDropped to a developer’s personal device, escalated through Kubernetes container escape and CI/CD token abuse to full cloud admin access, then rewrote Cloud SQL logic to reset MFA seeds and drain high-value wallets. Google GTIG documented the full kill chain in its H1 2026 Cloud Threat Horizons Report.

Source: cloud.google.com

Lumma Stealer OAuth Chain Breaches into Vercel

A Lumma Stealer breach on a Context.ai workstation exfiltrated Google Workspace OAuth tokens, which threat actors used to pivot through a Vercel enterprise account and enumerate customer project environment variables. ShinyHunters claimed the data and listed it at $2M on BreachForums; Vercel and Google Mandiant are actively investigating.

Source: vercel.com

TeamPCP Backdoors Trivy, KICS, and LiteLLM

Between March 19 and 31, 2026, TeamPCP used stolen GitHub PATs to inject credential-harvesting scripts into Aqua’s Trivy, Checkmarx KICS, LiteLLM, and the Telnyx PyPI package, siphoning AWS, GCP, and Azure keys via IMDS and environment variables from downstream consumers. Wiz caught credential reuse across Azure, GitHub, and SaaS providers; Unit 42 published the full chain on April 9.

Source: unit42.paloaltonetworks.com

UAT-10608 Hoovers 766 Hosts into NEXUS Listener

Cisco Talos caught UAT-10608 exploiting CVE-2025-55182 (React2Shell) across 766 Next.js hosts to systematically pull AWS keys, SSH private keys, Stripe tokens, GitHub credentials, and Kubernetes service account tokens into a self-built operator dashboard called NEXUS Listener. Every hit shared the same root condition- over-permissioned identities with no need-to-know boundary.

Source: hackaws.cloud

React2Shell Unpatched Frontend Cracks LexisNexis AWS

In late February 2026, FulcrumSec exploited an unpatched React frontend at LexisNexis via React2Shell to reach its AWS environment, exfiltrating and publicly leaking roughly 2GB of customer names, user IDs, business contacts, and support tickets. LexisNexis confirmed the data predates 2020 with no active PII, but the incident is a clean case study in how app-layer debt becomes cloud-layer breach.

Source: BleepingComputer

Thank you for reading the second issue of Offensive Engineering on attacking the cloud control plane with Siri Varma Vegiraju. Part 2, covering the cloud data plane, is coming shortly.

Stay Curious, Stay Secure!

S Pattnaik

Data Practitioner

Technical Contributor, Offensive Engineering — InfoSec Relations

In this session of Offensive Engineering Live Sessions, Siri Verma Veggiraju, a tech lead at Microsoft Azure Security with hands-on experience across cloud security architecture, identity, and the control plane, walks through the mechanics of how these attacks actually unfold. He’s speaking independently, and the views he shares are his own.

The conversation covers:

• How the attack landscape against cloud infrastructure has shifted with large language models and agentic AI

• Why secondary accounts are the real entry point to control plane compromise

• What a realistic attack chain looked like in the early days of cloud, and why the same principles still apply

• How managed identities work and where organizations consistently over-privilege them

• Why API proliferation is a blind spot that most security teams underestimate

• What least privilege looks like when you’re securing sub-agents in a hierarchical AI architecture

• How to think about the line between a security incident and a sovereignty problem

That gap is not unique to conflict zones. Somewhere on the internet right now, an automated system is scanning an internet-facing asset that its service owner last tested who knows how many months ago. That is how the attacking side has operated for years. And what has changed, though, with the surge of AI integration into everyday workflows, is the capability behind the probe. Today’s AI-driven offensive tooling does not match signatures against known patterns. It reasons about what it finds, adapts in real time, and chains discoveries into exploit sequences that no existing signature would catch. And it does this at a scale no security team can replicate.

The security side has had no equivalent answer to that until now. And so this issue, featuring Albert Ziegler, Head of AI at XBOW and former Principal Researcher at GitHub, examines what it looks like when autonomous agents are deployed at scale on the defensive side — say five thousand coordinated agents running a single penetration test — with architecture and governance built for the reality that the attacker is already operating this way.

Before the feature, a short historical note on how the attacker’s tempo advantage began. And do check out the person of interest this week.

Closing the Container Security Gap

A live interview with Docker Captain Advait Patel on why engineering teams scan containers and still ship vulnerable images into production.

Register Now

THIS WEEK’S HISTORICAL NARRATIVE

How in November 1988 Automated Offence Got Its Head Start

On the night of November 2, 1988, Cornell graduate student Robert Tappan Morris released a self-replicating piece of code onto the early internet. The worm exploited three Unix vulnerabilities simultaneously and spread across the network faster than administrators could track it. Within hours it had compromised between six to ten thousand machines. People (administrators, developers, etc) spent three days on manual response, coordinating over phone lines, with no automated tool to match what was running against them.

Narrative Link: The Morris Worm Gave Attackers an Offensive Start — InfoSec Relations

The Insider View

Featuring Albert Ziegler, Head of AI at XBOW and former Principal Researcher at GitHub.

The Architecture of Autonomous Penetration Testing Agents

Enterprise security teams have for years accepted that penetration testing is non-negotiable and that doing it well requires human expertise that is expensive, scarce, and impossible to deploy at the frequency realistically required to tackle escalating attack surfaces. And the standard model that emerged from that constraint was periodic testing. Say, for instance, a qualified team comes in, works through a defined scope, produces a report, and the organization uses what they find to close the known gaps before the next scheduled assessment. The interval between assessments, often six months to a year for most assets and longer for anything that seems less critical, is not a security decision. It is a capacity decision driven by the availability of human experts who can only be in one place doing one thing at a time.

The attacking side of that equation does not operate under the same constraint, and it never did. Automated scanning tools have been probing public-facing assets continuously for as long as those assets have been online. But the current shift is qualitatively different from automated scanning. AI-powered offensive tooling does not just probe attack surfaces. It can, at scale, reason about the environment it encounters, adapt to what it finds, and chain discoveries into exploit sequences that a signature-based scanner would otherwise never identify because no signature exists for the specific combination of conditions it is exploiting. And it can do all of this at a scale and a speed that makes the gap between how often security practitioners test and how often attackers exploit wider than it has ever been.

Scale Changes Everything

Albert Ziegler has worked across AI systems and enterprise-scale engineering, first building GitHub Copilot and GitHub Advanced Security as Principal Researcher at GitHub, and now as Head of AI at XBOW, an autonomous penetration testing company whose assessments can involve five thousand agents working in coordination across a single customer’s attack surface. That number is worth sitting with for a moment. Over five thousand agents, coordinating across an assessment in real time, each one scoped to a specific task, each one reporting into a system that decides what to do with what they find.

The scale shift matters for a reason that goes beyond the obvious efficiency argument. “It used to be that you put a website online and pretty soon you got your first automated scan,” Ziegler explains. “Well, this pretty soon becomes shorter and shorter, as attackers can also leverage scale and they only need to be successful once.” The asymmetry has always existed in theory.

AI-powered tooling on the offensive side has made it operational at a scale that changes the calculus for every asset a security analyst manages, not just the crown jewels. Assets that were previously tested infrequently because they seemed less critical are now being probed by automated systems that have no cost constraint on which targets they include. If a security practitioner can only afford thorough testing for their most valuable assets, and an attacker can afford to probe everything continuously, then the less critical assets become the path of least resistance. Continuous AI-driven penetration testing is not a luxury upgrade on the standard model, but an appropriate defensive response to what the offensive side is already doing.

What an Assessment Actually Looks Like

The architecture of an XBOW assessment reflects a design philosophy that runs counter to the intuition that more capable agents should be given broader mandates. Ziegler’s team has found the opposite to be true in practice. The individual tasks that each agent is responsible for are deliberately small and tightly scoped, and the reasoning behind that constraint is architectural rather than conservative.

“It is much easier to design any agentic system where the individual tasks that one agent fulfills are small and validatable,” Ziegler explains. “So instead of sending one agent to go on a moonshot mission where they have a much too high quiver of arrows and a large chance to be lost, our aim is to have several small hops where the agents can be much more targeted, only get the tools that they actually need, and can have their results immediately verified.” The principle is the same one that makes microservices more maintainable than monoliths. Smaller scope means clearer failure modes, faster debugging, and results that can be verified before they influence the rest of the system.

A typical assessment begins with a small number of agents mapping the attack surface of the target asset. They have been told by the customer, who has manually verified ownership of the asset, to explore what the attack surface looks like and make preliminary notes about which parts warrant closer attention. That initial mapping feeds into a more specialized layer of work. One agent logs into the application and maintains an authenticated session, providing that session as a shared service to the other agents that need authenticated access rather than having each agent manage its own authentication state independently. This service architecture prevents the coordination overhead that would otherwise accumulate when multiple agents are individually trying to maintain valid sessions against a target that may rate-limit or lock accounts on repeated authentication attempts.

The attack agents themselves are given a specific methodology and a specific place on the attack surface to work against. An agent assigned to look for cross-site scripting vulnerabilities, for example, is not exploring the application broadly. It is applying a defined methodology to a defined target, iterating through variations over ten to forty attempts, and refining its approach based on the responses it receives from the application, whether through direct HTTP responses or through a headless browser that can observe what the page actually renders. The iteration loop is tight and observable, which makes it possible to monitor what the agent is doing and stop it if something looks wrong before it goes further.

The Validation Layer That Prevents False Findings

The step that separates a finding from a false positive in XBOW’s architecture is not the attack agent’s confidence in what it found. It is a separate validation agent whose sole job is to verify that the finding is real before it enters the system as a confirmed vulnerability. Ziegler describes the handoff with the specificity that makes it clear why this step is not optional in a system operating at this scale.

When an attack agent believes it has found something, it passes the finding to a validation agent along with the evidence it has been told to gather for that type of exploit. For a cross-site scripting finding, the attack agent would tell the validator that navigating to a specific URL in a browser would cause a pop-up to appear containing a specific string. The validator then checks this automatically, independent of the attack agent’s assessment. If the pop-up appears, the finding proceeds to the next stage. If it does not, the finding is discarded rather than carried forward as a probable or likely vulnerability that a human reviewer needs to assess.

“Agents often believe they have found something because the models are trained to please,” Ziegler explains. That observation deserves more attention than it typically receives in the broader conversation about deploying AI agents in high-stakes environments. A model that is rewarded for task completion will tend toward confidence about whether it has completed the task, and in a security context that means an agent that has not found a vulnerability will still tend toward interpreting ambiguous signals as evidence that it has. The validation layer is the architectural response to that behavioral property. It removes the agent’s assessment from the chain of custody for a finding and replaces it with an independent check that cannot be influenced by the agent’s confidence in its own work.

Findings that pass validation go through additional administrative checks for replicability and minimal reproduction steps before they are assessed for severity and delivered to the customer. The chain from initial probe to customer report is fully automated and fully verified at each handoff, which is what makes it possible to run at the scale that human-driven pen testing cannot approach.

Governance When the Agent Has Offensive Capability

The governance question for autonomous penetration testing systems is more demanding than the governance question for most other agentic applications because the capability being governed is inherently dangerous when misdirected. An agent that can find and demonstrate exploits in a target system can also, if its controls fail, find and demonstrate exploits in systems it was not authorized to test, or cause harm to the system it was authorized to test in ways that were not part of the assessment scope.

Ziegler’s framework for addressing this organizes around the same motive, method, and opportunity triad he has developed from his experience running assessments and thinking carefully about what it means to give AI systems offensive capabilities in controlled environments. All three conditions have to be addressed because eliminating only two leaves a residual failure path that a bad combination of circumstances can eventually activate.

Motive is addressed by designing the agent’s goals in a way that excludes harmful outcomes from the valid solution space. In the XSS example, the agent’s goal is to prove that a cross-site scripting vulnerability exists by making a pop-up appear in a controlled test. The goal is not to change application state, exfiltrate data, or cause any modification to the target that persists after the assessment. An agent pursuing that goal faithfully cannot cause the kind of harm that a broader mandate would enable, because the goal itself does not point toward it.

Method is addressed by giving agents only the tools their specific task requires. An agent assigned to probe for XSS vulnerabilities does not have the tools to modify server configurations, access databases, or reach endpoints that are outside the scope of its assigned methodology. The tool set is the boundary, and the boundary is set at the task level rather than the agent level.

Opportunity is addressed through real-time controls that operate on every action before it executes. “Every action that an agent takes will be checked by a safety model, as well as checked for certain keywords that could indicate the intent to harm, as well as controlled via egress,” Ziegler explains. Network egress is restricted to the customer’s verified assets, and even within those assets, sensitive endpoints that the customer has flagged as out of scope are excluded from what the agents can reach. The opportunity controls do not rely on the agent making the right decision about what to do with the access it has. They enforce the boundary regardless of what the agent decides.

What Changes When Governance Is Built for Agents

Ziegler draws a line between the governance model he built at GitHub for Copilot and the model he has had to build at XBOW for autonomous agents, and the contrast clarifies why most organizations that are currently deploying coding agents and testing agents with governance frameworks designed for advisory AI are going to encounter the gap eventually rather than avoiding it.

GitHub Copilot, at least in the version Ziegler worked on, was an AI-first product where a human was always in the loop and the primary risk was a wrong suggestion. Wrong suggestions are annoying and occasionally costly, but they do not cause harm in the way that agent actions can cause harm. The human reviewer was the safety layer, and the governance architecture could be relatively simple because the most dangerous thing the system could do was provide a misleading recommendation that a human then chose to act on.

Autonomous agents face a categorically different risk profile. “The risk is not that their suggestions are annoying but that their actions are harmful,” Ziegler argues, “and that needs truly new ways of addressing them that cannot just be written off as there is a human in the loop and they will stop anything problematic.” The human in the loop did enormous safety work in the advisory model, and that work has to be redistributed into the architecture itself when the loop operates at a speed and scale that human oversight cannot follow in real time. The governance controls are not a feature added on top of the system. They are the system’s safety guarantee, and they have to be designed with the same rigor and the same adversarial mindset that goes into designing the offensive capabilities they are containing.

The organizations building autonomous security testing capabilities today are navigating a design space that has no established playbook and limited precedent. What XBOW’s architecture demonstrates is that the constraints, the small scoped tasks, the validated handoffs, the independent verification layer, and the motive-method-opportunity governance triad, are not limitations on what autonomous agents can accomplish. They are the conditions under which autonomous agents can accomplish something reliably and at a scale that changes what continuous security coverage actually means in practice.

THIS WEEK’S PERSON OF INTEREST

George Hotz — Hacker, iPhone jailbreaking pioneer

George Hotz jailbroke the iPhone at seventeen, reverse-engineered the PlayStation 3, hunted zero-days at Google’s Project Zero, and built comma.ai’s open-source autonomous driving software to 100 million miles driven.

This month he challenged Anthropic and OpenAI directly, threatening to release a zero-day a day until a major new model dropped. His argument was simple: software vulnerabilities are not scarce because they are hard to find. They are scarce because finding them legally is restricted. Reports of AI-assisted exploit discovery costing $20,000 in compute drew a dismissal from Hotz, who said he would do it for less.

That argument matters here because it names a tension the rest of this issue circles. When autonomous agents can find and chain exploits at scale, the question of whether AI labs are raising legitimate dual-use concerns or using safety language to shape regulation becomes a live policy debate. Hotz has the track record to make that challenge credible.

SECURITY BRIEFS

State-linked intrusions, supply chain compromises, and AI-assisted attacks from the recent weeks.

Iran-Linked Handala Wipes Stryker Devices

Handala used Stryker’s own Microsoft Intune console to remotely wipe devices across 61 countries on March 11, disrupting manufacturing and shipping operations globally.

North Korea Poisons Axios npm Package

Sapphire Sleet published two malicious Axios versions on March 31, deploying a remote access trojan across an estimated 600,000 installs before removal three hours later.

Iran-Aligned Groups Surge After Operation Epic Fury

Following the February 28 US-Israel strikes, Unit 42 tracked roughly 60 Iran-aligned groups operating under a newly formed Electronic Operations Room, maintaining tempo via Starlink during Iran’s 47-day internet blackout.

AI Tool Hits 600 FortiGate Devices Across 55 Countries

CyberStrikeAI ran fully automated attacks against Fortinet infrastructure between January and February 2026 with no human operator directing individual steps.

Booking.com Breach Exposes Customer Reservation Data

Booking.com notified customers on April 12 that their names, addresses, phone numbers, and booking details had been compromised. The attack vector remains undisclosed.

Thank you for reading the first issue of Offensive Engineering, the newsletter from InfoSec Relations. We will be back next week.

Puspita Pradhan

Business Analyst & Researcher

Technical Contributor for Offensive Engineering (by infosecrelations.com)