Hello BAS Development Team,
Summary
Short and clear: Public documentation and blog posts from Castle indicate that, by combining device fingerprinting, behavioral signals, and headless/automation-specific signatures, they are able to detect BAS-like automation. In other words, the typical patterns produced by BAS are being noticed by Castle and are triggering risk scores.
Key points
Castle uses a multi-layered approach (risk scoring + device fingerprint + custom signals + behavioral models) to distinguish automation. This combined approach makes BAS scenarios detectable.
Their device fingerprinting doesn’t rely on cookies; it leverages inconsistencies between measurements such as canvas, WebGL, UA, timezone, and locale to differentiate devices. These kinds of inconsistencies are frequently observed in BAS environments.
Castle’s technical blog includes concrete methods for detecting headless Chrome and Puppeteer. Those methods overlap with BAS’s deterministic, repetitive interaction patterns and increase detection likelihood.
Behavioral signals (repeating event sequences, distinctive mouse/keystroke patterns, parallel high-volume sessions) are strong triggers in Castle’s models — BAS scenarios tend to generate many of these signals.
Quick reference links
Below are links you can attach; each points directly to Castle technical content:
Castle — Bot detection (docs)
https://docs.castle.io/docs/bot-detection
Overview of bot detection layers.
Castle — Device fingerprinting
https://docs.castle.io/docs/device-fingerprinting
https://castle.io/product/devices/
Device fingerprint approach and product details.
Castle blog — How to detect Headless Chrome (Puppeteer)
https://blog.castle.io/how-to-detect-headless-chrome-bots-instrumented-with-puppeteer-2/
Headless/Puppeteer detection techniques and examples.
Castle — Signals reference
https://docs.castle.io/docs/signals-reference
Behavioral/signals reference — bot_behavior, etc.
Closing and request
In short: our technical sources and observations are clear — Castle can detect the characteristic traces left by BAS-style automation. Therefore, we ask the relevant development teams to urgently take the following actions:
Prioritize and remediate the detection vectors Castle targets (fingerprint inconsistencies, deterministic behavior patterns, headless/automation signatures).
Run quick benchmarks in an authorized, controlled test environment to record which BAS actions trigger which signals.
Compile findings into a concise, itemized report for internal distribution; set a timeline for implementing fixes and re-testing.
Please treat this as a high priority.
Best regards
@tersinemuhendis Sorry for the long reply, I sent you a private message with some clarifications
@Moderator 
error, you need 1 reputation.
Hello BAS Development Team,
Summary
We’ve identified that the castle_token value becomes invalid on Twitter and other platforms when sessions are initiated through BAS.
This does not occur in normal browsers — only in automated BAS environments — suggesting fingerprint and cursor behavior mismatches.
Key Points
Castle.io’s anti-automation system flags BAS sessions due to fingerprint inconsistencies (canvas, WebGL, UA, timezone, locale) and unnatural cursor/mouse signals.
While the same actions work smoothly in a standard browser, the automated environment exposes subtle, repetitive patterns that cause Castle’s system to invalidate tokens.
This leads to login/session failures and repeated token regeneration attempts.
Request
Please prioritize fixing the fingerprint and cursor behavior inconsistencies that trigger Castle detection.
We request an urgent review and resolution of this issue to restore normal operation of castle_token in BAS-based sessions.
Best regards,
