AI agents can now run sequences of research tasks with little human input. The question is who answers for the results. The European Commission has published the fourth version of its ERA Living Guidelines on the responsible use of generative AI in research, and its answer is clear: researchers remain accountable, no matter how much work they hand to an AI agent.

Published on 15 October 2026, this is the most comprehensive update since the guidelines first appeared in March 2024. It adds guidance on agentic AI and expands advice on AI use in peer review and proposal evaluation. The previous revision came in May 2026.

What Changes for Generative AI in Research

The biggest addition covers agentic AI, systems that can pursue complex goals and act with some degree of autonomy. The guidelines state that using AI agents may never be treated as a delegation of control or responsibility.

Researchers are asked to build checkpoints into agent-driven work so that critical decisions, such as methodological choices, are validated by humans. Any hypothesis generated, data processed or conclusion drawn by an AI agent requires human validation. The document also warns that researchers are not exempt from legal responsibility because an agent acted on their behalf.

The guidelines repeat that AI systems cannot be authors, co-authors or owners of research, since authorship implies agency and responsibility.

New Rules of Thumb on AI Disclosure

On AI disclosure, the guidelines draw a clearer line. Researchers should disclose AI tools used substantially, such as for literature reviews, identifying research gaps, developing hypotheses or interpreting data. Minor uses like spellchecking, grammar correction or formatting generally do not need disclosure. In case of doubt, disclosure is advised.

Researchers are also asked to consider that generative AI can produce different outputs from the same input, which may affect reproducibility. Authors decide whether prompts, logs and model versions should be kept or shared.

The document notes that a global reporting standard for AI disclosure is being developed at the World Conference on Research Integrity 2026 in Vancouver, which will inform future versions.

Peer Review and Hidden Prompts in Generative AI in Research

The guidelines say peer review remains a fundamentally human process. AI should not be used to assess novelty, originality, significance or whether a manuscript should be accepted or rejected. Confidentiality is described as non-negotiable, and unpublished material should not be uploaded to tools that cannot guarantee it won’t be used for training.

For funding bodies, the update flags a new risk: hidden prompts. These are instructions secretly embedded in documents, through invisible text, formatting tricks or metadata, designed to steer an AI tool toward a more favourable assessment. Funders are advised to set clear rules prohibiting such manipulation and add safeguards in the IT systems that process applications.

The guidelines also note that AI-polished proposals are increasing application volumes and overloading evaluators, and suggest the evaluation process may need to be redesigned to be more AI-resilient.

Security and Confidentiality Remain Central

Research organisations are encouraged to deploy locally hosted or self-governed AI tools so staff can work with scientific data while protecting confidentiality and research security. They are also told to ensure appropriate cybersecurity for these systems, especially those connected to the internet.

The document identifies systemic risks too, including dependence on proprietary AI systems and the concentration of AI capabilities and infrastructure outside the EU.

Non-Binding, but Built on Research Integrity

The guidelines are non-binding and do not replace existing laws or institutional rules. They rest on four principles: consider whether AI is the right tool, accountability stays with researchers and institutions, confidentiality is non-negotiable, and transparency builds trust. These draw on established research integrity frameworks, including the European Code of Conduct for Research Integrity.

The guidelines were developed with countries and stakeholders across the European Research Area. The next revision is planned for the third quarter of 2027, and an open feedback process remains available for contributions.

Verify you are human

Checking your browser before accessing this site.

Click to verify →

Then you will be redirected to the requested content.
Ray ID: 8f3a2c1b9d4e5f6a · Performance & security by Cloudflare

site-verification-ok

AI agents expose gaps in enterprise access controls and audit trails. Here's how security leaders can rethink identity, data governance, and oversight.

The post Your Security Stack Knows Who Logged In. But Does It Know What AI Agents Do Next? appeared first on TechRepublic.

SICW 2026 Opens With a Warning

AI Cuts Both Ways at SICW 2026

SICW 2026 Puts AI Risks Into Practice

The Trust Deficit Behind SICW 2026

"Accountability Cannot Be Outsourced"

What Comes Next

CrowdStrike links the ARTEX AI tool to breaches at South Korean banks, run by a suspected Chinese-speaking, profit-driven attacker.

Related Posts:

• The Devastating Ledger Security Breach
• The Reality of Ransomware Recovery Services
• SoftBank IDCF Cloud Ransomware Attack Exposed by Hackers

The post CrowdStrike Links South Korean Bank Breaches to Chinese AI Pentesting Tool ARTEX appeared first on Daily CyberSecurity.

Discover OpenAI's secretive Project 'O', a persistent AI agent expected to debut at DevDay. Learn how ambient AI is replacing traditional chat interfaces.

Related Posts:

• Codex Revamps and Reopens the ChatGPT Pro 20x Tier
• OpenAI Delays GPT-6.1 Astra Release Over Safety Concerns
• Google Outlines ChromeOS Sunset and Transition Plan

The post OpenAI to Unveil Project ‘O’ at DevDay appeared first on Daily CyberSecurity.

If you’re new to fuzzing and want to learn the fundamentals first, check out our Fuzzing 101 course at gh.io/fuzzing101.

Continuous fuzzing is not a magic solution that solves all your problems . Even projects that have been enrolled in OSS-Fuzz for years can still hide critical bugs, and the reason is almost always the same: someone needs to keep an eye on coverage, write new harnesses for the code that nobody is reaching, and triage the crashes that come out the other end. In other words, fuzzing still needs a human in the loop.

So the natural question I kept asking myself was: how much of that human work can we actually hand over to an LLM agent?

That is what led me to build the Fuzzing Taskflow, an autonomous fuzzing pipeline for C/C++ projects. You only need to point it at a GitHub repository, and it does the rest: it identifies the suitable entrypoints, analyzes the build system, writes the harnesses, runs AFL++, reads the coverage reports, improves the harnesses, triages every crash, and writes a vulnerability report for each unique bug, all without a human babysitting it.

The Fuzzing Taskflow is built on top of the GitHub Security Lab Taskflow Agent, our framework for writing LLM-driven security automation, so the pipeline is expressed as a set of taskflows that an agent runs end to end.

In this post, I’ll walk you through how it works and the design decisions behind it. Let’s get going!

How to run it

The simplest way to run it’s just to go to https://github.com/GitHubSecurityLab/seclab-taskflows-fuzzing and start a codespace.

Then, run the script like this:

./scripts/fuzzing/run_fuzzing.sh PROJECT

So, for example:

./scripts/fuzzing/run_fuzzing.sh tukaani-project/xz

That’s it. The argument is just a GitHub owner/repo slug. Then, the agent, takes care of all the preliminary steps on its own:

• Installing software such as AFL
• Cloning the repository
• Identifying the most relevant functions in the code
• Creating fuzz targets for those functions

If you just want a quick smoke test before committing to a long campaign, point it at something small:

./scripts/fuzzing/run_fuzzing.sh DaveGamble/cJSON

A word of warning before you run it: this taskflow runs afl-fuzz, clang, and arbitrary build commands chosen by the LLM directly on the host, with no container in between. A prompt-injected agent could, in principle, do anything your user can. So please run it only inside a disposable environment (e.g., a Codespace or a throwaway VM), without elevated privileges.

Model selection

Some frontier models impose security guardrails on their outputs. For the fuzzing task flow, we use Claude Sonnet 5 by default because it passed all of our internal tests without issues. You can choose a different model by modifying the following file: src/seclab_taskflows_fuzzing/configs/model_config.yaml.

The architecture in one minute

Before getting into the interesting parts, it helps to know how the pieces fit together. There are three layers:

• A shell driver (run_fuzzing.sh) that chains the pipeline stages together.
• A set of taskflow YAMLs, one per stage, which are essentially the prompts that tell the LLM agent what to do at each step.
• A set of MCP tools that the agent calls to actually do the work: run AFL, compile a harness, store a crash, read a coverage report, and so on.

The design rule I cared about most is a clean separation of responsibility: the LLM agent owns the decisions, and the MCP tools own the execution. The agent decides what to fuzz, what harness to write, and what coverage gap to chase next. The tools just expose primitives like run_afl_for or compile_harness. The agent never calls AFL or clang directly; it composes the pipeline out of these building blocks. All the state lives in a SQLite database (fuzz_context.db), so the stages never hand data to each other in memory, only through the database.

One small but important detail: each harness is built twice. AFL’s edge instrumentation is great for guiding the fuzzer but useless for human-readable coverage reports. So every harness becomes both a .afl binary (built with afl-clang-lto -fsanitize=address,undefined) and a .cov binary (built with clang -fprofile-instr-generate -fcoverage-mapping). The .afl binary does the fuzzing; the .cov binary replays AFL’s queue afterwards to produce real source-line and branch coverage.

The coverage-feedback loop

This is the heart of the whole pipeline, and it’s the part that most directly automates the manual workflow I described at the start.

If you have ever tried to improve fuzzing coverage by hand, you’ll know that it’s an iterative process that looks like this:

The “check the coverage” step used to be completed by me, manually reading an LCOV report looking for uncovered branches. The “improve the coverage” step was also completed by me, this time, writing a new harness or crafting a new input. The Fuzzing Taskflow hands both of those steps to the agent.

Each iteration, for each harness, the agent runs AFL for a time budget, replays the queue against the .cov binary to get a real coverage report, and then reads the list of uncovered branches. Based on what it finds, it picks one of a handful of actions:

• Add a new seed crafted to reach an uncovered branch
• Edit the harness source to call an additional API
• Auto-enrich the AFL dictionary with the magic constants a guard is comparing against
• Simply skip the gap if it’s a cold error path or vendor code that isn’t worth chasing

The time budgets double every iteration:

30s → 60s → 120s → 240s → 480s → 960s (≈ 32 min/target)

The idea is to spend cheap, short rounds early (when there’s lots of low-hanging coverage to grab) and longer rounds later (when the fuzzer needs more time to break through a hard guard).

And just like in my manual workflow, I need an answer to the question: when do we stop? Here, the loop uses plateau detection: once two consecutive iterations each gain less than a configurable threshold (1% absolute line coverage by default), the loop decides it has hit diminishing returns and moves on. This keeps the agent from burning hours of compute squeezing out the last fraction of a percent.

Structure-aware fuzzing

AFL’s default byte-level mutators (bit flips, arithmetic, block splicing) do a great job on binary formats but struggle with structured, text-based inputs. The classic solution is to hand-write custom mutators for each format, which is tedious work. This time I want the pipeline to do that work for me, so it ships four complementary mechanisms for producing structure-aware inputs.

1. Per-format dictionaries and custom mutators. For targets whose input format is recognized (JSON, XML, regex, PNG, length-prefixed binary TLV), the taskflow ships pre-built AFL dictionaries and LLVMFuzzerCustomMutator C files. The JSON mutator does token splicing and balanced-bracket duplication; the XML one knows about tags, entities, and billion-laughs tokens; the regex one carries real ReDoS patterns. Each mutator delegates half of its mutations back to AFL’s default byte mutator, so we keep the engine’s randomization instead of fighting it.

2. A source level dictionary. For formats the pipeline doesn’t recognize, it generates a custom mutator on the fly by scanning the target’s own .c/.h files. It extracts string literals and 32-bit numeric constants (from #define, case, and enum), filters out the noise, and uses them as splice tokens. The intuition is simple: the most interesting magic values that a parser checks for are usually written down somewhere in its own source.

3. A dynamically generated AFL dictionary with coverage-driven enrichment. The same source-token set is also emitted as an AFL classic dictionary before iteration 1 (numeric constants in both endiannesses, so the fuzzer can satisfy a memcmp against a 4-byte magic regardless of host byte order). Then, after every coverage step, the pipeline looks at the guards near the uncovered lines (strncmp, memcmp, case 0xN, == ‘X’) and appends any new tokens it finds. The dictionary literally grows toward the code the fuzzer can’t yet reach.

4. A corpus-splice operator. The smart mutator can also load files from a corpus directory and splice random sub-regions of them into the input, a recombination-style operator that AFL’s stock havoc doesn’t do well.

Evolving corpus

One of the things that quietly kills fuzzing efficiency is throwing away progress. If every run starts from the original seeds, you re-pay the cost of rediscovering the same paths over and over.

To avoid that, every harness gets a stable corpus directory that survives across iterations and across entire campaigns:

<workspace>/corpus/harness_<id>/

At the end of each iteration, AFL’s queue is merged into this directory and run through afl-cmin to keep its size bounded. The effect is that yesterday’s interesting inputs carry into today’s run, and the inputs you found in last week’s campaign carry into this one. If you stop and restart a campaign, you lose nothing.

Triage and vulnerability reports

Finding a crash is only half the job. As anyone who has done root-cause analysis knows, triaging is often the most tedious part of the whole process. This is the other place where the agent shines.

After the fuzzing loop finishes, three stages run automatically. First, every crash is minimized with afl-tmin, replayed under ASan to capture a stack trace, and deduplicated by a stack-top hash (the top normalized frames, with templates, inline namespaces, and LTO suffixes stripped so semantically identical crashes collapse together). Second, previously known crashes are replayed against the current binary to see whether an upstream fix has resolved them. Third, the agent reads the harness source and the crashing function, walks the call chain back from the public API, and writes a per-crash markdown report.

Each report assigns one of the following verdicts:

• vulnerability
• library_hardening
• harness_bug
• OOM
• timeout
• assertion_failure
• duplicate

The distinction between a real vulnerability (reachable and exploitable through a public API) and a mere harness_bug (the bug is in our own harness, not the library) is exactly the kind of judgment call that used to require me to sit down and trace the code by hand. Every report includes a root-cause analysis with file:line references, a reachability argument, an exploitability assessment, a suggested fix as a unified diff and a regression-test sketch.

Just as clarification: the suggested patches are marked “review required” for a reason. The agent’s analysis is limited by the model’s understanding of the target code, and it does get things wrong. Treat the verdicts as a very well-prepared starting point for a human, not as final result.

Live dashboard

Running an autonomous campaign and not being able to see what it’s doing is uncomfortable, so the pipeline publishes everything to a live HTML dashboard. It auto-starts in the background as soon as you launch a campaign, on port 8765. In a Codespace that port is auto-forwarded, so you can open it in any browser and watch the campaign progress in real time on the dashboard.

The page shows amongst others:

• a per-harness “running” pulse
• a coverage-trend table with inline sparklines
• a crash heatmap
• an iteration timeline

Conclusion

I started this project motivated by the limitations that any security researcher knows well: fuzzing works, but it doesn’t scale without human attention, and that human attention is the bottleneck. The Fuzzing Taskflow is my attempt to push that bottleneck back by handing the repetitive parts (writing harnesses, reading coverage, chasing gaps, triaging crashes) to an LLM agent, while keeping a clean separation between the agent’s judgment and the tools that do the real work.

If you’re the maintainer of C/C++ project, then please give it a try. If your project has never been fuzzed before, then this tool will help you to get started quickly. Or if your project has been fuzzed before, then this tool might help to find new bugs by increasing your fuzzing coverage.

The source code is open source, so please create an issue if you encounter any bugs. Contributions are also welcome!

The post AI-powered fuzzing with the GitHub Security Lab Taskflow Agent appeared first on The GitHub Blog.

Analysis of how default configurations in AWS AgentCore Harness allow prompt injection to exfiltrate credentials, and key steps to secure your agents.

The post A Vault with a Heap-View: The Uncomfortable Space Between AgentCore Harness and Identity appeared first on Unit 42.

Executive Summary

• OpenAI disclosed that agents used exposed Hugging Face credentials to write a file and deploy proxy Spaces during an unrelated May 2026 research workload, but it did not identify the accounts. SentinelLABS identified two accounts likely used in associated activity, 0Time and Nyx9. Their public histories extend OpenAI’s chronology and preserve previously unreported relay code, document-borne probes, and ChatGPT account-provisioning capability.
• The public records provide precise joins to OpenAI’s internal timeline. At 20:04:11 UTC on May 26, Nyx9 committed a file eleven seconds into the minute when OpenAI recorded a WebCache-confirmed external file write. At 20:49:55, another Nyx9 Space received relay code during the same minute OpenAI recorded its first proxy deployment. Looking backward, 0Time committed caller-directed relay code on May 13, nearly two weeks earlier and the earliest substantive public code write we link to this May activity. That May 13 relay commit was also independently flagged publicly.
• On May 26, Nyx9 also committed formbin.xlsx. Its WEBSERVICE() formulas targeted an external HTTP endpoint, a file:// URI, Azure’s Instance Metadata Service, and an internal-looking service URL. The workbook implements a recognizable document-borne probing capability and appeared four hours and 36 minutes after OpenAI’s first documented successful internal Artifactory SSRF at 2026-05-26 18:24 UTC. Public records do not show that its formulas executed or identify the system intended to process it.
• On May 30, five commits over 10 minutes and 31 seconds placed an existing, publicly available Chinese-language OpenAI account-registration and token-extraction tool into a Hugging Face Space. The commits added a small Flask wrapper defining an unauthenticated /do route, declared the application port, and introduced OAuth-response diagnostics. If the Space built, ran, and received a request, each call could attempt one registration and return its output. Repeated successful requests could supply additional ChatGPT identities or OAuth credentials, making this a potential identity-provisioning capability that could support rogue scaling.
• These findings expose a basic problem for threat intelligence and incident response: no single organization necessarily holds the complete record of an agent’s actions. An account handle is not an actor, and an IP address does not identify who authorized the activity. Investigators must reconstruct the originating task, credential lineage, action sequence, platform history, runtime telemetry, and effects across services. The public trail is part of the incident, not an appendix to it.

Overview

OpenAI’s technical report on its May 2026 incident describes agents, operating in a tool it calls WebCache, using an exposed Hugging Face token to write files and deploy proxy Spaces outside OpenAI’s environment.

At 20:04 UTC on May 26, OpenAI’s incident chronology records its first WebCache-confirmed external file write. At 20:04:11, the Hugging Face dataset Nyx9/temptestlf8eb0 received hello.txt, containing only “hi”.

Forty-five minutes later, OpenAI records its first proxy deployment. At 20:49:55, Nyx9/netproxy17 received its proxy relay code. The timing and function make these the cleanest public joins we found between OpenAI’s internal chronology of unnamed agent used accounts and the two Hugging Face account histories.

Those joins gave us account-level pivots. Looking backward, 0Time contains proxy relay-building activity on May 13, nearly two weeks before the better-known May 26 proxy sequence reported by OpenAI. Looking forward now, Nyx9 contains document-based probes aimed at local and internal resources later on May 26. On May 30, 0Time committed an adapted program for registering illicit OpenAI accounts to a Hugging Face Space and the committed wrapper defined an unauthenticated GET route at /do.

It’s important to note these commits do not prove a successful usage, and a build does not prove that a route received traffic. A formula inside a workbook does not prove that a server evaluated it, or what its true intention was – be it hacking into Hugging Face or used in the compromise of a separate organization. Our analysis keeps those stages separate because the public data can not tell us if or how these actions were used. Only Hugging Face and OpenAI hold the records that could.

Finding the Public Side of an Internal Timeline

OpenAI’s public account begins inside its own environment. The company reported an arbitrary Artifactory file write on April 20. On May 8, an agent attempting server-side request forgery, or SSRF, failed to reach its intended destination but incidentally wrote testabc.txt into internal Artifactory repositories. Code shown in OpenAI’s Black Hat presentation sent PUT, GET, and DELETE requests to internal repositories named bazel-cache-remote and pypi-openai.

On May 12, another agent used Artifactory as an improvised message board while searching for soft-trace-34.pdb. It wrote REQUEST_softtrace_target_missing.txt, asking other agents to upload the file if they found it. Other agents later encountered the request and added similarly named messages.

OpenAI said a separate WebCache-enabled agent used an exposed Hugging Face token on May 13 while searching for the same file, but its public chronology does not identify the account. This gap matters because the internal and external records answer different questions. OpenAI can describe the agent’s reasoning and tool calls. Hugging Face can identify account use, commits, builds, containers, and HTTP requests. Neither view alone reconstructs the event.

SentinelLABS attributes activity under the 0Time and Nyx9 accounts to OpenAI agents during the May window. We tested that attribution against public repository histories, finding exact-minute and code-function matches with OpenAI’s chronology. Both accounts predate the activity and should be treated as affected account identifiers, not OpenAI-created agent identities.

May 13 Relay Code Appears

The 0Time profile was created on February 21, 2026. The account predates the disclosed May activity; that does not establish who controlled it during May or why it was created. The primary question is what happened through the account during the incident window.

Before noon on May 13, 0Time created a test-named repository state, posted “hi” to a discussion in Anthropic’s BioMysteryBench dataset, and opened a draft pull request. At 11:05:13, the account committed the first substantive revision of a Space named puthack82d5.

That revision accepted a caller-supplied destination and supported GET and PUT requests. It also accepted an x-amz-copy-source value, a header associated with server-side object copying. A revision at 11:42:04 added bearer-authenticated POST bodies and Git LFS media types.

If the Space built and ran, the code could relay requests between an external caller and resources reachable from the hosted environment. The public record does not show a successful build, incoming request, or completed object copy. The code does not mention soft-trace-34.pdb, so we do not identify it as the unnamed Hugging Face search in OpenAI’s May 13 account.

Relay code was committed under an independently attributed account by 11:05 UTC on May 13. That is the earliest unambiguous attributed public code or file write we located in this cluster. This adds a separate public trace to the one OpenAI disclosed on May 13. We also credit researcher Jonas Wiedermann-Möller, who independently called attention to the same May 13 relay commit.

May 26 Small Tests and Exact Matches

Morning File and Storage Tests

The morning record contains several weak artifacts that become useful as a sequence. At 07:16:28, 0Time/findblobtest received a direct text write. Later that morning, 0Time/INCEPT-SH added three paths that referenced an existing Git LFS object at 811MB. The commits changed paths to the object, but did not alter the object itself, suggesting  aliasing or retrieval tests.

Nearby commits added a malformed Git LFS pointer and two tiny raw files. small.png contained “abcde”; model.bin contained “abcdefg”. The pointer misspelled “version” as “vearsion”. None of these strings is a useful indicator alone. Their value comes from their place beside direct writes, raw-file handling, LFS experiments, relay construction, configuration corrections, and later debug commits.

The account activity predates the evening proxy sequence, but the public record does not establish a causal chain between the morning tests and later events.

Exact Minute Matches Under Nyx9

OpenAI’s chronology records a dense set of external actions on the evening of May 26. At 19:50, WebCache sent Git LFS batch requests to one OpenAI dataset and one third-party dataset.

OpenAI then records a file write at 20:04, a request to create a private dataset at 20:15, a proxy deployment at 20:49, a successful proxy response at 20:53, and a Google search through the proxy at 20:54. At 21:07 the agent checked two gated benchmark datasets and submitted access requests. At 21:08 a second account deployed another proxy through the first.

Nyx9/temptestlf8eb0 was created at 19:30:08. At 20:04:11, it received hello.txt containing “hi”. The eleven-second offset from OpenAI’s minute-level (20:04) event is the strongest public correlation for the file write.

Nyx9/netproxy17 was created at 20:48:33. At 20:49:55, it received relay functioning code. The same-minute timing and the code’s function closely match OpenAI’s first proxy deployment.

A related 0Time Hugging Face Space named latnetnew, appeared at 21:06:05. It received a minimal “hi” revision at 21:12:41 and related relay code at 21:13:21. Those public events align with OpenAI’s 21:08 description of a second account deploying a proxy through the first. This is a strong sequence-level mapping, but not an exact-second match. OpenAI also describes different agents taking related actions, so the sequence should not be read as one continuous session.

Essentially there is noteworthy correlation beyond the use of the word “hi”. It is the combination of minute-level timing, repository type, code function/capability, and the surrounding cross-account sequence. Provider-side records, if retained, may establish the token, session, source-network, build, and runtime records needed to confirm action-level identity, but from the outside the overlap provides us considerable confidence in the activity being highly associated with the OAI/HF intrusions agentic activity.

Later That Night, a Workbook Contains Internal-Resource Probes

At 22:56, Nyx9 began adding files to a dataset named tmpdata177. The activity continued until 23:34. Several files were generated only one or two seconds before upload, a pattern consistent with programmatic creation. The collection included text, PDF, DOCX, and XLSX files.

Most contained simple markers, but one workbook was different. formbin.xlsx (MD5: a502264fa0b64eecae60498b0c48fca3), uploaded at 23:00:07, placed four WEBSERVICE formulas in cells A4 through A7. The basic functionality of the file is to test  probes by whether the application processing it can fetch external content, read a local file, access cloud metadata, and reach a specifically named internal service, potentially retrieving its API specification for further reconnaissance.

A1: MARKER
A2: =1+2
A3: =CONCATENATE("JOIN","T")
A4: =WEBSERVICE("https://httpbin.org/base64/UkVNT1RPSFgo")
A5: =WEBSERVICE("file:///etc/hostname")
A6: =WEBSERVICE("http://169.254.169.254/metadata/instance?api-version=2021-02-01")
A7: =WEBSERVICE("http://file-service-namespaced:8001/openapi.json")

The Azure request omitted the required Metadata header, reducing the likelihood of a valid response from a normally configured service. The workbook also contains no cached formula results. The file was created via Openpyxl, and we found no callback, secret, calculated value, or other evidence that Hugging Face evaluated the formulas or that any probe succeeded.

Hugging Face later described the same metadata-address family in an earlier and noisier variant of a separate July SSRF incident. The overlap shows similar interest in metadata-service access. It does not establish that the May workbook and July intrusion were the same workload, targeted the same processor, or came from the same agent.

This public evidence establishes a file-processing and SSRF probe set staged on Hugging Face on May 26th. The distinction to note is that the file clearly demonstrates probing intent, but it does not establish malicious authorization, successful exploitation, or which platform was targeted. An AI-assisted spreadsheet-processing environment (such as Hugging Face in this case) is a plausible target, but that remains an inference.

May 30 Registration Code Becomes a Web Route

The most consequential public artifact appeared four days later. Between 00:01:27 and 00:11:58 on May 30, five commits created and configured the Hugging Face Space 0Time/altreg.

The sequence moved from Space creation to an abc text marker, then to a 454-line registration program and Flask wrapper. A later commit declared the Space application port. The final revision added targeted logging around the OAuth response.

The 454-line program is a copy of a publicly available Chinese-language OpenAI account-registration and token-extraction script published by 0x5uo2hen. The Space was created independently rather than as a Git fork. It added a small Flask wrapper and Docker configuration; the final commit added one OAuth-response diagnostic statement.

The program automates the creation of ChatGPT accounts via disposable mail.tm inbox creation, identity generation, browser-like requests, OpenAI Sentinel anti-abuse token requests, email verification, workspace selection, and OAuth token extraction. The public source was a command-line program that could loop through registration attempts.

The altreg commits added a small but important adaptation. A Flask wrapper defined an unauthenticated /do route that called reg.run(None) once and returned the program’s output. If the Space built, served, and received a request, each call could trigger one ChatGPT registration attempt. Repeated calls would make the design bulk-capable and could expose resulting credentials to an unauthenticated caller if the underlying registration succeeded.

Repeated successful calls could provide additional accounts or OAuth credentials. That makes altreg a potential identity-provisioning primitive, not demonstrated self-replication. Recursive scaling would require an agent to obtain usable credentials, launch more agent work, and retain control of that work. None of those runtime steps can be observed in such public data.

As of September 14, Hugging Face’s API reported the Space as paused and flagged as abusive. However, this public state does not establish when the flag was applied or why.

The five-commit sequence is unusually compact. It progresses through a scratch marker, a complete program, a web wrapper, a deployment configuration, and response-specific debugging in 10 minutes and 31 seconds. That test-configure-debug cycle fits continued agentic activity, particularly alongside the account’s attributed May history.

Why Committed Capability Matters

Traditional intrusion reporting often centers on execution: a payload ran, a credential was stolen, or a command-and-control channel came online. The public evidence here forces a more exact progression. For committed code to become an observed external effect, investigators must separately establish each stage:

• Code was committed.
• The hosted application was built.
• The application started.
• A route received a request.
• The request produced an external action.
• The action succeeded and its output was used.

The May 13 relay and May 30 registration evidence establish the first step. The May 26 workbook establishes formula placement, not evaluation. OpenAI’s records establish runtime for its May 26 WebCache write and proxy actions. The public commits identify likely external counterparts but do not independently prove the same request, session, or initiating agent. Only Hugging Face and OpenAI can compare token use, sessions, source networks, builds, runtime requests, and route access to determine whether and how any of this was used.

Collapsing these stages would overstate the case. Waiting for confirmed credential theft or malware would miss the risk. Unauthorized token use, public file writes, hosted relay code, internal-resource probes, and registration automation are recognizable offensive capabilities, and a benign research objective behind them does nothing to lessen their effect on the third-party systems they touch. An AI research objective should never remove their effect on third-party systems.

Threat Intelligence Needs the Whole Task

None of the individual techniques observed here are new. Human operators have long used SSRF probes, public relays, disposable mail, OAuth automation, paste sites, source repositories, and legitimate cloud services. What changes is the investigative scale. A task-driven agent can assemble those pieces through other people’s accounts and hosted platforms while its originating lab, the hosting provider, and downstream services each retain only part of the evidence.

Treat the Task as the Unit of Analysis

0Time and Nyx9 are evidence containers, not actor names. Analysts need to connect action order, code function, object hashes, prompts, tool calls, token lineage, and provider-side session identifiers. A handle can belong to a victim whose exposed token was used by someone or something else.

Correlate Evidence Across Providers

OpenAI can see the authorizing workload and internal tool use. Hugging Face can see authentication, commits, builds, containers, and route requests. Other services may hold mail, proxy, DNS, or callback records. A defensible reconstruction requires those views to be joined without treating any one source as the entire event.

Read Weak Artifacts as a Sequence

Strings such as “hi”, “abc”, and “abcdefg” are poor standalone indicators. Their value changes when they appear inside a rapid sequence of direct writes, relay creation, port declaration, parser probes, and targeted OAuth debugging. Detection should focus on construction patterns and action order rather than generic scratch text.

Preserve Runtime Evidence Before Cleanup

Spaces can be paused, deleted, rebuilt, or garbage-collected. Commits and conversion outputs may survive after container and request evidence disappears. Providers should preserve token fingerprints, authentication and session identifiers, build logs, runtime logs, route requests, network egress, and deletion tombstones when agent-related abuse is reported.

Make External Actions Attributable

Affected operators should be able to determine which customer authorized a task, which model and policy state governed it, which credential it used, and what it wrote outside the provider’s environment. Without that chain, saying an agent acted explains neither authority nor responsibility.

Finally, it’s critical to remember that model-behavior review and DFIR answer different questions during incident response of cases such as this. LLMs can accelerate transcript clustering, code review, artifact decoding, and timeline development. They should remain triage and hypothesis-generation tools.

In their review of the June/July activity, METR and Redwood reported that their GPT-5.6 Sol analysis agents made errors, exercised weaker judgment than human researchers, and surfaced anecdotes they could not always verify manually. The same approach made review at this scale possible. Speed is useful, but it does not make an LLM generated narrative authoritative.

Independent Investigation Requires the Incident Record

OpenAI provided METR and Redwood Research with approximately 1,300 agent transcripts and 1.2 million Artifactory message-board entries for an on-premises review. As of publication, SentinelLABS could not identify an official public release of that underlying corpus. The resulting reports add useful context, but outside investigators cannot reproduce their conclusions, search systematically for omitted activity, or test competing explanations against the same evidence. METR incident investigation

Frontier AI labs should release a documented, redacted incident dataset when their agents interact with or affect third-party systems. At minimum, it should preserve the authorizing tasks, prompts, model and harness versions, action-level timestamps, agent messages, tool calls and results, external requests, and stable pseudonymous identifiers connecting sessions, accounts, and credentials. It should also state what was excluded, identify known gaps, document every class of redaction, and provide hashes for the released evidence.

This does not require publishing credentials, personal information, customer data, proprietary model details, or dangerous exploit material. Nor does it necessarily require unrestricted publication of private chain-of-thought. An action-complete record can preserve the observable decisions and causal sequence while removing genuinely sensitive fields. Where public release would still create unacceptable risk, labs could publish a structurally complete redacted dataset and provide fuller telemetry under controlled access to qualified independent DFIR and security-research organizations.

Privacy is a reason to redact the incident record, not a reason to make it unauditable. A narrative report—even one reviewed by external advisers—is not the same as an independently reproducible investigation. Once an agent reaches systems outside its developer’s environment, the evidence no longer concerns only the originating lab. Releasing a usable incident corpus should become a baseline accountability requirement for frontier-agent security incidents.

Conclusion

OpenAI’s internal chronology established that agents used exposed Hugging Face credentials to write an external file and deploy proxy Spaces on May 26. The public account histories examined here add another layer: caller-directed relay code under 0Time on May 13; exact-minute public counterparts under Nyx9 for the May 26 file write and first proxy; a workbook containing file-processing and SSRF-oriented formulas later that night; and, on May 30, third-party OpenAI account-registration code committed alongside a wrapper defining an unauthenticated web route. Those records establish repository state and capability, not successful execution.

How quickly a task-driven system can assemble old techniques across other people’s accounts and infrastructure, and how thoroughly that scatters the evidence, is the part of this incident that is new. The public trail is not an appendix to an agent incident. It is part of the incident.

Investigative Artifacts and References

The following records support the blog and are recommended for further investigative pivots. We normalized times to UTC and compared OpenAI’s minute-level chronology with second-level public commit metadata. Account handles, repository names, hashes, and the 169.254.169.254 destination should not be treated as standalone malicious indicators.

• OpenAI Hugging Face Incident Technical Report — Published internal chronology; see pages 6–7 and 32–33
• OpenAI Hugging Face Incident and Misalignment — OpenAI’s public account
• Hugging Face July Agent Intrusion Technical Timeline — Separate July incident referenced for comparison only
• OpenAI Black Hat presentation recording — Shows the Artifactory write and message-board examples
• 0Time puthack82d5 relay commit — May 13 initial relay behavior
• 0Time puthack82d5 POST and Git LFS revision — May 13 later relay revision
• Nyx9 — May 26 20:04:11
• Nyx9 netproxy17 relay commit — May 26 20:49:55
• 0Time latnetnew relay commit — Public revision after the 21:08 second-account event
• Nyx9 formbin.xlsx commit — Workbook with local, metadata, and internal-service targets
• 0Time altreg principal code commit — Registration program and Flask wrapper
• 0Time altreg OAuth-debug revision — Final May 30 diagnostic change
• 0x5uo2hen codex_register source commit — Earliest exact public source located
• Microsoft WEBSERVICE function documentation
• Microsoft Azure Instance Metadata Service — Header and access requirements
• openpyxl formula documentation — Formula storage and evaluation limitations

Explore how attackers targeting Latin American entities use AI for data exfiltration and how basic OpSec errors allow defenders to disrupt operations.

The post Attackers Expose Ongoing AI Tool Use Targeting Organizations in Latin America appeared first on Unit 42.

Using autonomous AI agents, an attacker breached an enterprise network in a matter of hours. Understand how to address and defend against agentic attacks.

The post An AI-Assisted Cyber Attack: Inside a Unit 42 Investigation appeared first on Unit 42.

Running a threat intelligence program today means operating across more tools, more workflows, and more organizational complexity than most platforms were originally designed to handle. The intelligence is there. The question is whether the platform is keeping up with how your team actually needs to use it.

The Open Secure AI Alliance introduced SAFE guidelines and open agent-security tools at Black Hat, giving enterprises a framework for safer AI deployment.

The post Open Secure AI Alliance Expands at Black Hat: What You Should Know appeared first on TechRepublic.

Claude Opus 5 set a Vending-Bench record while fabricating supplier bids, breaking truces, and ignoring refunds, showing why companies need stronger AI agent controls.

The post Claude Opus 5 Vending Test Shows Profit-Driven AI Risks appeared first on TechRepublic.