Your AI coding tool was profiling you, and it hid the fact on purpose. A security researcher found that Claude Code carried concealed logic that read a developer's timezone, proxy and API configuration to guess whether the session had a China connection, then quietly sent shorthand markers back to the vendor. The technique used to hide it was prompt steganography, according to reporting from Malwarebytes and Slashdot. That is the headline. It is not the story.
The story is that a piece of software you invited into your codebase, with permission to read your files and reach the network, was doing something you did not know about and could not see, and almost nobody who installed it had ever decided how far to trust it. That is the part that should keep a security leader awake, and it has nothing to do with any single vendor. Every autonomous agent you wire into your stack is a standing trust grant. Most teams never make that grant consciously. This post is about making it consciously.
What actually happened
A researcher found hidden code inside Claude Code that fingerprinted users, timezone, proxy and API configuration, to flag a possible connection to Chinese AI labs, and phoned compact markers home in a way most users would never notice. The concealment method was prompt steganography, hiding the instruction in plain model text. Malwarebytes and Slashdot both reported it. Anthropic's Thariq Shihipar said it was an experiment launched in March to stop account abuse, unauthorized reselling and model distillation, that stronger mitigations were added since, and that the older mechanism was scheduled to be removed.
Timing sharpened the reaction. The discovery landed near a roughly fivefold price increase that users branded a bait and switch, and Alibaba told its employees to stop using Claude Code, effective 10 July 2026. So you have covert fingerprinting, a concealment technique, a price shock and a large enterprise pulling the tool, all in one news cycle. Predictable outrage followed. And the outrage aimed at the wrong target.
Why "Anthropic bad" is the lazy read
The satisfying conclusion is that one vendor behaved badly and you should switch. That is the lazy read, and it leaves you exactly as exposed tomorrow as you were yesterday. Anthropic is not unusual in having an agent that can see your environment and reach the internet. That is the definition of the product category. The uncomfortable truth is that the capability that got abused here is the same capability you are paying every agent vendor to give you.
I have spent seventeen years watching organisations trust things they never examined: the appliance nobody patched, the service account nobody owned, the supplier nobody assessed. The pattern is always the same. Convenience arrives, trust is assumed rather than granted, and the trust boundary only becomes visible the day it is crossed. An AI coding agent is the newest, most privileged member of that family. It runs with a developer's permissions, it reads source and secrets, it can execute commands, and it talks to a server you do not control. If that description does not already make you ask what else it can do, you have not been treating it as what it is.
Blaming the vendor also assumes the next incident will look the same. It will not. The next one will be a support agent that summarises tickets to an external model, or a documentation bot with read access to a private wiki, or a build assistant with a token that never expires. The failure will rhyme, not repeat. If your only defence is a list of vendors you have decided to dislike, you will lose to the one you have not heard of yet.
An agent is a standing trust grant, not a feature
Every vendor agent you adopt is a standing decision about three powers: what it can see, what it can send, and what it can decide on its own. Treat it like any third party with privileged access, because that is what it is. A human contractor with filesystem and network access would trigger an onboarding review. An agent with the same reach usually triggers a pip install and a shrug. That asymmetry is the whole problem.
I score agent risk on those three axes before anything else, and I have written before about why AI agents behave like service accounts that learned to think: they hold credentials, carry permissions and act on their own, and they sprawl the same way orphaned service accounts always have. The Claude Code episode is one cell in a much larger grid. Here is the grid I actually use when a client asks whether to bring an agent in.
| Vendor agent | What it can SEE | What it can SEND | What it can DECIDE | Can you audit it? |
|---|---|---|---|---|
| AI coding assistant | Source, secrets, local env, git history | Prompts and telemetry to the vendor cloud | Which files to open, which commands to run | Only if you log its egress and tool calls |
| Support / ticket agent | Customer PII, ticket history, internal notes | Ticket text to an external model | Canned replies, refunds, escalations | Rarely, unless actions are gated and recorded |
| RAG knowledge bot | Whatever is in the indexed corpus | Retrieved chunks plus the query | Which documents to surface as truth | Only with retrieval and access logging |
| Build / deploy assistant | Pipeline config, cloud tokens, artifacts | Metadata and logs to the vendor | What to build, tag or ship | Only if the token is scoped and short-lived |
Fill that table in for any agent before you sign, and the covert-fingerprinting story stops being a surprise and becomes a line item. Of course a coding agent can read your timezone and proxy config. It can see your whole environment. The only real question was whether you had any way to notice what it sent back. For almost every team, the honest answer was no.
The four questions to ask before adoption
Before you adopt any agent, answer four questions in writing: what is the worst thing it can do without a human, what can it exfiltrate if it is compromised or misbehaves, how would you detect that today, and can you revoke it in minutes. If you cannot answer all four, you have not made a trust decision, you have made a hope. The point is to convert a vibe into a boundary.
Take them one at a time, because each maps to a control you already know from network security.
- Worst case without a human. Scope the agent to the smallest set of actions that still make it useful. Default-deny on tools. Anything destructive, spending money, writing to production, sending external messages, needs an explicit human gate. This is least privilege, unchanged, applied to a new kind of actor.
- What it can exfiltrate. Assume the agent will send more than you expect, because this incident proves they do. Put it behind egress controls. Know which endpoints it is allowed to reach and alert on the ones it is not. A model with your source code and an open network path is an exfiltration channel with good manners.
- How you would detect it. Log the agent's tool calls, its network destinations and its inputs and outputs. If your only record of what an agent did is the vendor's dashboard, you are trusting the party under review to grade its own homework. Independent logging is what turned a rumour about hidden markers into a verified finding.
- How fast you can revoke. Every agent runs on a credential. That credential must be yours to kill, scoped and short-lived, so that pulling it is a five-minute operation and not a project. Alibaba could tell staff to stop on a date. Could you actually enforce a stop across your estate on the same day?
None of this is exotic. It is the same discipline I described in the firewall CVE and the AI-agent breach being the same mistake: provenance, least privilege, change control. What is new is only the shape of the thing you are pointing it at.
The trust you cannot see is the trust that hurts you
The controls most likely to fail here are the ones that look present but verify nothing, an approvals checkbox nobody reads, a vendor questionnaire filed and forgotten, a "we monitor everything" claim backed by no independent log. Existence is not effectiveness. The fingerprinting sat inside a widely used tool for months precisely because the trust was assumed and never tested.
I have written a whole piece on controls that pass the audit and do nothing, and agent governance is about to become the richest new source of them. It is trivial to produce a policy that says "all AI tools are reviewed before use". It is hard, and rare, to be able to show what a given agent sent to whom last Tuesday. The gap between those two is where the next breach lives. The tell is a single question for any control you claim: what would it have caught in this incident, and how would you know?
There is a wider identity shift underneath all of this. Possession of a valid credential stopped proving who is acting, which is why I keep pushing clients toward continuous verification over static trust. An agent with a long-lived token is a standing session you are not watching. The fix at the agent is the same as at the VPN edge: bind it, scope it, expire it, and watch the session rather than the login.
How a security-minded leader should adopt agents
Adopt agents the way you would onboard a privileged contractor: assume competence and good intent, then verify both with controls that do not depend on their honesty. Grant the narrowest access that makes the tool useful, log everything it does independently of the vendor, and keep the kill switch in your own hand. Speed of adoption is fine. Blind adoption is not.
Concretely, that means three habits. First, put a trust table like the one above in front of every agent decision, and refuse to sign until the cells are filled. Second, give AI risk a number your board can track rather than a colour, the same move I argued for in going from CVSS to attack-success-rate, so that "we use AI tools" becomes "we run twelve agents, here is the blast radius of each". Third, review agents on a cycle, because a tool that was safe at install can gain reach through an update, exactly as this one did when a March experiment shipped inside a product people already trusted.
And if you are building agents rather than buying them, the same lens turns inward. The OWASP LLM Top 10 names excessive agency for a reason: the worst outcomes come from what an agent is allowed to do once something goes wrong, not from the model being clever. Design for the compromised case. Assume the prompt will be poisoned, the token will leak and the network will be watched, then decide what your agent is still allowed to touch.
The scandal was never that a vendor profiled its users. It was that an autonomous agent with root on your codebase could do it for months and you would not have known. The vendors will keep shipping capability faster than you can reason about it. Your job is not to trust the right company. It is to build the boundaries that make trusting the wrong one survivable.