> ## Documentation Index > Fetch the complete documentation index at: https://docs.arclasp.com/llms.txt > Use this file to discover all available pages before exploring further. # Policies > How Arclasp decides what to allow, flag, or block # Policies A policy is a rule that maps an agent action to a decision. Arclasp ships with default policies that cover common harm categories out of the box, and lets you add custom policies for organization-specific rules. ## The four decision outcomes Every action goes through policy evaluation and gets one of four outcomes: | Decision | What happens in your code | Dashboard visible | | ------------------ | ------------------------------------------------------------------------------------ | -------------------------- | | `allow` | The action proceeds. `record_agent_action` returns normally. | No | | `allow_with_flag` | The action proceeds. A flag is attached to the event for review. | Yes — flagged in dashboard | | `require_approval` | The action is paused. An email is sent. The call blocks until the approver responds. | Yes — pending approvals | | `deny` | The action is blocked. `ActionDeniedError` is raised in your code. | Yes — denied events | The decision arrives as a `PolicyDecision` object when `require_approval` resolves or as an `ActionDeniedError` exception when an action is denied. ## Three-stage evaluation Every action runs through a three-stage pipeline before a decision is returned: **Stage 1 — Risk classification.** The action is scored 0-100 based on what it does, what's in the payload, and which agent is running it. Categories like `financial`, `destructive`, `communication`, `exfiltration`, `privilege_escalation`, `credential_exposure` are assigned where they apply. **Stage 2 — Chain context update.** Running totals for the chain are updated with this action's contribution: financial amounts, external communications, records modified, etc. **Stage 3 — Policy application.** Rules are evaluated in priority order: hard denies first, approval triggers second, audit flags third, default allow last. The first matching rule wins. A reference implementation of this algorithm is published in [`arclasp/policies.py`](https://github.com/TOAAiV/proofrail/blob/main/arclasp/policies.py) for you to read and audit — but it is not what makes the actual decision. The backend is the sole authority for governed actions; the SDK submits the event and enforces whatever decision comes back. ## Default policies These ship with Arclasp and cover the categories most agent workflows need to be careful about. You don't have to configure them — they're active by default. ### Hard denies Actions that are blocked immediately, with no human-in-the-loop option. * **High cumulative exposure** — chain-wide financial exposure over \$50,000 * **Production deletions** — DELETE operations against production resources * **Unauthorized domains** — sending data to domains not in the allowlist * **Credential exposure** — payloads containing patterns matching API keys, passwords, credit card numbers * **IAM modifications** — changes to permissions, roles, or access control * **Impersonation attempts** — agents sending communications with a claimed identity different from their declared identity * **Restricted data access** — accessing data classified as restricted without authorization ### Approval triggers Actions that pause for human review. * **Single financial transaction over threshold** — a top-level `amount_usd`, `amount`, or `value` in the payload strictly exceeds the org's single-action threshold (default $5,000, no upper bound — above the separate $50,000 cumulative hard-deny limit, the action is denied outright instead) * **Cumulative financial threshold** — chain cumulative exposure exceeds the configured limit (default \$10,000) * **First external communication** — the first time a chain sends data outside your organization * **Bulk operations** — actions touching 100+ records * **Bulk deletions** — deleting 10+ items at once * **Irreversible actions** — contract signing, legal filings, public posts, financial commitments * **High-risk agent actions** — actions by agents you've marked as high-risk * **Out-of-scope access** — agents accessing resources outside their declared scope * **PII sent externally** — content containing detected PII going to external domains ### Audit flags Actions allowed but flagged for review. * **Production writes** — any write to production resources * **External API calls** — any call to an external service * **New agent first action** — the first time a previously unseen agent appears * **External communication content** — outgoing content to external recipients ### Auto-pause conditions Chains that hit these limits pause automatically, raising for review. * **Event count** — 1,000 events in a single chain (likely runaway behavior) * **Chain duration** — 3,600 seconds (60 minutes / 1 hour) of activity without completion, configurable per organization (`0` disables this trigger) * **Token budget** — cumulative token spend exceeds the configured budget This is a separate limit from the 24-hour default human-approval wait timeout (`default_approval_timeout_hours`) — auto-pause is about total chain runtime, not how long one approval sits pending. See [Human approval](/guides/human-approval) for the approval timeout. ## Configuring thresholds The org-wide financial threshold, domain allowlist, and high-risk-agent list are backend policy configuration, not `arclasp.init()` keyword arguments — a fresh organization gets the $5,000 single-action / $10,000 cumulative defaults with no setup required. The one threshold you *can* override from your code is the per-chain cumulative financial threshold, via `chain.add_financial_threshold()` before the chain starts: ```python theme={null} chain = arclasp.Chain("high-value-workflow") chain.add_financial_threshold(usd=2000.0) # overrides the org-wide cumulative default for this chain async with chain: ... ``` Approval workflow settings (`default_approval_timeout_hours`, `fallback_approvers`) are passed to `arclasp.init()` and do apply per SDK session. See [Configuration Reference](/reference/configuration) for the complete picture of what's client-side vs. backend-side. ## Custom policies Beyond the defaults, your organization can create a named policy record in the dashboard at `app.proofrail.dev/dashboard/policies` with a mode of `enforce`, `shadow`, or `disabled`. The dashboard does not currently expose a customer-facing rule editor, JSON matching DSL, or arbitrary predicate builder for authoring custom match conditions — policy configuration today is the mode control plus the org-wide threshold defaults described above, not free-form rule authoring. None of this is required to get your first governed, approved action working — the default single-action threshold applies to a fresh organization automatically. See the [quickstart](/quickstart). ## Policy modes: enforce, shadow, disabled Every policy (default or custom) can run in one of three modes: * **`enforce`** — Decisions are applied. This is what you usually want. * **`shadow`** — The policy evaluates normally, but the decision is logged without being applied. The SDK always returns `allow` to the agent. Useful for testing new policies against real traffic before turning them on. * **`disabled`** — The policy is skipped entirely. New custom policies default to `shadow` mode so you can calibrate before enforcement. Default policies ship in `enforce` mode. ## Where to go next Tamper-evident records of every chain. How approvals work end-to-end. Halting all agent activity in an emergency. Every threshold and parameter, explained.