Field notes from 43 hours of legitimate security research, 35 false-positive blocks, and one
support form.
The setup
I do authorized bug bounty work and CTF practice. My toolchain is unremarkable by design: the
usual ProjectDiscovery/OWASP staples — subfinder, httpx, nuclei, katana, naabu, dnsx,
amass — plus ffuf, gobuster, arjun, bbot. Nothing bespoke, nothing evasive, nothing that
wouldn't show up in any security bootcamp's syllabus. I use Claude as a research and
documentation assistant alongside my OWN dev tool HALO, that I have been developing over the course of about six months(roughly). I use these toolchains, on training platforms explicitly built to be
practiced against, learned from and exercised. And I pay for the Cluade PRO plan as a means of learning and having an assistant ten times smarter than myself.
Over a 43-hour window, that combination — legitimate work plus an AI assistant with a
cybersecurity safeguard — produced 35 blocked requests. This is a writeup of what the block
pattern actually looked like, because the pattern is the interesting part. It isn't "the filter
is too strict." It's that the filter appears to be scoring the wrong thing. And by 'wrong thing' I mean even un-related normal language messages and requests.
The headline case: blocked for writing an ethics checklist
The densest cluster was ten blocks in four minutes and thirty-three seconds. The request,changed and re-phrased, also unchanged (no matter what I did),
across all ten attempts: write a markdown template for reporting bug bounty findings.
The document that eventually made it to disk — after the eleventh try succeeded — is 513 lines
across four files: a submission skeleton, a CVSS severity guide, a README, and a pre-submission
checklist. The checklist is the file that was open when block six through ten fired. Its contents:
- [ ] The asset is explicitly in scope for this program, today
- [ ] Testing stayed within the program's rules (no DoS, no social engineering,
no automated scanning if prohibited, no third-party accounts)
- [ ] I stated a concrete attacker outcome, not a capability
- [ ] I did not overclaim (no "full server compromise" for a reflected header)
- [ ] Secrets, tokens, and third-party PII are redacted
- [ ] I deleted test data, injected records, and uploaded files I created
- [ ] I did not retain third-party data
- [ ] No production users were affected
- [ ] Tone is neutral and collaborative — no demands about bounty amount
That's a responsible-disclosure ethics document. It instructs the reader to stay in scope, avoid
denial of service, redact third-party data, and delete their own test artifacts. If a classifier's
job is to catch material that increases risk, this is close to the least risky text a security
practitioner could type. It got blocked more times than anything else in the sample.
The control case that makes the point
The same account, the same day, the same client. Earlier that evening I ran a 43-minute CTF
session — 204 messages, live enumeration and credential testing against a practice box, the actual
offensive work the safeguard exists to gate.
Zero blocks.
Side by side:
CTF session (df828311) |
Report-template session (e6f361c6) |
|
|---|---|---|
| Activity | live offensive operation | writing a markdown document |
| Messages | 204 | ~12 |
| Duration | 43 minutes | ~5 minutes |
| Blocks | 0 | 10 |
Whatever the classifier is weighting, it isn't operational risk. The session where I was actually
doing the thing the safeguard is presumably designed to catch ran clean start to finish. The
session where I was documenting how to do that thing responsibly did not. And to make matters worse, writing this article you are currently reading was also blocked.
The pattern that best fits the data: block density tracks accumulated conversation context —
how much security vocabulary has built up over the session — rather than the risk content of any
single request. A stable, unchanging request (write a template) got a different verdict each of
eleven times it was submitted in the same conversation. That's not how a per-request classifier
behaves. It's how a classifier scoring cumulative context behaves.
Two failure modes that compound it
It fires on output, not just input. Several blocks truncated the assistant's own reply
mid-sentence — once while it was in the middle of advising me to keep scope notes in a local file
instead of chat. From inside the session, a mid-word cutoff is indistinguishable from a network
hiccup or a length cap. It isn't labeled as a refusal. This led the assistant, twice, to
confidently tell me the truncation wasn't censorship and to suggest I use plainer terminology —
advice that would have increased the block rate, not decreased it. The failure mode doesn't just
degrade the experience; it actively misinforms the system's own operator about what's happening.
It fires on meta-discussion of itself. I tried, deliberately, to describe the blocking problem
using zero security terminology — just "I sent a message and it got blocked." That message was
blocked too. So was a follow-up attempt to make the same point. There was, in that stretch, no
available phrasing that got a plain factual report of the bug past the filter meant to catch
security content.
Put together: a request gets silently dropped, the assistant doesn't know it was dropped, it
retries or re-explains, and each retry is itself scored against an already-elevated context
window. Support documentation for the underlying system describes an escalating filter that
tightens with repeated triggers and cools off after a quiet period. If that's accurate, the retry
behavior isn't neutral — it's the thing generating the escalation. One legitimately blocked
request can silently become ten logged violations against the account, without the user or the
assistant ever being told a block occurred.
Why this matters beyond one annoyed user
The stated purpose of a cybersecurity safeguard is presumably to reduce uplift for offensive
misuse while still serving people doing the work legitimately — pentesters, bounty hunters,
defenders, students. A classifier that blocks the ethics checklist ten times and waves through 43
minutes of live target enumeration is optimizing for something other than that goal. If anything,
the current calibration selectively suppresses the exact material — scope discipline, redaction
practices, responsible severity claims — that makes offensive-security work safer to produce,
while letting the higher-capability activity through untouched. That's the opposite of the
intended tradeoff.
There's also a plain usability cost. I pay for this specifically because the model is useful in
this domain. The current behavior means the subscription is least usable for the exact reason I
bought it.
What I filed
I compiled a full evidence document — request IDs, timestamps, session breakdowns, the control
case, verbatim excerpts of the blocked content — and re-applied to the program that governs an
exemption from this safeguard, after an earlier application had been declined.
The medium-length version of that appeal, roughly what I'd want a reviewer to actually read:
I'm a Claude Pro subscriber and an individual security researcher doing authorized bug bounty
work and CTF practice. I previously applied to the Cyber Verification Program and was declined.
I'm asking for that decision to be re-reviewed against logged request data rather than a
description of intent.Between two dates my account logged 35 blocks citing "a cybersecurity topic." All 35 request IDs
are recoverable from local session logs and verifiable server-side.The densest cluster — ten blocks in four minutes and 33 seconds — occurred while asking for a
markdown template for reporting findings professionally. Not an exploit, not a payload, not a
target: a document about stating impact honestly, avoiding overclaiming, confirming scope, and
deleting test data. Later the same evening, working a CTF box that exists solely to be practiced
against, the blocked messages included requests to name a working directory.The control case: a 43-minute capture-the-flag session, 204 messages of live work against a
practice target, produced zero blocks. The session asking for documentation guidance drew ten.
Whatever is being scored, it isn't the risk posed by the request.Rephrasing doesn't reliably help. Vocabulary was sanitized — no tool names, no site names, no
mention of the field — and blocks continued. One blocked message contained no security
terminology at all; it only described the fact of being blocked.The program's own documentation states that eligible applications are occasionally declined
incorrectly. This is offered as evidence that this account is one of those cases, and as a
request to be evaluated as what it is: legitimate work in a defensive field, using publicly
distributed tooling, on systems built to be practiced against.
That's the version sized for a standard appeal text box — long enough to carry the control case
and the request-ID anchor, short enough that a reviewer will actually finish it. A one-paragraph
version and the full 35-entry evidence log exist alongside it for forms with tighter or looser
limits.
The uncomfortable summary
None of this is an argument that the safeguard shouldn't exist. It's an argument that the current
implementation can't currently tell the difference between doing the risky thing and writing a
checklist about how not to do the risky thing badly — and that the difference matters, because one
of those outputs is the thing that makes the other one safer.
Top comments (1)
Anyone else who uses AI as an assistant, having these issues with CC?