← Back to all posts
Published on · by Renaud Deraison

The agent log was in their cloud

Warp has disclosed that attackers stole agent traces and telemetry for roughly 1% of its users by breaking into a vendor in Warp's infrastructure, and its CEO says the intruders used a swarm of AI agents to do it. An agent trace records what the agent read, ran and saw, so it can hold code, command output and secrets. In Bromure Agentic Coding, the agent's trace is written and encrypted on your Mac, every secret the agent handles is a stand-in, and you choose which hosts receive anything at all.

An agent trace is a record of everything the agent read, ran and saw. Warp's traces sat with a vendor, and on October 23 someone got into that vendor.

On Friday, October 23, Warp became aware of what its founder and CEO, Zach Lloyd, called "an active and narrow-banded exploitation of a vendor in Warp's infrastructure." Warp has grown from a terminal into what it calls an agentic development environment, and the data taken was agent traces and user telemetry. Lloyd puts the upper bound at roughly 1% of Warp users. The company's site claims at least 800,000 users, so 1% is on the order of 8,000 developers. BleepingComputer reported the disclosure yesterday.

Warp says it detected the operation within hours and contained it. It has engaged CrowdStrike, informed law enforcement and notified affected users. According to Risky Business, Lloyd says the intruders used a swarm of AI agents to breach the supplier. Warp hasn't named the vendor, described the vulnerability, or said whether the stolen traces included source code, prompts or credentials. Its advice to users: monitor account activity and treat unsolicited messages with more caution than usual.

It is the second coding-agent breach this month to start on a vendor's servers. On October 16, attackers reached the provider API keys that about 1.4% of OpenCode Console users had saved, and some users found charges of up to $1,700 they hadn't run up. We covered it in The keys were in their console.

What an agent trace holds

A coding agent works in a loop. It reads a file, runs a command, reads the output and decides what to do next, and a trace records each step. That includes the prompt you typed, the files the agent opened, the diffs it wrote, the shell commands it ran and what those commands printed.

That last part is where secrets end up. An agent that debugs a failing deploy runs env, opens .env, prints a config file and pastes a stack trace with a connection string in it. In The transcript kept the token, Trellix showed coding agents copying secrets from the keychain into command lines, shell history and their own transcripts as a side effect of ordinary work. Customer data gets in the same way: the agent opens a CSV or queries a table to check a fix, and the rows land in the trace.

A trace also holds your codebase in pieces, the names of internal hosts, and a timeline of what you worked on. For an attacker, a few thousand of them are a list of developers to phish, each with a convincing story about the project they were working on that week. That risk sits behind Warp's advice about unsolicited messages.

Where a cloud-kept agent trace travels1 · The agent workson the developer's laptop:reads files, runs commands,reads their output2 · Trace to the vendoragent decision logs andtelemetry, kept in thetool vendor's cloud3 · The vendor's vendora third party in Warp'sinfrastructure; not named,flaw not disclosed4 · Breached October 23by a swarm of AI agents,per Warp's CEO; traces for~1% of users takenWhat an agent trace can containprompts · source files the agent opened · diffs · shell commands and their output · environment values printed while debuggingcustomer rows from a query or a CSV · internal hostnames · a timeline of what each developer worked on
The path of an agent trace when the tool keeps it in the cloud. The agent works on the laptop, the trace goes to the tool vendor, and the vendor stores or processes it with a third party. Warp's attackers got in at that third party.

The same session on a Bromure machine

Bromure Agentic Coding runs Claude Code, Codex, Grok, Kimi and omp in Ubuntu VMs on your Mac. Every request a machine makes, including each call the agent makes to its model, goes through a proxy on the Mac. That proxy is where Bromure records the trace, swaps credentials and applies your network rules. Take the debugging session above and run it there.

The trace is written on your Mac

Bromure's session trace answers the question you ask after an incident: what did the agent do? New machines record AI request details: one metadata record for every request, plus the full request and response bodies for the model providers. The Trace Inspector (⇧⌘I) parses those bodies into a conversation view with every tool call, every shell command the agent ran and every file it read or wrote. bromure-cli trace gives you the same data in a terminal.

All of it lives in ~/Library/Application Support/BromureAC/traces/ on your Mac. Captured bodies are sealed with AES-GCM under a key held in your Keychain, with file permissions 0600. For an individual install, no trace record, body or summary is uploaded anywhere, and the proxy has no analytics endpoint wired for individual users. The prompt-injection classifiers that read the same traffic run on the Mac too.

No vendor holds a copy, and neither do the vendor's suppliers. An attacker who breaks into a logging provider finds none of your sessions there.

The secrets in the trace are stand-ins

Back to the debugging session. The agent runs env, opens .env and prints the deploy config. On a Bromure machine, every credential you configured is a fake inside the VM. ANTHROPIC_API_KEY holds an sk-ant-api03-brm- value, GH_TOKEN and ~/.git-credentials hold a ghp_ stand-in, ~/.aws/config points at a helper that hands out a fake secret key, and the SSH keys stay on the host behind an agent socket. Keys you import from an existing .env become stand-ins too. The proxy puts the real value on the wire only for the host that credential belongs to.

So whatever the agent prints and pastes into its conversation is a stand-in. That holds for every copy: the model provider's logs, the agent CLI's own history files, a crash report, a trace. Off the machine, the stand-ins authenticate nowhere. If one of them heads for a host it wasn't minted for, the proxy blocks the request with HTTP 451, pauses the VM, and shows This environment may have been compromised with the credential, the host it belongs to and the host it was sent to.

Bromure's own trace goes a step further. Authorization, Cookie, api-key and similar headers are rewritten to <redacted> before anything is written, and each credential swap is stored as a first-and-last-character preview such as sk-a…f9q3. The real secret never enters a trace record, encrypted or not.

Customer data stays on the Mac

Turn on PII Protection in the machine's settings and the proxy finds personal data in each request before it leaves for the model provider: names, email addresses, phone numbers, card and bank numbers, government IDs and street addresses. It replaces each value with a realistic stand-in, a made-up name or an @example.com address, and puts the real values back in the reply, including in tool-call arguments. Detection runs on the Mac with the built-in Rampart model.

The agent works with the real rows, and the provider sees the stand-ins. The same customer gets the same stand-in on every turn, so prompt caching keeps working. The Security Timeline counts each swap, 3 names · 1 phone number → api.anthropic.com, without logging a single value.

For work that should stay on the Mac, route the agent to an on-device model. MLX models run on the Mac's GPU, and those turns go nowhere else.

You choose who receives anything

Agent CLIs talk to more than their model. Error reporting, feature flags and usage telemetry each go to a host of their own. In the machine's Guardrails pane, set Unmatched traffic to Deny and allow the hosts the project needs: the model provider, your forge, your package registries. Every other connection is refused at the Mac, and each refusal is a row in the Security Timeline. You end up with a written list of the companies that receive data from that machine, and you wrote it.

Teams get oversight without collecting transcripts

Organizations still need to see what their agents do. A Mac enrolled with a bromure.io workspace streams session metadata to the administrators: tools used, files touched, commands run, token usage. Raw prompts are never emitted. The full conversation stays in the encrypted trace on the developer's Mac. A red dot in the window header shows when a machine is streaming, and Private mode keeps a workspace's activity local, for example one that uses a personal API key.

Laptop agent, trace in the cloudAgent runs env, opens .envreal API keys and tokens in the outputTrace kept by the vendorand handled by the vendor's own suppliersOne supplier breachedworking keys, code fragments, customer rowsand a phishing pretext for every developerBromure: trace on your MacAgent VM (Ubuntu)env and .env show stand-ins; real keys never in the VMHost proxy on the MacPII swapped before the provider; unapproved hostsrefused; stand-in sent elsewhere: 451, VM pausedTrace in Application SupportAES-GCM under a Keychain key; auth headers redacted,swaps kept as previews; nothing uploaded
The same debugging session on a laptop agent with cloud-kept traces, and on a Bromure machine. On the laptop, the trace carries real secrets and customer rows to the vendor and its suppliers. On Bromure, the trace is encrypted on the Mac, secrets in it are stand-ins or previews, personal data reaching the provider is swapped, and unapproved hosts are refused.

The week after

Warp's affected users now have to work out what their traces contained and rotate whatever might have been in them. On a Bromure Mac, the first part takes a few minutes. Open the Trace Inspector, filter by workspace, and switch on Conversations only to see every command the agent ran and every file it read. Leaks only lists any request that carried a real token Bromure didn't mint, which shows whether a raw secret ever went past the stand-ins.

Rotation happens in one place. The real keys live in one encrypted vault on the host. Paste the new value into the machine's Credentials pane and the next launch writes the matching stand-in. A key stored as a 1Password reference is re-resolved every two minutes, so a rotation in 1Password reaches running machines without a reboot.

Traces stay home

The session trace is written on your Mac and sealed under a Keychain key. Individual installs upload nothing.

Secrets are stand-ins

Whatever the agent prints is a fake. Traces keep auth headers redacted and swaps as short previews.

PII is swapped

Names, emails, card numbers and addresses reach the model provider as stand-ins, detected on the Mac.

You pick the hosts

With Unmatched traffic set to Deny, only the hosts you allowed receive anything, and each refusal is logged.

Keep the record where the work happened

Agent traces are worth keeping. They are how you find out what an agent did at 3 a.m. and how you answer an auditor. The question is who holds them. Each company that stores your agent's decision log is one more company whose suppliers can lose it, and attackers now run agents of their own to find the weak supplier.

Bromure Agentic Coding keeps the full record on the machine where the agent worked, encrypted under your Keychain, and fills it with stand-ins in place of secrets. When the next vendor discloses a breach, you answer "were we in it?" from your own Trace Inspector.

For how agents spread secrets through their own transcripts, read The transcript kept the token. For the OpenCode Console breach earlier this month, read The keys were in their console.