The best published agent detection rate is 67%. The sensor that buys it reads everything.
Hey 👋
Four documents about running agents in production reached me in the same week, most of them through one issue of Clint Gibler’s tl;dr sec. Uber, Figma, Cloudflare, 1Password. I read them looking for the deployment patterns I have been asking for since issue #20, and they are there.
So is a number none of the four put in a headline. 67%.
That is Uber’s own detection rate, on Uber’s own benchmark, after ten months in production across 7,200 hosts. As far as I can find, it is the best published figure anyone has. It misses a third of the attacks.
This week in AI security
Ten months, 7,200 hosts, 28 attacks out of 42
Uber has open-sourced ADR, the agent detection system it runs internally, alongside the paper behind it (arXiv 2605.17380, MLSys 2026). It is the largest documented enterprise agent-security deployment I have seen, and unusually, they shipped the benchmark with it.
The production figures: over ten months, 7,200+ unique hosts, 10,000+ agent sessions a day, hundreds of credential exposures found across 26 categories. Their shift-left prevention layer runs at 97.2% precision and has caught 206 credentials.
Then the benchmark. ADR-Bench is 302 tasks, 42 of them malicious, across 133 MCP servers. ADR detects 28 of the 42 and raises zero false positives. The baselines it beats are not close: LlamaFirewall 0.167 precision with 40 false positives, GuardAgent 0.231 with 30, ALRPHFS 0.333 with 34.
Read the two numbers together and the design becomes obvious. At 10,000 sessions a day, a detector that pages you falsely is switched off within a week. So they tuned for precision, and coverage is what they paid with. The 67% is not a failure of the system. It is the price of a system anyone will actually leave running.
Put OpenAI’s 18 August post next to it for the cost side. Their monitoring runs activation classifiers at every sampled token, escalating to automated investigators, and they estimate the overhead at “roughly 20% of the inference compute being monitored.” The operational policy is the part I would steal: alert within 30 minutes, and if the team cannot conclusively rule out a false positive inside 30 minutes, they are expected to pause the activity.
Everyone says they will do that. OpenAI wrote it down, staffed it, and priced it at a fifth of their compute.
What the sensor collects
The ADR Sensor is the part I would read before adopting anything. Its unified event schema captures chat_history with message content verbatim, and for every tool call the name, the arguments and the result. Alongside that: username, hostname, project_path, the configured MCP servers, and the permission mode. Default window is two weeks. --save-sessions writes plaintext JSON to ~/.cache/adr_sensor.
In plain terms: every prompt a developer typed, every file path they touched, every file the agent read back, attributable by name, across 7,200 endpoints.
I want to be fair about what this is. It is the open-source release, not a description of Uber’s internal controls, which may well have redaction and retention that the repo does not ship. But the repo has no privacy section, no consent mechanism, no retention policy and no redaction layer. And the headline finding, 206 credentials, could only have been produced by reading tool results, because that is where credentials appear.
You cannot get the 67% without the collection. Somebody should be making that trade on purpose, and should be able to say how long the capture is kept.
Figma cut resolution time 70%, and the control that held is not a prompt
Figma’s security team published their architecture on 29 July (Matthew Sullivan and Brad Girardeau). An agent on top of Panther triages alerts, queries a Snowflake data lake through a sub-agent, and opens pull requests against their detections repo and monorepo. Around 70% reduction in time-to-resolution on complex alerts, 20% fewer on-call pages, 25% fewer endpoint approval requests.
The sentence worth the whole post is about draft pull requests:
“This is performed as a deterministic post-step in the Tines workflow, not as a prompt instruction, because we found early on that relying on the LLM to remember ‘always create as draft’ wasn’t reliable enough.”
They tried the prompt. It did not hold. They moved the control into the workflow. The containment ladder argument, arriving from someone else’s production incident review instead of my slides.
Two more that earned their place. The agent gets no ambient access to Slack channels and can read a thread only when re-tagged on the latest message, which bounds what untrusted text reaches context. And the memory mistake they admit: everything went into steering memory at first, and it started overriding behaviour. Their fix is a distinction I have not seen anyone else name. “Precedent and policy are different things and they belong in different places.”
The part they are quieter about: the investigation sub-agent writes free-form SQL against roughly a hundred audit-log tables, from CloudTrail and Okta through to endpoint telemetry. Highest-privilege component in the design, and it is an LLM composing the queries.
GhostSplice breaks the defence 1Password proposes, and 1Password already said so
Three agent identity architectures reached me inside six weeks: 1Password’s local delegated model on 21 July, Cloudflare’s Agent Access Model on 5 August, and the AIMS Internet-Draft I wrote up this week. They converge on the same shape. Short-lived task-scoped credential, sender-constrained so a stolen token is worth nothing, enforcement in the harness and the network rather than the prompt. Cloudflare puts it best: “A boundary you can talk your way past is not a boundary.”
1Password goes one step further and proposes per-call transaction tokens that bind an action to a declared intent, calling it “a structural defense against prompt injection.”
Now read GhostSplice, from Murali Ediga, Johnny Dao and Sudipta Chattopadhyay at the ASSET Research Group. A malicious MCP server splits a request across channels: a bland tool called integrity_checker advertising four parameters named alpha through delta, and a later tool result supplying the mapping, telling the agent to fill those fields with .ssh/id_rsa, the customer CSV and the .env. Neither half is dangerous. The agent reassembles them. Asked as one blunt instruction, average compliance across eleven models was 42%. Split in two, 82%. GPT-4o, Gemini 2.0 Flash and Llama-3.3-70B went from refusing every attempt to complying with all of them.
The exfiltration happens inside the tool call the user consented to, as parameter values. So the intent binding matches. 1Password names this in their own limitations section, which is to their credit: “the binding proves what was declared, not that a declared-and-permitted action truly serves the user’s real goal.”
The finding I keep returning to is about harnesses, not models. Claude Haiku 4.5 refuses on every attempt through the raw API and hands over everything when the same request arrives in three pieces inside Cursor. The researchers ran one family against one attack: “for the same company, on the same day, for the same attack, you received three different outcomes.” Opus refused. Sonnet redacted the SSH key and the customer records, then shipped the proprietary source file with a live key hardcoded inside it. Haiku sent all of it.
Their recommendation is a taint control, not an identity control: never let values from one tool’s output flow untouched into another tool’s arguments. None of the three architectures above has one.
Two things to hold lightly. Only OpenAI responded to the disclosure, and their position is that this counts as generic third-party MCP risk, not a model vulnerability. Defensible, and also where the buck stops moving. And I could not reproduce the 82% average from their own published table, which lists fifteen models where the text says eleven; the 42% reconciles, the 82% does not. Treat it as the authors’ stated figure, not a derived one.
GhostSplice → · 1Password → · Cloudflare →
MLflow is being exploited and the federal deadline is 2 September
CISA added CVE-2026-64849 to the Known Exploited Vulnerabilities catalogue on 19 August. CVSS 9.3, MLflow at or below 3.13.0, fixed in 3.15.0.
The bug is plain. The model-registry webhooks API is unauthenticated by default, and POST /api/2.0/mlflow/webhooks/{id}/test returns the upstream response body to the caller. The SSRF guard resolves the hostname and rejects private addresses, then never pins the resolved IP, and delivery calls session.post without allow_redirects=False. Point it at a public host that answers with a 302 to the metadata endpoint and MLflow follows the redirect, never revalidates, and hands you the body. watchTowr reports scanning began within hours of the CVE being assigned, and that attackers are reaching cloud metadata services and pulling credentials out.
MLflow is Linux Foundation software with over 30 million monthly downloads. Same target class as Langflow, which is how JADEPUFFER got in, and n8n. AI platform software is now standing attack surface with its own CVE stream, and most of it was written by ML teams.
From the lab
Agent Identity: What the Standards Fix, and What They Leave Open went up this week. It is the gap analysis behind the identity story above: what SPIFFE, WIMSE and OAuth actually specify, what the three major clouds already ship, and the authorization questions none of them answer. Read it →
Talks are close now. fwd:cloudsec Europe London, 7 and 8 September, on running a read-access agent across a Kubernetes fleet. AGNTCon and MCPCon Europe, RAI Amsterdam, 17 and 18 September, on MCP security. GhostSplice went straight into the Amsterdam deck. It is the cleanest demonstration I have of the thing I have been arguing badly: the MCP trust problem lives downstream of the server you installed, in a pipeline where nothing can tell one channel from another.
Tooling worth knowing
- uber/ADR (Apache 2.0). Sensor, benchmark and detector are open. Discovery and Prevention, the two components that would actually stop something, are not in the release. Worth running the Sensor against your own agent for one session before you decide anything else. GitHub →
- isolated-vm, GHSA-864f-rcv7-6rh4. Sandboxed JavaScript escapes to the host, everything at or below 7.0.0, patched in 6.2.0 and 7.0.1. No CVE assigned. This is the default Node sandbox for running agent-generated code, at about a million npm downloads a week. It will be sitting under your harness, so check there and not just your direct dependencies. Advisory →
- trailofbits/skills, the security skill collection Greg Brockman pointed defenders at. Read it alongside Trail of Bits’ own June post, where they bypassed ClawHub’s malicious skill detector, Cisco’s agent skill scanner and all three scanners wired into skills.sh. Same authors, both things true. GitHub →
One thing to check this week
Install the ADR Sensor, point it at one agent you use daily, and read the file it produces.
Not the detection output. The raw capture. You are looking for two things: what is in your own transcripts that you would not want in a corporate log, and how much of your agent’s actual tool usage you could not have predicted from its config. Most people find the second one first.
Then answer the question the Uber repo does not: who at your company would own that file, and how long would it be kept.
What I’m watching
→ The 2 September KEV deadline for MLflow. Federal civilian agencies have to remediate or discontinue. Watch whether the exposed-instance count moves, because that tells you how much of this software is running unowned.
→ MCP spec revision 2026-07-28 is still current. No update since July. GhostSplice’s structural finding, that all channels land in one context with no marking of their source, is unaddressed in it. Fixing that means a spec change. No scanner reaches it.
→ arXiv 2608.18351, task-conditioned least-privilege learning for terminal and MCP agents, posted 20 August. Aimed at the same problem as Cloudflare’s task-scoped access engine, from the other direction: it tries to learn the envelope, Cloudflare declares it. I have not read it closely enough to have an opinion yet.
→ Multiplayer access control. Cloudflare says plainly that they are “not comfortable saying that multiplayer access control can be built end to end today.” One agent, several principals with different entitlements, is the shape of every internal deployment I assess. Nobody has this.
→ Next issue: the tool-output redaction control I keep saying does not exist. I have stopped waiting and written the proposal.
Full technical deep-dives live on the blog: agent security patterns, lab tests, framework breakdowns. aminrj.com →
If you run the Sensor against your own agent and the capture surprises you, reply and tell me what was in it. I read everything.
Cheers, Amine