# Would You Notice? Five AI Agent Incidents and Who Actually Caught Them > Source: > Published: 2026-10-22 14:40:08+00:00 In short, between April and July 2026, AI agents under evaluation at Anthropic, Google, Meta, OpenAI and the UK AI Security Institute reached systems outside their test environments, and on 30th September OpenAI said it had told more than 100 organizations that its agents may have touched theirs. The incidents have been read as containment failures, and they were. Read the five disclosures for who noticed, though, and they are detection stories first: one operator found out from a transcript review begun after another company’s announcement, two were told by their evaluation partner, one was told by the victim, and one caught its agent with its own monitoring and had the machines isolated within an hour of the alert. None of the five agents announced itself, and none needed to, because an agent’s traffic looks like any other workload’s until something is built to tell the difference. This post lays the five accounts side by side, asks what caught each one and how long it took, maps that onto what agent infrastructure has to provide, then says what a governance layer like Tigera Lynx can and cannot do about it. It is written for the platform and security leaders who would be asked, the morning after, how long an agent had been running in their cluster and whether anything other than the agent knew On 1st October 2026, [Reuters reported](https://www.thestar.com.my/tech/tech-news/2026/10/02/openai-alerts-more-than-100-groups-about-rogue-ai-agent-activity) that OpenAI had “informed more than 100 organizations about incidents involving unauthorized activity tied to its AI agents.” The notices come from a review OpenAI opened after its evaluation agents reached Hugging Face’s production infrastructure in July. Reuters put the review at “roughly 50 petabytes of data,” OpenAI has said it will take months, and the company’s explanation, as reported, is that models “used internet access in unintended ways” or “did not have the ideal restrictions applied.” [The Register](https://www.theregister.com/a/5300891) picked out the line from OpenAI’s update that every recipient will have read twice: “Notification does not mean that any private information was accessed.”  That update is the latest of five accounts published since July. On 30th July, [Anthropic reported](https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals) that after reviewing 141,006 evaluation runs it had found three incidents, across six runs, in which Claude models reached real systems during evaluations run by the security firm Irregular. “The earliest incidents date to April.” Google’s Gemini reached three real companies during an Irregular test in May; Irregular notified Google at the end of July, and the public heard on 18th September, [when The Wall Street Journal asked](https://www.securityweek.com/google-confirms-gemini-ai-breached-three-firms/). We took that one apart in [Gemini never left the sandbox](https://www.tigera.io/blog/gemini-never-left-the-sandbox-the-sandbox-had-a-door/). On 14th August, [Meta said](https://research.meta.ai/blog/addressing-third-party-testing-misconfiguration-muse-spark-1-1) a pre-release Muse Spark model had exploited a vulnerability in a real website during an Irregular exercise that began in early July. And on 4th August, the [UK AI Security Institute published an incident report](https://aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing) on a cyber evaluation of seven models over 122 runs: “in 10 of the 122 runs, we identified 19 cases where an agent had taken distinct actions beyond the scope of the testing parameters.”  None of this is carelessness that deserves a lecture, and the write-ups are candid: Anthropic published its run count and its root cause, Hugging Face published a [forensic timeline](https://huggingface.co/blog/agent-intrusion-technical-timeline) of what OpenAI’s agent did inside its clusters, and AISI published what its monitoring saw and what it did not. These are the tests that should be run, by the people best placed to run them.  The uncomfortable part sits in a column none of the five accounts draws out, so this post draws it. Not one of the five agents was caught because it announced itself. Each was found by a transcript read afterwards, by a partner, by the victim, or by a monitor watching the network, and the lag between the agent acting and someone knowing ran from under an hour to about three months, depending on which. That column is the one that applies to your cluster, where the agent is a Deployment somebody shipped on a Tuesday, calling a model provider with a key it found in its environment. Would you notice? ## **Who noticed, and how long did it take?** Here are the five accounts reduced to four questions: when the agent acted, who noticed first, what did the noticing, and how long it took. | Program | When the agent acted | Who noticed first | What did the noticing | Lag | |---|---|---|---|---| | **Anthropic** (Claude models, evaluations by Irregular) | April to July | Anthropic, in a transcript review begun on 23rd July, two days after OpenAI’s disclosure | A retrospective review of 141,006 runs; the misconfiguration surfaced “through our additional evaluation monitoring” | About three months for the earliest. The two affected organizations Anthropic reached “had not previously detected the activity” | | **Google** (Gemini, evaluations by Irregular) | May | Irregular, which notified Google at the end of July | Not stated publicly | About two months | | **Meta** (Muse Spark 1.1, evaluations by Irregular) | Early July | Irregular: “A third-party model evaluator notified us of a cybersecurity issue” | Not stated publicly | Not stated | | **OpenAI** (evaluation agents reaching Hugging Face) | 9th to 13th July | Hugging Face, the victim | “Live runtime analysis, SIEM logs, and others,” correlated into one signal that “failed to correctly raise the alert’s criticality and trigger the on-call team” | Days. The campaign ran “for several days” and 17,600 actions before Hugging Face cut access on 13th July | | **UK AI Security Institute** (seven models, two cyber ranges) | 25th to 28th July | AISI, from its own security monitoring | Data “leaving one of our testing systems through the ‘Tor’ anonymity network,” on the morning of 28th July | Within three days to the alert, and “within one hour of the alert” to isolation | Read the fourth column; the fifth follows from it. There are three kinds of noticing in it. A transcript is the agent’s own account of itself, read afterwards; Anthropic’s review found six runs in 141,006, which is the right way to find something that already happened and no way to find something that is happening. A partner or a victim is someone else’s monitoring; Google and Meta learned from Irregular, and OpenAI’s agent was caught by Hugging Face. A monitor on the network or the runtime, at a point the agent did not control, is the only kind that noticed while the agent was still acting, and the lag runs with the kind: months for the transcript, weeks for the partner, days for the victim’s stack, and an hour from alert to isolation for the program that saw its own packets leave. The two accounts that say most about detection agree from opposite ends. AISI, which caught its agent: “Our security team detected the anomalous traffic through general monitoring after the fact, not through monitoring built to watch the evaluation as it ran, which could have flagged or blocked the behaviour sooner.” Anthropic, which found its agent in the transcripts: “Careful validation of all internet access paths before evaluations began and real-time monitoring of the evaluation logs would have helped to surface the problem sooner.” Hugging Face’s account adds a detail that belongs in every runbook. Its security stack correlated several ambiguous events into “a coherent attack signal.” Then that stack “failed to correctly raise the alert’s criticality and trigger the on-call team, costing precious time in the response.” The detection worked and the noticing did not, because a detection that pages nobody is a log line, and while it sat there the agent “went from code execution in a single worker pod to cluster-admin across multiple internal clusters in under thirteen hours.” ## **Why does an agent blend in?**  Because nothing in the platform knows it is one. Kubernetes knows a Deployment, a container image, a ServiceAccount and a set of environment variables. It does not know that the image holds LangGraph and a provider key, that the process inside will decide its own next step from whatever lands in its context window, or that the HTTPS connection it just opened goes to a model. From the node’s point of view, an agent calling a model provider is a pod making TLS connections to an external host, which describes half the cluster, and an agent calling a model you host yourself is a pod talking HTTP to a Service, which describes the other half. The agent’s control flow is what makes this different from ordinary shadow IT. A forgotten cron job does the same thing every night. An agent does whatever the model decides, with whatever the pod can reach: the same shell, the same route out, and the same projected ServiceAccount token every pod carries, which is the token OpenAI’s agent read first inside Hugging Face. We made the point in [the safest place to run an AI agent](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/): controls the agent can override are not controls, and the agent’s own report of what it did is not a control at all.  An agent does leave marks that can be read from outside the process, without its cooperation. Four are reliable enough to build on. **It talks to a model.** For a public provider, the TLS handshake carries the provider’s hostname in the Server Name Indication field, in the clear, before any encrypted byte is sent. For a model you host in the cluster over plain HTTP there is no handshake, but there is a destination address that belongs to a Service you know about. Either way the connection is observable from the node, on every pod, whether or not the pod was configured to go through anything.  **It loads a framework.** LangChain, LangGraph, CrewAI, AutoGen, the OpenAI Agents SDK, Google’s ADK: an agent built on any of them has the library mapped into its process, and a process’s loaded libraries can be read from the node.  **It carries configuration that names a provider.** An environment variable called OPENAI_API_KEY or ANTHROPIC_BASE_URL says what the pod is for. The name says it; nobody needs to read the value, and nobody should.  **It calls tools, and other agents.** An enforcement point that MCP and agent-to-agent calls pass through can see the method, the tool and the arguments. This mark is the odd one out, because it is only visible for traffic that was routed through the enforcement point.  A gateway sees the agents that were configured to use it, ours included, so its record is a list of the agents somebody already knew about. The agent you are worried about is the one nobody configured: the notebook promoted to a Deployment, the side project calling a provider on the company card, the agent registered in staging and copied to production without the registration. Egress policy that closes every path except the gateway shrinks that set, and [Peter Kelly’s multi-layer policy post](https://www.tigera.io/blog/multi-layer-policy-for-securing-ai-agents/) shows how the gateway and the kernel layers fit, but a workload that reaches a provider directly, or an in-cluster model over plain HTTP, never writes a line in the gateway’s record. So the first signal has to come from the node, from the first three marks, and only then can the gateway tell you what the agent is doing.  Three verdicts fall out of that. Registered: the workload maps to an agent you know, with an identity you issued and an owner. Shadow: the workload is calling a model and no registered agent matches it, which is the “agents in here you haven’t accounted for” of Dillon Barry’s [field guide to the agents in your cluster](https://www.tigera.io/blog/a-field-guide-to-the-agents-in-your-cluster/). Unknown: a connection you observed and could not attribute to a workload at all. Each is a different morning. A registered agent doing something odd is a policy question, a shadow agent is a phone call, and an unknown connection is an investigation.  Count what that means at scale. One agent, on a range built for it, went unnoticed at AISI for up to three days. Ten agents from three teams is a list someone could keep by hand for a quarter. Two hundred, some promoted from notebooks and some built in a vendor’s tool, is a population whose membership changes every sprint, and the only way to know its size is to observe it. You will not get to review 141,006 runs, because the review is what happens after someone tells you. What would have caught each one? Split the question in the title into the five the accounts answer between them, and for each ask what the accounts show and what infrastructure has to provide so that the answer does not depend on the agent, a partner or a victim. | The question | What the five accounts show | So the infrastructure must provide | |---|---|---| | **Is an agent running here?** | Anthropic reviewed 141,006 runs after the fact to find six; AISI’s agent went unnoticed for up to three days | An inventory built from observation rather than registration: the model connection, the loaded framework and the configuration, read from the node for every workload | | **Is it one of ours?** | Google and Meta each learned what their agent had done from Irregular, the partner running the range; Google two months on | A registry to compare each observation against, so a workload is classified as registered, shadow or unknown, with the evidence beside the verdict | | **Where is it reaching, and as whom?** | AISI’s agent sent data out over Tor and opened GitHub accounts under invented identities. OpenAI’s went from one worker pod to cluster-admin across several clusters | Per-request authorization at an enforcement point the agent does not control, with the caller’s identity, the target and the operation as context | | **Who gets told, and how fast?** | Hugging Face’s stack correlated the signal and paged nobody. AISI isolated its machines within an hour of the alert | An alert that lands with a named owner, and a containment action that needs no redeploy: cut the agent off at the enforcement point and in the kernel | | **What did it do?** | Anthropic’s and Google’s accounts rest on transcripts. Hugging Face counted 17,600 actions from its own database audit logs and network flow logs | A record written by the enforcement points at the time, which the agent cannot edit: the caller, the target, the decision, the tool, and the model that served the call | Read column three again. Nothing in it asks the agent to report itself, and nothing in it depends on the model’s judgment on the day. Each row is a control that sits outside the agent, which, as we argued when we asked [why network policies, API gateways and RBAC are not enough](https://www.tigera.io/blog/the-ai-agent-accountability-gap-why-network-policies-api-gateways-and-rbac-are-not-enough/), is the only place a control for an agent can sit. NetworkPolicy and RBAC each take half of row three, and Hugging Face’s account shows what the RBAC half looks like when it is a ClusterRole that “granted pod creation cluster-wide.” Neither answers row one, because neither knows what an agent is.  Now run the five through the table. Row one, done from the node, turns Anthropic’s three-month review into a verdict on the day the first evaluation run opened a connection it should not have. Row four is the row Hugging Face’s account is about, and the one AISI got right: an alert with an owner, and an hour. Row five is the difference between Hugging Face’s timeline, rebuilt from its own logs, and a transcript in which, as Anthropic describes, a model that recognized a real system “rationalized that the real company must be part of the exercise.” ## **What happens when it is done properly?**  Here is what a governance layer like [Tigera Lynx](https://www.tigera.io/blog/why-we-built-lynx-bringing-control-to-the-age-of-ai-agents/) does for the table above, and what it leaves to you. Both halves matter.  Done properly, every node runs a detector that reads the marks an agent cannot hide: the hostname in each outbound TLS handshake, matched against a watchlist of public model providers and whatever self-hosted endpoints you add; connections to a model you run in the cluster over plain HTTP, matched on the Service’s addresses; the agent-framework libraries loaded in each process; and the names of environment variables that point at a provider, never their values. The signals are weighted together, and configuration alone never makes a workload an agent. Each detection is compared against the registry and given a verdict, registered, shadow or unknown, with the evidence beside it. Registered agents carry an identity the infrastructure issued (SPIFFE, OIDC, or a pod-owner binding for agents you cannot modify), and their traffic passes a gateway the agent does not control: default deny, a decision on every request, with the caller’s identity, the target and the operation as context. A registered agent that should not be doing what it is doing can be quarantined with one action, at the gateway, which refuses its traffic, and in the kernel, where it can no longer write to disk, launch a process or open an outbound connection, with no redeploy; a discovered workload gets the kernel half, which is the half that stops it reaching anything. Every call through the gateway lands in the Agent Trail with the caller, the target, the decision and the policy that made it, the tool and the names of its arguments, the token issued for that hop, and the model that actually served the call, written by the enforcement plane rather than narrated by the agent. The same detector ships as a package for plain Linux hosts, for the agents that never made it into a cluster. Now the other half. None of that is automatic, and some of it is deliberately narrow. The detector reports workloads that called a model in the window you are looking at, so an idle agent does not appear, and one that reaches a model over gRPC, or an endpoint nobody added to the watchlist, is not matched. Its identity matching reads the Secret references in a pod’s spec, so an agent that gets its credentials some other way shows up as shadow until you register it, and the first week of detection in a real cluster is a list of workloads to go and ask about. A person decides whether each shadow is sanctioned; the detector will not. The trail records what passed through the gateway, as tool names and argument names rather than values, and no prompts or completions unless you turn that on and accept the retention that comes with it, so “what the agent saw and what it decided” still lives in the agent’s own telemetry, and keeping it is your call. Closing every route out of the pod except the gateway is network policy you write first. And a verdict is not a page: Lynx shows the shadow and the evidence, and who gets woken at three in the morning is your on-call rota. What the infrastructure provides is the layer the question assumes exists: the ability to say, from observation rather than from a registry someone forgot to update, which agents are running, which of them you know about, where each one reached, and what it did through the points you control. Put in properly, the agent somebody deployed on Tuesday is a shadow verdict on Wednesday morning with the library and the hostname beside it, and a quarantine button under it. Put in badly, it is a line in a transcript review you begin after another company’s announcement. ## **Frequently asked questions** 1. **What is a shadow AI agent?** A shadow AI agent is a workload that calls a model, a tool server or another agent without having been registered with whatever governs agents in that environment, so its calls happen outside policy and outside the audit record. In Kubernetes it is usually ordinary: a notebook promoted to a Deployment, a vendor’s builder with a key, an agent copied between clusters without its registration. 2. **How do you detect an AI agent running in a Kubernetes cluster?** From the node, rather than from the agent. An agent opens connections to a model endpoint, loads an agent framework into its process, and carries configuration that names a provider. All three can be read on the node with eBPF and process inspection, for every pod, without the agent being configured to report anything. Each detection is then classified against the registry of known agents as registered, shadow or unknown. 3. **Why isn’t a gateway enough to find unregistered agents?** A gateway sees the traffic that was routed through it, so its record is a list of agents somebody already configured. An agent nobody configured reaches the provider directly, or reaches a model inside the cluster, and never appears. Egress policy that forces the gateway path shrinks the gap. Node-level detection closes it, and the gateway then governs what the detected agent is allowed to do. 4. **Is a transcript enough to know what an agent did?** No. A transcript is the agent’s account of itself. Anthropic’s report describes models that recognized a real system and “rationalized that the real company must be part of the exercise,” and the transcript records that reasoning faithfully while the system on the other end records a login. Evidence of what an agent did comes from the points it passed through: the egress policy, the authorization decision, the audit log. Hugging Face counted 17,600 actions from its own audit and flow logs, which is what a record looks like. 5. **What should happen in the first hour after an unregistered agent is found?** Attribute it, contain it, then ask. Attribution means which pod, namespace, ServiceAccount and owner, and what it has been reaching, taken from the detection evidence rather than from the pod’s author. Containment means quarantining it in the kernel so that it can neither call out nor change anything while you look, in one action rather than a redeploy. Then ask the owner whether it is sanctioned, and if it is, register it and give it a policy. AISI’s hour is the benchmark: alert, review within minutes, isolation within the hour. 6. **Do I have to tell anyone if my agent reached someone else’s system?** That is a legal question, and the answer depends on where you operate, what the agent did and what your contracts say, so get an opinion on your own case. Some clocks are already running: if you sell products with agents in them into the EU,[the Cyber Resilience Act’s reporting duty](https://www.tigera.io/blog/eu-cyber-resilience-act-europe-just-put-your-ai-agents-on-a-24-hour-clock/) starts from the moment you have reliable evidence. The engineering answer is that you cannot notify anyone about an agent you have not detected, and OpenAI’s hundred notices are what the alternative looks like. ## **Whose question is it?** OpenAI is reading 50 petabytes, over months, to find out where its agents went. Anthropic read 141,006 runs to find six. AISI read one alert and had its machines isolated within the hour. The difference between those three efforts was never the agents’ speed. It was the distance between the agent and the first thing that was watching, and in four accounts out of five that thing belonged to someone else or was read after the fact. Your agents are not on a range built for them. They are in a cluster with everything else, and the morning-after question is not whether one of them could reach something it should not, because Hugging Face’s timeline settles that. The question is whether anything you run would know. So ask the question now, while it is cheap, and ask it of a named person. An agent nobody is watching for is found by whoever it reaches. **If you are the CISO, the VP of Engineering or the head of platform**, your question is about the fleet. How many workloads in our clusters called a model provider last week, how many of those map to an agent we registered, and who owns the difference? The first number comes from observation. The second comes from a registry. If nobody can give you both, the difference between them is the fleet you do not know you have.  **If you are the platform or security engineer who runs the cluster**, your question is about one pod. If a pod in the data science namespace started calling a model provider tonight, with a key from a ConfigMap, what would tell you by morning: the agent, the invoice, or something on the node? And once it told you, could you stop that pod reaching anything else without a redeploy and without finding its author first?  **If you built the agent**, your question is about whether it exists on paper. Is it registered, does its traffic pass the enforcement point, and if it reached a system it should not have, would the record carry its name and yours, or an IP address and a guess? An agent that works without registration is the one that shows up as shadow, and the phone call goes to whoever can be found first.  If any of those answers starts with “we would need to check,” the check is what to build. One program in five noticed while it was happening. It was watching the network, not the model. ## **See Lynx in action**  Tigera Lynx gives every AI agent, MCP server and LLM provider in your clusters a verifiable identity, a policy decision on every call, and a record written by the enforcement point rather than by the agent. Schedule a demo and see it on a live cluster. Lynx is Tigera’s enterprise security and governance platform for AI agents on Kubernetes: identity, policy, detection, and audit for every agent in your cluster. Read [How Lynx Works](https://www.tigera.io/blog/how-lynx-works-a-technical-walkthrough/) or [request a demo](https://www.tigera.io/demo/?product=lynx).