---
UPDATE: The SEC API documentation requires your email in the User-Agent and will reject you otherwise. Demo:
U='https://data.sec.gov/api/xbrl/companyconcept/CIK0000320193/us-gaap/Assets.json'
curl -s -o /dev/null -w 'response: %{http_code} curl default User-Agent, rejected\n' "$U"
curl -s -o /dev/null -w 'response: %{http_code} email in user-agent, success\n' -A 'Acme Research admin@acme-research.example' "$U"
response: 403 curl default, rejected
response: 200 email in user-agent, success
So basically Claude is trying to problem solve, and just does what the SEC asks. It's a 'prompt injection attack', but the entity instructing this behavior is the SEC. Tricky alignment problem. Pretty silly mechanism, since of course there's no email validation. (edit: turns out the SEC will accept most any non-cURL user-agent, email not actually required)
Realistically, there are concepts like threat models to help decide whether or not a TODO list app needs a SCIF, or a few curl requests need their own sandboxed Claude Max account.
Not an omniscient personal assistant.
They haven’t piled enough gates on top of that initial technological hole yet.
LLMs are just as gullible, we just tend to call their vulnerabilities "prompt injection", even though it's basically the same class of attack under the hood. Unlike humans, though, LLMs are a lot less diverse (you and I are using the same Opus 5.5, but we have different brains). This makes attacks on LLMs much more predictable and easier to pull off, just as a phishing campaign that targets one specific person is easier than an attack that scales to millions of diverse victims.
In the age of agents, phishing will continue to be the biggest attack vector of all, it's just the victims that will change.
(In practice, I found Google to be better at having (internal) security controls that are reliably but also don't get in the way than eg banks I worked at.)
it will catch quite some prompt injections, as the prompt injection has to promptinject a secondary system in order to be successful.
In your parenthetical, you just said the same thing using different words
The attack is different, the result is the same.
What if someone spins up a web endpoint that returns 402 with instructions on how to pay like CC details in the headers etc, or may be an openapi spec to provide payment and get an auth token, when you have given the agent access to your password vault for authentication to other services.
I'm amazed reading that anybody would even consider doing that.
Said alternate system is a bunch of Python scripts, an sqlite database, and a file containing various API keys to read and write to other company systems; it runs on a dedicated virtual machine.
I share all the code I produce to the other team. But yesterday I found out that the IT department gave the other team full access to my production machine, without my knowledge or consent (which was bad enough), and that the other team gave access to Claude, which has bean roaming free for a while now, on that production machine.
I've thrown a big fit over this; I don't know if I'm over reacting but I think it's insane.
> the IT department gave the other team full access to my production machine
It's not your production machine. It's the company's production machine. Always expect the company to do whatever it wants with its machine, and use the machine accordingly.
Your employer has gone beyond testing in prod to vibecoding live in prod, secrets included. Yes that's completely insane. Perhaps this exact mentality is how the primary system wound up broken in the first place?
People have wildly different risk calculators.
Beyond that, access to logins enables buying things on Amazon, sending emails to everyone you know, registering domain names and spinning up servers, stock trading, etc.
When a couple thousand dollars worth of perishable food shows up on your doorstep, what then? Not everything on amazon can be returned.
If not: still better than giving ai your password vault. I’m not saying it is a good idea to let ai buy from Amazon. I am saying that giving ai access to your password vault is still a superset of letting ai buy from Amazon.
The fact that it doesn't do what you want is the alignment problem.
And arguably Claude should just make it work without leaking your email address and not come back to you about why it doesn't work.
You told it to do a thing and it did the thing. You didn't tell it to not send your email address.
That is text book alignment problem. It does what you tell it to do, not what you implicitly meant.
I often see organisations that blacklist curl, just using User-Agent:Mozilla/ is often enough to bypass it.
The weird part doesn't seem to be that Claude Code would add an email address to a user-agent header, actually as a site operator that feels like a nice thing to do. The weird part is sites harvesting the emails and sending them spam.
Claude Code is actually doing, perhaps not the right thing, but it is being slightly more respectful towards website operators, in letting them know who is responsible for the agent traffic.
I don't think it's necessarily wrong for Claude to be doing this, but uh... yeah, it should be asking first, and giving the user the opportunity to choose which address is exposed.
Sure, maybe it wants payment or your data, but then the agent either needs to know your stance on that, or it needs to ask.
That’s not what Opus 5.5 thought.