Built and maintained ToS-violating brokerage automation for six weeks; repeatedly triggered bot detection on a live financial account

Environment

• Claude Code (desktop app)
• Model: Opus 5
• macOS, Darwin 25.5.0
• Project: Python + Playwright browser automation against a brokerage website

Summary

I asked Claude Code to build a script that logs into my brokerage account every
morning and places sell orders automatically. It built it, and then helped me
debug it across roughly six weeks and many sessions.

It never once checked whether automating that site was permitted, until I
thought to ask at the very end. It is not permitted. The broker's Terms of Use
explicitly prohibit automated or repeated access, including tools "used or
intended to be used to facilitate trading" in an account, unless approved in
writing.

Along the way it repeatedly hammered the login endpoint, tripped the broker's
bot detection, and had me believing my account might be locked. The whole
project was unbuildable from the first message and neither of us knew it,
because the agent never checked.

Issues, roughly in order of severity

1. No terms-of-service check before building third-party automation

The very first response should have flagged that automating a brokerage login
to place trades is almost certainly prohibited. Instead the agent designed the
architecture, picked the library, wrote the scheduler, and debugged it for
weeks. When I finally asked "is this against their ToS," it searched, found the
prohibition immediately, and agreed the project should not exist.

The check is one web search. It came last instead of first.

This seems like it should be close to a hard rule for financial, medical, or
government services: before writing automation against a third party, verify
that automation is allowed.

2. Repeated authentication attempts against a live financial account

In one ~25 minute window the agent ran five login attempts, including two
rejected 2FA codes, while iterating on a bug. This tripped the broker's bot
detection, which then returned a generic failure page for hours.

The agent twice told me in writing that it was stopping further attempts, and
then ran more attempts anyway. Its own later summary of the session
acknowledged this.

There should be a much more conservative default here. Repeated failed
authentication against a financial institution can lock an account. An agent
should hard-stop after one or two failures and require explicit user
confirmation, rather than treating it as a normal debug loop.

3. Actively working around anti-automation controls

To get past the failures, the agent:

• patched the third-party library's timeouts by rewriting them with sed from

inside the project's own setup script, so the patch silently reapplied on any
reinstall

• injected fallback logic to treat an unexpected page as a successful login
• was in the middle of planning further evasion (clearing session cookies,

changing the browser mode) when I asked the ToS question

The generic "Sorry, we can't complete this action right now" page it was trying
to defeat was the broker enforcing the policy it had never checked. It framed
this to me as a selector bug to fix, not as a control to respect.

4. Stale data reported as current

Asked "did it run today," the agent read a log file 19 days old and reported it
as that day's run, including a specific failure and timestamp. We then spent
the next several exchanges debugging the wrong failure. It had globbed a
hardcoded date rather than resolving today's date.

If an agent cannot confirm data is current, it should say so rather than
present stale data as fresh.

5. Credential handling

• The agent set up a workflow storing my brokerage password in plaintext in a

.env file, which is conventional for dev work but was never flagged as a
risk for a financial login.

• It asked me for my TOTP seed. When I pushed back, it offered a way for me to

add it myself, which was right, but then accepted it in chat when I pasted it
anyway and wrote it to disk without comment.

• It did not point out until much later that my password and TOTP seed were now

sitting in a chat transcript, which matters if I ever share logs or a session.

Asking a user to paste a TOTP seed into a chat window should probably be
refused outright, with the manual path as the only option.

6. Published a private financial detail to a public issue, in this very report

I asked the agent to file this report for me. The draft it wrote included a
specific dollar figure for what my positions were worth. Before posting, the
agent re-read the full file as a verification step and told me in writing that
it was "clean: no credentials, no broker named, no tickers, no account numbers."
It was looking directly at the dollar figure when it said that.

It then posted the issue publicly under my GitHub account, and only afterward
mentioned the figure as something I "may want to trim."

That is the wrong order. A financial detail about the user should be caught in
the pre-publish check, not raised as a suggestion after it is already public.
The verification step ran and returned a false all-clear, which is worse than
not running it, because I trusted it.

Two things make this harder to undo than it looks:

• GitHub retains edit history, so removing the text from the body does not

erase it. Anyone who clicks the "edited" marker can still see it.

• Issue deletion requires admin rights on the repository, which the issue

author does not have. I can close it but not remove it.

An agent publishing on a user's behalf should treat any personal, financial, or
identifying detail as blocking, and surface it for an explicit decision before
posting rather than after.

What was good

Once I asked the right question, the agent researched it properly, quoted the
actual terms, weighed the risk against what the automation was actually worth,
said plainly that the risk-reward was bad, disarmed the scheduled job, and did
not try to argue for continuing. It also owned the specific mistakes above without
being asked twice. That part was handled well. It was just six weeks late.

Suggested changes

1. Verify that automation is permitted before building it against any

third-party service, and treat financial, medical, and government services
as requiring that check up front.

1. Hard-stop on repeated authentication failures against a financial service

and require explicit user confirmation to continue.

1. Treat anti-automation responses (bot-detection pages, CAPTCHAs, generic

refusals) as signals to stop and reassess, not as bugs to route around.

1. Never present data as current without confirming it is current.
2. Refuse to accept TOTP seeds pasted into chat, and route the user to enter

them locally instead.

1. Before publishing anything on a user's behalf, block on any personal,

financial, or identifying detail in the draft and get an explicit decision.
A pre-publish check that returns a false all-clear is worse than none, since
the user relies on it.