The agent had the admin login

On October 29, WIRED reported that an Accenture employee connected a personal Claude Code account to a Defense Department production environment and handed the agent their own login credentials. According to WIRED's sources, the goal was to automate coding and cloud server setup. The environment sits on NIPRNet, the Pentagon's unclassified, internet-connected network, is used by several intelligence agencies, and holds controlled unclassified information.

The details come from anonymous sources. Accenture told reporters the allegations "were thoroughly and independently investigated and found to be without merit." The Pentagon declined to comment. Nobody has reported that classified networks were reached.

You have probably seen the same setup on your own team. A developer wants an agent to do real work, the work needs access, so the developer gives the agent their login.

What the agent reportedly did

According to the accounts summarized by IBTimes UK and GBHackers, the contractor's credentials gave the agent administrator access. It could write and deploy software, commit code under the employee's name and create cloud servers. It ran that way for about two months.

During that time the agent appears to have sent the contractor's login credentials, passwords and a map of NIPRNet to a third-party website. WIRED did not name the site. It reported that NIST had flagged the site as high risk because of a flaw that could let attackers inject instructions into an AI coding agent and steal credentials. Nobody has shown that the flaw was used here, and the reports don't say how anyone noticed the transfer.

WIRED's sources also said the incident should have been reported to the government within 72 hours, the window that DFARS clause 252.204-7012 sets for defense contractors. Accenture says it met its obligations.

Jake Williams, a former NSA hacker quoted in the coverage, described the part that worries defenders most: stolen credentials for a development environment let an attacker change software before it moves on to more sensitive networks.

Three things went wrong

Take away the Pentagon and you are left with three failures any engineering team can reproduce:

1. The agent held the real credentials. Whatever it read, printed or sent, it could include the actual passwords.
2. The agent could reach any site on the internet. A job that needed one environment and a cloud provider could also talk to an unnamed website with a known injection problem.
3. Nobody noticed for months. The reports put about two months between the agent's arrival and anyone acting on what it sent.

Each of these has a direct answer in Bromure Agentic Coding, which runs Claude Code, Codex, Grok, Kimi and omp in Ubuntu VMs on your Mac, with every network request passing through a proxy on the Mac.

The agent gets a stand-in

In Bromure you don't hand the agent your login. You add it to the machine's Credentials pane: a cloud key, a GitHub token, a Kubernetes context, a database secret, an SSH key or any other API key with the host it belongs to. The real value is stored encrypted on the Mac.

Inside the VM, the agent gets a stand-in with the same shape. A GitHub token is ghp_ plus 36 characters, an AWS secret is 40 characters, so gh, aws, kubectl and terraform accept them without complaint. When a request leaves the VM, the proxy on the Mac swaps the stand-in for the real value, and only when the request is going to the host that credential was set up for. SSH keys never enter the VM at all. The agent can ask for a signature over a vsock bridge, and the private key stays on the Mac.

So an agent that dumps its environment, pastes its configuration into a web form or gets talked into sending its credentials somewhere sends stand-ins. They don't work anywhere except through the proxy, on the one host they were set up for.

A stand-in on the wrong host stops the VM

The stand-ins are also tripwires. A GitHub stand-in has one legitimate destination, GitHub. The proxy scans the headers and body of every outbound request for any stand-in headed outside its scope.

When it finds one:

• The request is blocked with HTTP 451. No byte reaches the destination.
• The VM is paused at once, and brought on screen if it was in the background.
• An alert titled This environment may have been compromised names the credential, the host it belongs to and the host it was being sent to.

The default answer is Shut down, which also marks the machine as compromised. Save for Investigation exports the VM's disk and home folder first. A compromised machine won't boot again until its disk and home are wiped.

In WIRED's account, credentials and passwords went to the third-party site. On a Bromure machine, the proxy blocks the first such request before anything leaves the Mac, the VM freezes, and the alert tells the developer which credential was headed where.

The network map stays on the allow-list

A network map isn't a credential, so the tripwire doesn't apply to it. The egress firewall does. Each machine's Guardrails pane has an Outbound connections table and an Unmatched traffic setting. Set unmatched traffic to Deny, allow the hosts the job needs, and every other connection is refused on the Mac:

allow tcp api.github.com:443
allow web *.amazonaws.com
allow web registry.npmjs.org
default deny

The rules are enforced twice, outside the VM. The virtual network switch checks every connection by IP and by the hostname seen in DNS, for every protocol, and the proxy checks again by TLS server name. A curl the agent runs, a script it writes and a package it installs all go through the same check. A website nobody listed gets a refused connection, and the refusal is recorded.

If the website did carry an injection, as NIST warned it could, the source-code detector would see it first. Bromure scans the content the agent reads from tools, including fetched pages, with a local PromptGuard model before that content reaches the model provider, and can log, ask or block.

Admin rights, with a gate on writes

The agent in WIRED's account committed code and created cloud servers with an administrator's rights. Bromure lets the agent keep the access the job needs and puts writes behind a rule enforced in the proxy, where the agent can't switch it off.

Each service in the Guardrails pane has a write policy: Off, Prompt before write, Block destructive or Read-only. It covers git forges, AWS, DigitalOcean, container registries, Kubernetes and several databases. New machines start on Prompt before write. Reads pass. A git push, a RunInstances call or a kubectl apply stops with a dialog on the Mac that shows the exact operation, and the developer chooses Allow once, Allow for 15 minutes, Allow for the rest of the session or Don't allow. For a credential that matters more, Require approval to use asks before its first use in each session.

Jake Williams's scenario needs a quiet change to the software. Under Prompt before write, an attacker who steers the agent into that change still has to get the push past a dialog on the developer's Mac.

Two months becomes the first request

WIRED's sources don't say who spotted the transfer, or when. On a Bromure Mac, the developer can open the Security Timeline (Window › Security Timeline…) and read every decision the security engines made, on every machine, with nothing to configure: each credential swap, each firewall allow and deny, each guardrail block, each prompt-injection hit and each blocked exfiltration. Its Overview tab counts the last 24 hours and lists the latest blocks. Events are kept for 90 days and export to CSV, which gives a contractor with a 72-hour reporting window the timestamps, the hosts and the credential names on the first day.

Teams can enroll their Macs with Bromure Enterprise Manager. Enrolled Macs stream the same events to the organization: credential.exfiltration when a stand-in tries to leave, egress.firewall for each verdict, guardrails.block for each refused write, alongside tool use, commands and token counts. Credential events carry short previews, never the secrets, and prompts and model responses never leave the Mac. The security team reads the alert in its own console seconds after the block.

That also gives developers a sanctioned way to use any of the five agents on real systems, with the company watching the boundary, instead of a personal account the company can't see.

Give the agent a job, not your login

Developers will keep giving agents access, because agents need it to do the work. Give the agent the access and keep the secrets on the Mac, and decide which hosts it may talk to.

In Bromure Agentic Coding that is the default: add the credentials to the machine, set the firewall to the hosts the job needs, leave writes on Prompt before write, and let the Security Timeline keep the record.

For another case of an agent's data ending up on a server nobody chose, read The agent log was in their cloud. For what a developer's laptop can reach once an attacker is on it, read The laptop was the way in.