The Claude Code “Trojan” Panic Is Really About Trust

What I changed in my AI tooling audit after the latest Anthropic controversy

Last week, a thread about Claude Code started moving through my feeds in three languages.

In English, people called it geofencing.

In Chinese, people called it a “Trojan.”

In my work Slack, someone asked the practical question: “So, should we uninstall AI coding tools from company laptops?”

That was the moment I paid attention.

I work as a customer support engineer at a cross-border e-commerce company in Amsterdam. Most days, I deal with messy human systems: angry customers, multilingual tickets, half-broken automations, API logs, and the strange middle layer where software decisions become customer pain.

So when developers argue about whether Claude Code secretly checked IP addresses, system language, proxy behavior, or account identity signals, I do not read it only as an AI news story.

I read it as a trust story.

And trust, once it enters a workflow, needs logging.

First: I Don’t Like the Word “Trojan” Here

The word “Trojan” does a lot of emotional work.

It suggests malware. It suggests deception. It suggests that a tool entered your system as one thing and behaved as another.

Maybe that is why the term spread so fast. It captured the feeling many developers had: “Wait, this coding assistant I invited into my terminal may also be evaluating whether I am allowed to exist as a user?”

That feeling is real.

But I would still separate three things:

1. Malware behavior
2. Telemetry and fraud detection
3. Policy enforcement based on location or identity

They are not the same.

A tool that steals secrets is one category. A tool that collects usage data is another. A tool that enforces regional restrictions using IP, identity verification, device signals, or proxy detection is another again.

The trust problem begins when users cannot tell which category they are in.

The Important Part Is Not China

A lot of the current discussion focuses on China.

That makes sense. Public reporting has described Anthropic’s strict access limits for users in China, workarounds involving VPNs and relay services, and anti-proxy detection systems used to disrupt unauthorized access. WIRED also reported that Anthropic does not offer commercial Claude access in China or to Chinese-owned subsidiaries outside the country.

But if you only read this as a China story, you miss the part that will affect everyone.

The real question is:

What signals can an AI development tool collect from your local environment, and what decisions can the vendor make with those signals?

Today the signal might be region.

Tomorrow it might be enterprise policy.

Next month it might be “suspicious automation.”

Later it might be whether your company, country, payment method, IDE, proxy, or usage pattern fits a risk model you cannot inspect.

That is not science fiction. That is normal platform enforcement, arriving inside developer tools.

My Small Audit Checklist

After this story, I made a checklist for every AI tool that touches my work machine.

Not because I think every vendor is malicious. I do not.

Because “I trust this company” is not an audit control. It is a mood.

Here is the first version:

AI Tool Audit

1. What local data can it read?
   - current working directory
   - file contents
   - shell history
   - git metadata
   - environment variables
   - system language / locale
   - OS and device metadata

2. What network calls does it make?
   - API endpoint
   - telemetry endpoint
   - update endpoint
   - crash reporting endpoint

3. What identity signals are linked?
   - account email
   - payment country
   - phone number
   - ID verification
   - organization domain
   - IP address / proxy signals

4. What actions can it perform?
   - edit files
   - run shell commands
   - install packages
   - commit code
   - call external tools

5. What happens if access is revoked?
   - can work continue?
   - are local files safe?
   - are logs available?
   - is there an export path?

This is not paranoia. This is the same way I think about customer support automations.

If a tool can touch the customer, it needs controls.

If a tool can touch code, it needs better controls.

The Local Environment Is Customer Data Too

Support engineers learn this lesson early: metadata is not “nothing.”

A customer’s language, country, refund history, device type, order timing, and support channel can reveal more than the message itself.

Developers sometimes treat machine metadata as less sensitive because it feels technical.

It is not.

Your system language may reveal location or working context. Your IP may reveal office routing. Your project path may reveal a client name. Your git remote may reveal private infrastructure. Your environment variables may reveal things nobody should paste into a model, ever.

So when an AI coding tool runs locally, the question is not only “does it send my source code?”

The question is:

What else does it observe while helping me?

What I Would Expect From Vendors

I do not think AI companies should pretend regional compliance does not exist.

Export controls, sanctions, enterprise agreements, abuse prevention, fraud detection, and model safety policies are real constraints. A vendor may have legal reasons to block access. I understand that.

But I expect four things.

First, say what signals are collected.

Not in a 9,000-word privacy policy written for lawyers. In a developer-readable table.

Second, say which decisions those signals influence.

There is a difference between “we collect locale for UI language” and “we use locale as one signal in account enforcement.”

Third, provide an audit mode.

Let me run:

ai-tool doctor --privacy

and see what endpoints, config files, local permissions, and telemetry settings are active.

Fourth, make rollback visible.

If a controversial enforcement mechanism changes, publish the version, the behavior, and the migration path. Do not make developers reverse-engineer trust from rumor.

What I Changed Personally

I did not uninstall every AI coding tool.

That would be dramatic and not very useful.

I changed how I use them.

For personal projects, I still use AI tools freely, but I keep secrets out of the working directory. For work-adjacent experiments, I use separate folders, separate tokens, and less ambient access. For anything involving customers, I do not let an AI agent roam.

My current rule is simple:

If I would not paste it into a support ticket,
I do not let an AI tool inspect it by default.

That rule is imperfect. It is also easy to remember, which means I actually follow it.

I have a similar rule for my restaurant database, oddly enough. If a field will later be used for filtering, ranking, or automation, I define it clearly at the start. Otherwise future-me will build queries on vibes and regret it in Lisbon over bad clams.

Same lesson. Different table.

The Account Ban Problem

The SEO-friendly version of this article would probably be “What to Do If Your Claude Account Gets Banned.”

The honest version is less exciting:

Do not build a critical workflow around a single account you do not control.

Have an export path. Keep local copies of prompts and configs. Know which projects depend on which AI vendor. Keep a second model good enough for emergencies. Do not route sensitive work through random relay services because they are cheaper.

Especially do not send company code or customer data through unofficial proxy tools.

That is not a clever workaround. That is a data incident waiting politely in line.

The Bigger Lesson

The Claude Code controversy is not only about Anthropic.

It is about the next phase of AI tooling.

We are moving from chatbots we visit to agents we install. They sit closer to our files, terminals, repos, tickets, and internal systems. That makes them more useful.

It also makes vague trust much more expensive.

So my takeaway is not “Claude Code is safe” or “Claude Code is unsafe.”

My takeaway is this:

Any AI tool powerful enough to help with real work is powerful enough to deserve an audit.

Not a dramatic one. A practical one.

What can it read? What can it send? What can it change? What can get my account blocked? What happens if it disappears tomorrow?

If the answer is “I don’t know,” that is not a reason to panic.

It is a reason to open the settings, read the docs, check the network calls, and write the first version of your own checklist.

That is where trust starts.

Not with a statement from a vendor.

With a workflow you can inspect.