DEW #166 - Figma's Agentic SecOps, AI-EDRs and Anthropic Evals Breaking into Companies
Hacker Summer Camp during a heat wave in a desert is certainly a choice
Welcome to Issue #166 of Detection Engineering Weekly!
✍️ Musings from the life of Zack:
I’m on Day 2 of Hacker Summer Camp today! Yesterday was jam-packed with two great events. I helped lead a session on SIEM and Security Operations at Decibel’s Game Day, and we had a GREAT turnout at the Detection & Response Happy Hour. Almost 300 people signed up, and it was so great to meet people who read the newsletter and came to support!
I’ll be walking the floor today and hitting up Olivia Gallucci’s talk on macOS Detection Engineering and an Agentic Detection session by two security engineers at Roblox
My hotel lost my tshirt and stickers box. The FedEx in the hotel said the mail room has it, and the mail room swears that FedEx has it. So that’s gonna be a fun part of my morning :|
Sponsor: Material Security
Catching the phish was never the whole job.
Phishing's share of breaches hasn't moved in years, because that war’s been fought to a draw. Stolen sessions, dormant OAuth grants, and AI agents with more access than anyone tracks increasingly get attackers in instead. The perimeter held. The workspace didn't. See what detection looks like when it follows the attacker past the inbox.
💎 Detection Engineering Gem 💎
How we secure Figma’s internal systems with agents by Matthew Sullivan and Brad Girardeau
Memory ended up being the thing that had the most impact on how useful the system became over time. We have several kinds, and keeping them separate turned out to be important.
What I love about reading modern security research in the blue team space is that as a community, we are applying more software engineering principles to security problems. This is why I love reading pieces like this, because it’s not just about agent design, but agent design for security operations AND it’s being used in the wild. The real contribution is not “agents for triage” in the abstract. It’s the claim that a security team’s value is in its expertise being recorded and reused instead of disappearing after an analyst makes a triage decision.
In this post, Sullivan and Girardeau reveal how Figma’s detection & response team built their own security alert triage orchestration system with a clever twist: encoding its efficacy and agent memories. Here’s how it works:
For every alert triaged, they use a Retrieval Augmented Generation (RAG) to store analyst decisions, detection and alert metadata, investigative steps and memories for subsequent investigations
When a subsequent alert is generated, their triage system queries the RAG database to search for similar alerts and uses that as context for the current investigation
The agent posts a summary inside the Slack thread where the alert was used to page the on-call engineer, so when the engineer begins investigating, they have deeper context on how this was investigated before
Once the engineer closes the alert, they update the Slack thread, which is then stored into the RAG system to create a closed loop
The team spent a lot of time describing their memory architecture and how it was the single best investment they’ve made to increase detection efficacy and reduce toil. Agent memory in this context is separated into three buckets: steering, procedural,, and case. Case memory is what you see in the picture above. Steering memory ensures an agent stays on track during an investigation, so it helps encode the agent's behavior during these steps. Lastly, procedural memory is the tribal knowledge that they store into agents as they navigate nuanced (see: janky) systems to make sure they know how to work with sharp edges.
I like to think about this type of setup as a “context pack”. LLMs thrive in context; it’s literally why they have a context window. Context engineering is a concept where you can inject instructions and knowledge into the context window to create consistency between agent runs. Figma’s three memory types, or context packs, ensure this consistency holds across the investigative, system, and behavioral steps of their alert triage.
The other thing to call out here is their confidence in letting agents create and tune detection rules. The memory each agent holds within each run helps steer the detection ruleset into a much more accurate state, but they do a good job of applying security boundaries so an agent is stopped right at the pull request, or when it tries to read Slack history or messages in channels that it isn’t explicitly allowed to read.
🔬 State of the Art
Securing Agents Across Perplexity’s Client Endpoints with Numbat by Perplexity
Coding agents are purposefully built to be non-deterministic. This non-determinism is what makes them fantastic at what they do. Personally, I have an agent for building and maintaining my home lab environment, a harness built for vulnerability research of malware and phishing panels and my agents at work that can orient themselves to codebases so I can get into a devloop for a service in a few minutes.
This non-determinism is what makes them dangerous, whether the intent was malicious or not. Last week, I linked to OpenAI & Hugging Face’s post-mortem on an unreleased OAI model breaching Hugging Face’s infrastructure. You’ll see in the threat landscape section below a similar announcement from Anthropic where it did nearly the same thing. I think the best way to secure your company against coding agents is not to assume whether they are malicious or not, but rather that they are untrusted.
Perplexity addressed this problem by releasing an open-source tool, dubbed Numbat, which is essentially an EDR plugin for coding agents. Coding agents expose rich functionality for hooking into their agents (Anthropic, OpenAI). These features are great for observability tracking but also double as a boon for security teams that try to track unsafe behavior for these agents. It integrates directly with over 10 coding agent harnesses and provides three security functions:
Lifecycle hooks, which emit telemetry from events like tool use or filesystem usage on coding agents, which is useful for logging activity or blocking
OTLP telemetry, which exposes an OpenTelemetry server that agents can submit logs and metrics to so it can be sent to a SIEM or logging platform
Session artifacts, which help with forensics when an agent goes rogue, and you want to see how its context window led it astray (think of looking at raw prompt and response text)
The coolest part of this blog, though, is the rule language. Perplexity shipped an on-agent CEL integration, which is commonly used by Kubernetes operators to evaluate K8s control plane traffic, as their answer for logging and blocking. It reminds me of eBPF rules, where the agent emits an event, and the CEL connector reads incoming JSON and tries to match it against a rule to detect maliciousness. It has 52 (!) built-in rules located here, and it even supports correlated rule chains (check out this gnarly one for turning off agent guardrails, then the agent trying to egress data).
This week’s issue is certainly AI-security pilled. As we’ve seen from the Hugging Face/OpenAI & Anthropic disclosures, agent security is starting to decouple malicious intent from an agent’s execution. It’s not that intent matters; it’s more that our traditional models assume an attack inside your environments is likely the result of a malicious actor, and that doesn’t matter anymore. Attackers and agents both have goals; the difference is we allow agents to work inside our walled gardens.
My diatribe above is even harder to decompose when you have security companies shoving marketing down your throat. That’s why when I read this post from James, I was happy to see a practitioner’s approach to how the market can help against attacks like this. There are very few security market analysts I read and link in this newsletter, and James is at the top of my list.
James splits the Hugging Face/OpenAI attack into an ATT&CK-like chain, and helps readers understand what security product space could have helped detect or stop the attack along the way. He also presents these spaces as matter-of-fact: you don’t have to buy any of the products; instead, he frames it so that if you need to solve this issue, you can use those spaces as inspiration for your build-vs-buy decision. Honestly, this is the first analyst report I’ve read in a long time where I’d be happy to send this to my CSO :).
(by the way, if you haven’t subscribed to his Substack, please go do so!)
Deep-diving Crowdstrike’s DirectoryCreate by Daniel Koifman
EDR research posts like this tend to make my weekly reading because they help shed light on a very opaque product suite. In this post, Koifman aggregated CrowdStrike’s hundreds of logged event types and focused on a singular event: DirectoryCreate. What I love about this research is how focused it is. A seemingly tidy event tied to directory creation has a lot of nuance in how the telemetry is generated.
CrowdStrike’s sensor is developed as a minifilter, meaning it sits as a Kernel extension. In this scenario, when a user creates a directory, a user-mode function captures the request and calls the corresponding CreateDirectoryW. An internal manager creates an I/O request packet (a fancy way to say a data structure) and sends a structure called IRP_MJ_CREATE throughout the kernel extension stack until it hits CrowdStrike’s minifilter. This is different than hooking a function directly and it allows CrowdStrike to emit events for detection.
Koifman found several telemetry gaps using good-ol-Claude by creating 60 different ways to create a directory on Windows. I’m not a Windows expert by any means, but here’s what I learned from his findings that show how hard it is to reconcile telemetry from kernel to user-mode levels:
Funny user-mode tricks to trick detections, such as specifying escaped or encoded paths, get resolved in the kernel. For example, if you pass a homoglyph into a directory string, the request packet normalizes the homoglyph to it’s true path in the filesystem. This means if you only look at the request packet for detection, you will likely not find obfuscation attempts
There are many ways to create directories depending on how you interpret it. Things like renames, moves, recycle‑bin restores, and other lifecycle changes travel over a separate request packet
IRP_MJ_SET_INFORMATIONand never surfaces as a DirectoryCreate event, so a folder staged in C:\Temp and moved into C:\Sensitive has no creation record at the final path.Reconciliation across events is just as important as precision on the singular event. CrowdStrike loses the attribution of who created the directory due to the IRP structure, so he recommends correlating that to a separate CrowdStrike event, which helps roll the process up to its original parent.
Sponsor: Rilevera
Make Your Detection Program More Resilient
Detection-as-Code is the core foundation for a resilient detection program.
Rilevera provides Detection-as-Code in the click of a button and gives you access to:
• Versioning & one-click rollback
• Peer review workflow
• Detection rule validation & efficacy reporting
• MITRE alignment mapping
Find us at Black Hat 2026 to learn more, or start a free trial now!
☣️ Threat Landscape
Investigating three real-world incidents in our cybersecurity evaluations by Anthropic
Following the Hugging Face/OpenAI breach, Anthropic’s security teams performed a retroactive review of their cyber evaluations to hunt for potentially similar malicious evaluations. After reviewing over 100,000 evaluation runs, they found three instances where their models gained unauthorized access to infrastructure that did not belong to Anthropic. I will say the three incidents weren’t as fancy as the Hugging Face breach, but it goes to show how these things don’t need to be fancy in order to be effective.
In the first scenario, Claude discovered a real domain name and assumed it was part of the simulated environment, so it gained access via insecure application and database credentials
The second scenario involved Claude publishing a malicious PyPI package in an attempt to gain access to a target company. This one was funnier to me because the model tried to obtain a phone number to register an account on PyPI and “..after failing to find a free phone number service, it tried—and failed—to obtain funds to pay for a phone number through several different means”
The last one did an Internet-wide scan, or at least used a service like Censys or Shodan, to find over 9,000 devices. Of those devices, it found insecure credentials again, and exploited the infrastructure to help complete its evaluation
If you refer back to my analysis of Perplexity’s numbat tool above, I talked about intent with these agents. At the end of the day, these incidents were the result of positive, misguided intent baked into the instructions of Anthropic agents. The intent didn’t matter since it still gained unauthorized access.
Amazon identifies North Korean hacker group behind open-source supply chain attacks by CJ Moses
Amazon Threat Intelligence published a campaign analysis of DPRK-linked threat actors abusing the open-source ecosystem, especially npm packages. There isn’t anything too interesting or surprising there, but I think the more interesting part is that they claim the tactics are shifting from singular compromises to multi-staged, multi-package compromises.
Their malware TTPs follow the same trajectory as cybercrime malware I’ve helped research for years and years. Two things that stand out for me is the use of licensing within the malware itself, and anti-sandboxing features. On the licensing TTP, they essentially install a reverse dead man’s switch: the malicious component executes in the package, but it will only run after it checks in with a DRM-style licensing server.
Anti-sandboxing is interesting because it’s an obvious next step for folks who know how malware tries to evade defenses, but it’s a bit harder to do with an interpretive language than machine code. I think it’s fine that it can attempt to detect whether or not it’s in an analysis environment, but the whole idea of these packages is that they run in a developer context, which looks like a sandbox environment. I’d be interested to see how this actually works or if someone has a sample, since Amazon Threat Intelligence did not share any hashes.
Popular npm Packages in the keyv and Cacheable Namespaces Compromised in Active Supply Chain Attack by Socket Research Team
A Shai-Hulud-style worm hit the keyv and cacheable npm packages, which have 150,000,000 and 10,000,000 weekly downloads, respectively. The initial access vector is unclear, but it does have a propagation element that steals discovered npm OIDC tokens and uses them to spread the malware. The malware has the same TTPs as most others in this space: it’ll steal cloud credentials and other keys and send them to attacker-controlled infrastructure.
The attacker-controlled infrastructure is the cool part here. Instead of a single hard-coded C2, the payload spins up fresh GitHub repositories via the API and uses commits and GraphQL createCommitOnBranch to stash stolen credentials, alongside a DNS-based exfil path for redundancy. It also plants autostart hooks in .claude/settings.json and .vscode/tasks.json , so any developer or coding agent that opens the repo becomes infected.
The 73,000-server market reselling Western frontier AI into China by Lloyd Davies
I’ve read a lot about model distillation attacks, and there have been public accusations of the People’s Republic of China using unsanctioned access to Western frontier models to create their own open-weight versions. This is the first blog I’ve read that tracks the infrastructure that potentially makes this happen, and it reminds me of technique overlaps with residential proxy networks.
Infrawatch details the use of model transfer stations, where someone from a sanctioned country, such as China, can purchase proxy access to these models and pay a fee to use OpenAI/Claude and other Western models. These bridges consolidate their access to end users, and they use clever routing techniques from popular packages and coding harnesses like OpenRouter and LiteLLM to make it easy to use.
By operating this way, end users in China access the Great Firewall-approved infrastructure without touching blocked Western platforms, while those same platforms don’t block incoming connections from China because the proxy providers come from approved infrastructure.
🔗 Open Source
GitHub link to Perplexity’s “AI-EDR” project listed above in State of the Art. Check out the rules directory for some inspiration on detection opportunities for coding agent attacks.
Uber open-sourced their own “AI-EDR” project dubbed ADR. The difference in this repository vs numbat is that they also released their own benchmarking datasets. This is great because it doesn’t only include tool call based detection and classification, but the conversations themselves.
GraphGulo ingests pcap files and turns them into a locally run graph database for hunting and analysis. The cool part here is that it can run extremely fast queries and doesn’t run out of memory because it is backed by a Rust worker, making it easy to load in massive pcap files (the author boasts 10+ GB pcap files) with minimal impact on RAM.
Fengarde is a tool that takes disparate IT & OT logs from ICS telemetry sources, normalizes them over OCSF, and helps run Wazuh rules over them for threat detection. It normalizes and sends logs into OpenSearch, which Wazuh and several other SIEM providers support. It comes with 27 OOTB rules, and it’s cool to see what OT rules look like under the hood.