One auditable policy that emits protection for static sites, Node/Express, Next.js and Cloudflare Workers. AI crawler governance, request validation, security headers, rate limits and injection detection — with identical verdicts across every runtime.
Runs locally · never mutates production · no DNS or secrets · reproducible verdicts
Every request gets one explicit action and a stable machine-readable reason code. Not a black-box score — you can inspect why, reproduce it, and roll it back.
Each one can be toggled, tested and rolled back on its own.
Method, path, body size, content-type and host validation
CSP, HSTS, frame, MIME, referrer and permissions policies
CSRF, origin checks, login throttling and generic failure responses
IP/key rate limits, burst control, route budgets and evidence-safe logging
Named crawler policy, sensitive-route denial, training vs search distinction, robots/llms guidance
Traversal, SQLi, XSS, command-injection and prompt-injection signals
Lockfile/dependency audit commands and secret-safe configuration
Most anti-bot tools block the AI search crawlers that actually send you traffic. TJ Sentinel separates training crawls from search indexing — the policy is explicit and reversible.
openEverything passes. For content sites that want maximum AI citation.
search-onlyAllow search indexing, deny training crawls. When you want the traffic but not the training set.
verified-onlyOnly named crawlers from verifiable sources; spoofed user agents fall back to ordinary traffic rules.
closedDeny all, still with explicit reason codes so you can reopen later.
A WAF runs at your infrastructure edge with vendor rule sets you cannot reproduce. TJ Sentinel is a policy file you own: it generates runtime-specific protection locally, and the same request yields the same verdict and reason code across all four runtimes — so it can live in version control, be code-reviewed and rolled back.
Not by default. The AI posture defaults to search-only: search indexing crawlers that send you traffic are allowed, and only training crawls are denied. You explicitly choose among open, search-only, verified-only and closed, and can change it at any time.
Static sites (_headers), Node/Express middleware, Next.js middleware, Cloudflare Workers/Pages, plus Nginx include and robots.txt / llms.txt generation. All adapters return identical verdicts on the same fixture set.
No. Policy generation and attack simulation run entirely locally; production deployment, DNS changes and credential handling stay outside the generator and remain yours to execute. The recommended flow is to install into an isolated copy of the site and run the bundled verification probes before going live.
Every block carries a stable machine-readable reason code (for example sqli.union_select) plus a correlation ID. The public response stays generic while detailed, redacted evidence remains local — so you can debug without leaking rule details to attackers.
Pick your stack, pick an AI posture, generate the bundle, simulate legitimate and hostile requests, then verify in an isolated copy. None of it touches production.