> ## Documentation Index
> Fetch the complete documentation index at: https://docs.botshield.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Introduction
> BotShield is a deployable verification layer that confirms whether a real human is present at the moment a sensitive action occurs — such as checkout, account creation, ticket purchase, or credential recovery.
It is designed to integrate with existing security, fraud, and risk systems — not replace them.
BotShield can be invoked when automated defenses are uncertain, when risk thresholds are exceeded, or when the value of an action justifies direct human verification.
## What is BotShield?
BotShield attests **one truth**: whether a human is present for a specific action.
Verification is:
* **Action-scoped** — tied only to the specific operation being performed or enforced
* **On-demand** — invoked only when and where the platform desires verification
* **Non-replayable**— attestations expire after use or TTL
* **Hardware-backed** — secured by OS-level device authentication
* **Privacy-preserving** — no identity collection or behavioral tracking
BotShield produces a cryptographically verifiable attestation that platforms can consume alongside existing signals to allow, deny, or escalate the action.
It functions as a definitive human confirmation layer within a broader security stack.
**BotShield attests. Platforms enforce.**
**Anonymous by construction.** Census Anonymous Human Attestation performs one operation: anonymous human attestation — one operation, no modes. No email, no user identifier, and no identity-bearing token ever crosses the partner boundary. You learn *that a human is present*, never *who they are*. You correlate results to your own system by the `request_id` and `metadata` you supply.
## The Three Result States
Every Census verification resolves to one of three partner-facing result states. These are the complete partner-facing output — there is no score, no confidence value, and no separate identity field.
| Result state | Meaning |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Human Verified** | A verified human is present at this moment. |
| **MultiPass Active** | A verified human who also holds an active BotShield MultiPass credential — a richer positive state. You may route these users through reduced friction at your discretion. |
| **Human Unavailable** | BotShield cannot return a verified-human result for this user right now. The cause (failed presence vs. infrastructure) is never exposed across the boundary. Apply your own policy. |
The result state is the verdict and the MultiPass signal combined — there is no separate MultiPass boolean.
## **How BotShield Fits in a Security Stack**
It is typically deployed as:
* **Step-up verification** when automated defenses flag uncertainty
* **A final checkpoint** before high-value actions are approved
* **A low-friction alternative** to challenge-based verification
* **An independent human confirmation signal** for risk engines
BotShield operates alongside existing protections and does not require removal of CAPTCHA, device fingerprinting, behavioral analysis, or fraud detection systems.
## Availability
BotShield is available as a private SDK for qualified partners.\
\
Access is provided through a developer onboarding process. Approved integrations receive API credentials, implementation guidance, and deployment support.
BotShield is not distributed as a public self-service download.
➡️ To begin integration, request developer access through the **BotShield Pilot Program**.
BotShield is for security-sensitive infrastructure, controlled distribution is required. Access to the SDK is provisioned only to approved partners.
## Key Features
Each verification resolves to one of three result states — Human Verified, MultiPass Active, or Human Unavailable — that your server acts on
Verification is scoped to the specific action or security flow
Requires device passcode security at minimum for valid attestations
Verifies human presence without identity, data collection, or persistent tracking
## How It Works
BotShield integrates into your platform's critical actions via a REST API:
1. **Your server creates a session** using your API key
2. **Your server creates a verification link** for the user's action (carrying your own `scope` and `metadata`)
3. **The user opens BotShield** via deep link, web URL, or QR code
4. **BotShield verifies presence** using device biometrics (Passcode / Face ID / Touch ID)
5. **The result is delivered to your server** via a Svix-signed webhook (or polling). The payload is anonymous — it carries only `{ type, event_id, request_id, , [reason], product, metadata }`, where `event_id` is the same `req_…` value as `request_id` and `type` is one of `census.human_verified` / `census.multipass_active` / `census.human_unavailable`. No identity, no `auth_mode`, no user token.
6. **Your server acts on the result**, correlating by the `request_id` you created, and applies its own policy
A synchronous, **PII-free** `verification_token` is also available (returned on the `return_url` as `?token=` or in the SDK response). Its claims are only `{ request_id, verified, organization_id, timestamp, nonce }` — there is no email, user id, or device data in it.
## Use Cases
BotShield is ideal for:
* **Limited-access drops** -- Ensure fair access for real customers
* **Ticket purchasing** -- Prevent bot corruption of ticket sales
* **High-value actions** -- Protect critical transactions
* **Account recovery** -- Verify presence during sensitive operations
* **Digital agreement execution** -- Confirm human presence for consent
* **Public posting actions** -- Reduce spam and abuse
## Next Steps
Integrate BotShield in minutes using the REST API
Apply for API credentials to start integrating