> ## 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.

# Action-Scoped Enforcement

> Understanding how BotShield limits enforcement to specific actions

# Action-Scoped Enforcement

Action-scoped enforcement is a core principle of BotShield: verification and enforcement are limited to the specific action being taken, not broad surveillance across your platform. In BotShield Census the unit you attach verification to is a **scope** — a named action like `checkout.complete` or `comment.create`.

## What is Action-Scoped Enforcement?

Action-scoped enforcement means:

* **Verification happens for the action (the scope)** -- Not for the user, session, or platform broadly
* **Enforcement is limited** -- Only affects the specific action being verified
* **No cross-action tracking** -- Each action is independent
* **No persistent monitoring** -- No surveillance beyond the immediate action

## How It Works

### Traditional Approaches

Most verification systems use broad-scoped methods:

* **Session-based verification** -- Verify once, trust for entire session
* **User-based verification** -- Verify user identity, apply broadly
* **Platform-wide monitoring** -- Track behavior across all actions
* **Persistent tracking** -- Store verification state for reuse

### BotShield's Approach

BotShield scopes verification to a single action:

* **Action-specific verification** -- Verify presence for this specific action
* **Limited enforcement** -- Only this action requires verification
* **No cross-action data** -- Each verification is independent
* **No persistent state** -- Verification is consumed by the action

## Example: Checkout Flow

```bash theme={null}
# User wants to checkout -- create a verification request for the checkout scope
POST /operations/sdk/create-verification-link
{
  "scope": "checkout.complete",
  "metadata": { "order_id": "checkout-12345" }
}
# → User verifies → result delivered to your Svix webhook endpoint → checkout proceeds

# Later, same user wants to post a comment
# This requires a NEW verification -- the previous one does not carry over
POST /operations/sdk/create-verification-link
{
  "scope": "comment.create",
  "metadata": { "comment_id": "comment-67890" }
}
# → Fresh verification required
```

The verification result arrives at the HTTPS endpoint you registered in **Console → Settings → Webhooks** — it is not passed inline in the request. The payload is anonymous (no email, no user id), and you correlate it back to your order via the `request_id` and the `metadata` you supplied. See [Webhooks](/concepts/webhook-payloads).

## Benefits

<CardGroup cols={2}>
  <Card title="Privacy-First" icon="lock">
    No broad surveillance or tracking
  </Card>

  <Card title="User-Friendly" icon="smile">
    Verification only when needed
  </Card>

  <Card title="Flexible" icon="settings">
    Different actions can have different requirements
  </Card>

  <Card title="Secure" icon="shield">
    Each action gets fresh verification
  </Card>
</CardGroup>

## Selective Enforcement

You choose which actions require verification. BotShield does not require verification for every user interaction -- only the ones you designate:

* **Checkout** -- Always verify
* **Comment posting** -- Verify for new users only
* **Account recovery** -- Always verify
* **Profile update** -- Verify for sensitive changes only

This is entirely your decision. BotShield provides the verification mechanism; you decide where to apply it.

## Standard vs Elevated Scopes

Each scope you define carries an impact level that resolves to one of two verification postures:

* **Standard** -- passes when the user has either an active MultiPass credential *or* a fresh Face ID event. Best for routine actions (commenting, signing up).
* **Elevated** -- always demands a live Face ID for this action, even when the user's MultiPass is active. Best for high-impact actions (payments, withdrawals, account changes).

You configure the impact level per scope. The result a partner sees is still one of the three anonymous Census result states — **Human Verified**, **MultiPass Active**, or **Human Unavailable** (see [Human Presence](/concepts/human-presence)). The standard/elevated distinction only changes *how strictly* a given scope is checked, never what identity information you receive (none).

## Comparison

| Approach                      | Scope                | Privacy  | Flexibility |
| ----------------------------- | -------------------- | -------- | ----------- |
| Session-Based                 | Entire session       | Low      | Low         |
| User-Based                    | All user actions     | Low      | Low         |
| Platform-Wide                 | All platform actions | Very Low | Low         |
| **Action-Scoped (BotShield)** | **Single action**    | **High** | **High**    |

## Privacy Implications

Action-scoped enforcement provides:

* **No surveillance** -- No monitoring beyond the action
* **No tracking** -- No cross-action data collection
* **No profiling** -- No user behavior analysis
* **No persistence** -- No stored verification state

## Related Concepts

* [Human Presence](/concepts/human-presence) -- What BotShield verifies and the three Census result states
* [Webhooks](/concepts/webhook-payloads) -- How anonymous results reach your server
* [Device Security](/concepts/device-security) -- Hardware-backed security requirements
* [SDK Overview](/sdk/overview) -- Technical API architecture