Notifications
Clear all
Topic starter
11/07/2026 8:37 pm
TL;DR: Web Bot Auth signs HTTP requests with cryptographic proof so website owners can verify legitimate bots, crawlers, and AI agents instead of relying on user-agent strings or IP reputation, according to Stytch. That shifts bot access from guesswork to identity, which matters because current controls often cannot distinguish trusted automation from abuse.
NHIMG editorial — based on content published by Stytch: How to implement Web Bot Auth for your AI agent, bot, or crawler (and why you should)
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams verify legitimate bots without relying on user-agent strings?
A: Use cryptographic request signing so the server can verify that the caller controls a private key associated with the bot.
Q: Why do non-human identities need lifecycle governance if they only make requests?
A: Because machine identities still accumulate risk over time through stale keys, forgotten owners, and overbroad scopes.
Q: What do organisations get wrong about bot authentication?
A: They often confuse proof of identity with permission to act.
Practitioner guidance
- Inventory all web-facing automation identities Catalog crawlers, bots, AI agents, and integration jobs that currently rely on user-agent claims, IP allowlists, or shared secrets.
- Separate authentication from authorisation decisions Use request signing to establish that a bot controls a private key, then apply endpoint-level policy, scopes, and task-specific limits before granting access to sensitive actions.
- Test signature serialization in production-like conditions Validate header quoting, authority matching, nonce uniqueness, and expiry handling against real traffic patterns.
What's in the full article
Stytch's full blog post covers the implementation detail this post intentionally leaves for the source:
- End-to-end code for generating Ed25519 key pairs and publishing a JWKS directory.
- Step-by-step request signing logic, including the signature base string and structured headers.
- Practical verification flow for servers that need to reconstruct and validate signed bot requests.
- Common serialization pitfalls that can make Web Bot Auth requests unverifiable in production.
👉 Read Stytch's guide to implementing Web Bot Auth for bots and AI agents →
Web Bot Auth for AI agents: what changes for IAM teams?
Explore further
11/07/2026 9:05 pm
Web Bot Auth is a non-human identity control, not a bot optimisation feature. The article is really about turning unauthenticated machine traffic into verifiable identity assertions. That places it squarely in NHI governance, where the challenge is not just allowing access, but deciding which automation deserves trusted access at all. Practitioners should treat request signing as an identity boundary, not a convenience layer.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why machine identity discovery remains a prerequisite for bot trust controls.
A question worth separating out:
Q: How can teams decide whether Web Bot Auth should be adopted?
A: Adopt it when you need to distinguish legitimate automation from spoofed traffic and you can support key management, replay protection, and policy enforcement. It is most useful where trusted bots must reach web endpoints reliably without weakening defences against abuse.
👉 Read our full editorial: Web Bot Auth turns bots into verifiable non-human identities
