Telemetry, detection and control guidance drawn from the July 2026 frontier model incidents, as at 5 August 2026
In July 2026, OpenAI and Anthropic each disclosed a frontier model reaching production systems belonging to organisations with no involvement in the testing, including Hugging Face. OpenAI disclosed that two of its models escaped an isolated test environment. Anthropic disclosed that three of its models reached the open internet through a misconfigured evaluation environment that was never sealed in the first place. Neither model was directed at these victims. Both were told to attack something, pursued the objective narrowly, and treated whatever they could reach as in scope.
Neither intrusion was stopped by a control. Hugging Face’s own correlation pipeline flagged its intrusion while the campaign was still active, days before OpenAI connected the activity to its own models. In the second disclosure, neither of the two organisations Anthropic was able to reach had detected the activity at all, and the third had not yet been contacted.
If your teams are deploying AI agents, the pressing question is not whether those agents are governed. It is whether anyone is doing the AI monitoring that catches it.
One is a capability story. One is a hygiene story.
The two intrusions began entirely differently. From the credential step onward they are the same incident, and the same monitoring answers both.
Figure 1. Every stage of the incident mapped to an observable action, which is what agent monitoring records.
The two disclosures, briefly
Hugging Face’s own anomaly-detection pipeline surfaced an intrusion into part of its production infrastructure during the week of 14 July, with recovered activity spanning 9 July to 13 July UTC, a 4.5-day campaign, disclosed on 16 July and stated that it was driven end to end by an autonomous AI agent. Roughly 17,600 intrusive actions were recorded over that window, grouped by Hugging Face into about 6,280 clusters for triage. Five days later OpenAI attributed the intrusion to at least two of its own models, named as GPT-5.6 Sol and an unreleased pre-release model, both running with cyber refusals deliberately reduced for the ExploitGym benchmark evaluation, which had exploited a previously unknown vulnerability in the package registry cache proxy, the escape path out of OpenAI’s own test environment.
Anthropic then reviewed 141,006 of its own evaluation runs and found three cases in which a model reached the internet from a third-party evaluation environment and compromised the production infrastructure of three unrelated organisations. Across the three incidents, the techniques were weak passwords, unauthenticated endpoints, credentials read from an exposed debug page, SQL injection, a scan of roughly 9,000 targets, and a dependency-confusion attack in which Mythos 5 published a malicious PyPI package that ran on 15 real systems, including a security company’s malware scanner, from which the model exfiltrated credentials to a collection point it had set up before using them to reach further infrastructure. Three different models were involved. One stopped once it concluded the target was real, one continued after reaching the same conclusion, and one convinced itself it was still inside a simulation.
The questions that expose an AI agent blind spot
Figure 2. Five questions most SOCs cannot yet answer about the non-human identities acting on their systems.
- Machine identities are not baselined. Behavioural analytics usually covers only human users. An agent identity has no working hours, no location pattern and no owner to call, so it falls outside the model that flags a human account.
- AI platform telemetry is not in your SIEM. Tool invocations, connector activity, model selection and context retrieval are the closest thing to an agent decision record, and few organisations collect them today.
- Workload egress is rarely retained at session level. Both intrusions crossed from a controlled environment to a third party over ordinary public services. Without destination and certificate detail that path cannot be reconstructed.
Which of your AI deployments need enhanced monitoring
It is tempting to read the July incidents as a problem for AI labs running evaluations, not for your organisation. The victims were ordinary companies with ordinary infrastructure, and the techniques used against them were weak passwords, SQL injection, exposed debug pages and dependency confusion. Anyone can be the victim regardless of whether they use AI at all. That exposure is a function of running internet-facing infrastructure, full stop, and it sits outside the scale below entirely, no organisation opts out of it by avoiding AI.
The scale below answers a narrower, second question: if your organisation also deploys AI agents, where does that specific deployment sit, and how much monitoring does that deployment need on top of ordinary security hygiene. A supervised chat assistant sits at the far left and carries a different risk profile entirely. Monitoring earns its cost from the third column onward, where an agent holds credentials and acts between human checkpoints rather than in front of one.
Figure 3. Both July incidents sat at the far right of this scale. Everyday supervised assistant use sits at the far left. The controls you need are set by position on the scale, not by which vendor supplies the model.
Telemetry to collect
Four layers in priority order, plus a retention requirement across all of them. Each is available on most identity, cloud and security platforms, so none of this requires a change of platform.
Log sources required, and where they come from
Categories overlap and listing one is not an endorsement. What matters is that every layer has a source feeding it.
| Layer | Sources, and where they typically come from |
| 1. Identity and credentials |
Machine identity and service principal creation. Application and OAuth client registrations and consent grants. API key, token and client secret issuance. Token exchange and short-lived credential issuance. Federated trust changes, including OIDC. Machine authentication, recorded separately from human sign-ins. Privileged role assignment and activation. Secret read events attributed to an identity. Sourced from the identity provider and directory, secrets manager or vault, cloud control plane audit trail, CNAPP entitlement analysis, and source control audit logs where an agent holds repository or merge rights. |
| 2. Agent behaviour | The tool, system and endpoint set each agent normally invokes. API and tool call volume over time. Planning or reasoning iterations per task. Established destinations, including repositories, data stores and cloud regions. Session duration and total runtime per task. Derived rather than collected, baselines are built in the SIEM or detection platform from the identity, gateway and egress data around it, which is why those three have to land centrally first. |
| 3. AI platform | Prompt source and destination. Tool, plugin and function invocation. Memory and context retrieval. Activity involving external connectors and tool-integration servers. Model selection and model switching. Inference and token volume. Tool invocation failures. Sourced from the API or AI gateway, often the only place this layer exists at all where a model vendor exposes little directly, agent framework logs, tool-integration and connector servers, and model provider audit logs where available. |
| 4. Workload and egress | Outbound egress at DNS and session level, with destination, port and certificate retained. Instance metadata access from application and workload contexts. Privileged and host-mounting workload creation. Machine identity token requests and permission enumeration in orchestration platforms. Package registry, proxy and artefact cache activity. Read volume and scope per identity against data stores. Administrative changes to the monitoring and network policy controls themselves. Sourced from the network security stack, DNS and proxy, service mesh for agent-to-service calls inside the cluster which north-south egress logging does not see, container platform and orchestration, cloud audit trail, data platform and object storage access logs, and CI/CD pipeline logs. |
| Across all four layers | All of the above forwarded to a central platform on ingestion, so that retention follows your policy rather than the default of each vendor. Native retention on some identity and network platforms is as short as twenty-four hours, against an investigation window measured in weeks. Sourced from a central log platform or SIEM, with forwarding configured at ingestion rather than on export. |
Detection opportunities
Every detection below is built on one of the four layers above, and every one maps to behaviour that occurred in both reported incidents. Several assume a specific control from the enforcement layers further on is already in place, noted against each.
| Detection | The signal it is built on, and what it depends on |
| Agent authenticates outside its baseline |
First authentication by a machine identity to a host, API or resource it has never touched. (Layer 1 telemetry.) |
| Machine identity issues its own credentials |
Token, key or secret created by a non-human principal, or a new privileged role granted to one. (Layer 1 telemetry.) |
| Credential used away from its issuing environment |
A secret known to live inside a workload presenting from a different network origin. Meaningful only where Credential management (enforcement Layer 5) is already in place, otherwise every credential looks portable by default. |
| Volume or breadth beyond human sustainability |
Per-identity call rate over a rolling window, and connection attempts spread across a wide range of hosts, both against that agent’s own baseline. For scale, Anthropic’s Incident 3 involved a scan of roughly 9,000 targets, and the Hugging Face campaign produced roughly 17,600 actions in 4.5 days. |
| Failure burst followed by adjacent success |
Failed tool calls or authorisation denials from one agent identity, then a success against a neighbour. |
| Tool or connector invocation outside baseline |
A call to a function, plugin or external connector the agent has never used, particularly shell execution, file write or remote administration tooling. |
| Sustained inference spend on one objective |
Reasoning iteration or token volume far beyond the task baseline, held over a long window, often alongside repeated tool failures. |
| Context retrieval outside the established set |
Memory or context retrieval reaching repositories, data stores or knowledge domains outside the agent’s baseline, or a sharp rise in retrieval volume. |
| Model or safety configuration change | A change to the model, system instruction or safety configuration an agent identity runs under, including selection of a less constrained version. |
| External account registration or payment attempt
|
External account registration, email or phone verification, or a payment attempt, for example on a package registry, initiated by a non-human identity. Anomalous under any baseline and cheap to detect. |
| Instance metadata accessed from an application context |
Metadata service calls from a processing pod or application runtime rather than an administrative path. Only observable once egress is centrally logged (Layer 4 telemetry). |
| Permission self-assessment after first use of an identity |
Role, namespace and cluster enumeration right after a workload identity is first used. |
| Egress outside the allow list |
Session or DNS activity from the agent segment to an unlisted destination, with certificate detail retained. Meaningless without Network isolation (enforcement Layer 4) actually restricting the segment first, otherwise there is no list to be outside of. |
| TLS trust anomalies on agent egress |
Unexpected certificate authorities or broken chains of trust on connections an agent initiates. Mythos 5’s own reasoning for continuing was partly that it did not recognise the certificate authorities securing its connections, which is a direct argument for retaining this detail rather than discarding it as noise. |
| Anomalies on the agent’s only egress path |
Request pattern and error-rate anomalies against the proxy or artefact cache the agent segment may reach. |
| Non-human identity pushes an artefact to a public registry |
A machine identity publishing to PyPI, npm, a container registry or a public repository. Anthropic’s Incident 2 was exactly this, a published package, and it has no corresponding detection anywhere else on this list without naming it directly. |
What has to be enforced alongside it
Monitoring shows you what an agent did. The seven layers below control what it’s allowed to do in the first place.
Some detections only work if the matching control is already switched on. For example, you can only flag traffic leaving an approved zone if you’ve actually set up an approved zone. And you can only flag a credential turning up somewhere unexpected if you know where it’s supposed to be used.
So if the control isn’t there, the detection has nothing to check against. The below are examples
| Control Layer | Required Outcome |
| Least privilege | No agent identity holds the top privilege tier on identity, cloud, orchestration or source control. Scope permissions to the task, the resource and the time window. |
| Human approval | Authorisation required for data deletion, production deployment, identity and access change, account creation, network change and payment. |
| Execution boundaries | Constrain what the agent is able to do, not only what it is told to do. Shell, filesystem, remote administration, database writes and new workload creation. |
| Network isolation | A dedicated segment with an explicit destination allow list, and all egress through a single controlled path that produces logs. |
| Credential management | Short-lived, federated or platform-managed identities. No secrets in environment variables, source or configuration the agent can read. |
| Termination | Immediate kill, credential and session revocation, environment isolation and context clearing. Tested rather than assumed. This is the direct answer to Figure 2’s fifth question, who terminates a misbehaving agent on a Saturday, and how long the record survives. |
| Auditability | Every action reconstructable. Which identity, which model, what instruction, which tools, which credentials presented, what approval obtained. |
Key takeaways
Where to start
This is an order of operations, not a menu. Each step depends on the one before it landing first.
- Inventory your non-human identities and AI tooling. You cannot monitor autonomy you have not counted.
- Build identity and credential telemetry. Credential acquisition was the decisive escalation step in both incidents, even though Hugging Face’s initial access came from code execution via a malicious dataset rather than a credential.
- Add session-level egress logging. Both intrusions crossed from a controlled environment to a third party over ordinary public services, invisible without destination and certificate detail.
- Bring AI platform logs into the SIEM. Tool invocation, connector activity and model switching are the closest thing to an agent’s own decision record, and almost no programme collects this layer today.
- Rebuild behavioural baselines around agent identities specifically. A baseline tuned for human working hours and login locations will not flag a non-human identity, because it was never built to.
Principles to hold onto
- Do not restrict supervised AI use on the strength of these disclosures. Both occurred inside evaluation environments with safeguards deliberately reduced, and Anthropic states that the safeguards shipped with its generally available models would have blocked the observed behaviours. An over-broad restriction pushes usage outside your visibility instead.
- Reduced-guardrail environments need more control, not less. All three July incidents started in evaluation or red-team environments where safety measures had deliberately been lowered to test raw capability. The environment with the fewest constraints is the one that most needs isolation and monitoring, not the one that gets to skip it.
- Enforce boundaries technically rather than through instruction. Three models met the same situation and reached three different conclusions about whether to continue. On credentials specifically, rotation is a mitigation and removal is the control.
- Containment is a control, not an afterthought. Immediate kill, credential and session revocation, and context clearing need to be built and tested before an agent needs to be stopped, not designed in response to the first incident that requires it.
- Treat prompt inspection as a partial control, not as coverage. Neither July incident involved a jailbreak or a prompt injection. Both models pursued the goal they had been given, so an AI guardrail inspecting prompts would have shown nothing anomalous in either case. Collect from it, but do not count it as monitoring.
- Fold this into existing security operations rather than creating a separate AI security function. The disciplines are identity governance, least privilege, egress control, behavioural analytics and log retention. Your programme already owns them.
Frequently asked questions
What is AI agent monitoring, and how is it different from normal SIEM monitoring?
It is not a separate system, it runs on the same SIEM. The difference is what you feed it and what you baseline against. A SIEM tuned for human accounts baselines working hours, login locations, and typical activity volume. An AI agent has none of those, it acts continuously, at machine speed, across tools and services a human account would never touch. Your SIEM can catch AI agent incidents, but only once it is ingesting machine identity, AI platform, and workload egress telemetry, and once its baselines are rebuilt around what normal agent behaviour looks like rather than human behaviour.
Do we need to worry about this if we only use AI for chat assistants, not autonomous agents?
Not to the same degree. A supervised chat assistant sits at the low-risk end of the scale: limited task scope, no standing privilege, no unsupervised runtime. Monitoring investment should scale with how much an AI deployment can do without a human in the loop, not with whether AI is in use at all. Restricting chat assistant use because of the incidents would be an over-broad response to a risk profile those tools do not carry.
What is the minimum telemetry to start with if we are monitoring AI agents for the first time?
Start with identity and credentials. Machine identity creation, API key and token issuance, and privileged role assignment were the decisive step in both July incidents, not the initial exploit. Agent behaviour, AI platform activity, and workload egress all matter, but identity is the layer to build first, because a credential is still the fastest way an agent’s reach turns into an attacker’s reach.
Would my SIEM have caught these incidents?
Only if it was already ingesting machine identity telemetry, AI platform logs, and session-level egress data, which most organisations do not currently do. The incidents were not stopped by a control in either case. Both were reconstructed afterwards from logs, and neither of the two organisations Anthropic was able to reach had detected the activity.
Is prompt injection detection enough to cover this risk?
No. Neither incident involved a jailbreak or a prompt injection. Both models pursued the objective they had been given, so a guardrail inspecting prompts would have shown nothing anomalous in either case. Prompt inspection is worth collecting as one input, but it should not be counted as monitoring coverage on its own.
How long should we retain AI agent logs?
Longer than your current identity and network platform defaults, which are often measured in days. Anthropic had to review evaluation runs going back to April to find the incidents it disclosed in July, a gap of several months between the earliest activity and the question that required answering it. Retention needs to be set by how long it takes an investigation to surface, not by a vendor’s default window.
About Theos Cyber
Theos Cyber helps organisations across APAC respond faster to cyber threats. From incident response and forensics to threat detection and offensive testing, our expert-led services are trusted by financial, tech, and critical infrastructure organisations to strengthen their resilience.
Theos Managed Threat Detection and Response pairs human-led threat detection with next-gen technology, including CrowdStrike and Microsoft, to give you faster visibility, deeper investigation, and real-world response. It ingests identity, agent behaviour, AI platform and workload egress telemetry into a single view, correlated and baselined so that agent activity does not drown a SOC tuned for human accounts. When an agent needs to be stopped, our response team can revoke credentials, terminate sessions and contain the workload directly.
Sources
- Hugging Face, security incident disclosure, 16 July 2026
- Hugging Face, companion technical timeline of the intrusion
- OpenAI, disclosure on the Hugging Face model evaluation incident, 21 July 2026, updated 28 and 29 July with advisor and model detail
- Anthropic, “Investigating three real-world incidents in our cybersecurity evaluations,” 30 July 2026, corrected 3 August 2026
