Skip to main content

Configuration

Arclasp configuration is split between:
  1. the Python SDK runtime;
  2. organization-side governance state in the Arclasp backend/dashboard.
The distinction matters because several SDK runtime arguments are accepted for compatibility but no longer control current backend-authoritative policy.

Minimal hosted configuration

The SDK does not automatically read ARCLASP_API_KEY; your application reads it and passes the value. Hosted Arclasp is the default backend. For local SDK/backend development, explicitly pass backend_url="http://localhost:8000".

Environment tag

environment is attached to Chain context and can be used to distinguish workloads such as production, staging, and development.

Backend timeout

If governed execution cannot obtain backend authority, the SDK fails closed. max_retries and retry_backoff_base_ms are supported transport settings. They do not make governed execution fail open; after transient retries are exhausted, backend unavailability still raises.

Approval timeout and fallback

default_approval_timeout_hours controls the SDK’s approval wait configuration. fallback_approvers participates in the approval flow. The current product does not expose a general per-Chain approver-routing DSL through Chain(metadata=...).

Financial thresholds

Single-action threshold

A fresh organization currently uses a default single-action financial approval threshold of $5,000 for supported top-level amount fields. The legacy init argument:
does not change the current backend-authoritative threshold and should not be presented as the active control.

Per-Chain cumulative threshold

Use:
This is the supported customer-facing per-Chain cumulative override. The current backend default cumulative threshold is $10,000. A separate hard-deny threshold exists above the approval boundary.

Agent risk

Use the dashboard/backend Agent Registry for enforced registered-agent risk behavior. The source-supported rule to rely on is that a registered Critical agent requires approval for governed actions. The old high_risk_agents=[...] init argument is compatibility-only for the deprecated local policy path and should not be documented as an active backend control.

External-domain configuration

The old external_domains_allowlist=[...] init argument remains in the call signature for compatibility. Do not present it as the current customer control for the backend policy’s domain behavior. The current public product does not expose a mature general rule/allowlist editor through the Python init call.

Backend unavailability always fails closed

The current public SDK does not support fail_mode or fail_modes init() keywords. There is no fail-open init() setting that authorizes governed execution when the backend is unavailable. Current behavior is:

Payload sanitization

The SDK sanitizes governed payloads before submission using field-name and value-prefix patterns plus string-length truncation. Example:
Default field-name patterns include common secret-like keys. Default value-prefix patterns include common credential prefixes, including prail_. Treat SDK sanitization as defense in depth. Do not promise that every value across every product surface can never be persisted unsanitized. Avoid sending secrets in governed payloads in the first place.

Local fast path

The current public SDK does not support an enable_local_fast_path init() keyword. The current public governance path is backend-authoritative. Do not rely on local evaluation to bypass backend latency or availability.

Offline buffer

offline_buffer_max_events remains a compatibility parameter. It does not create a supported “execute now, govern later” path. Governed execution does not silently continue when Arclasp is unavailable.

Chain metadata

Metadata is customer-provided Chain context. Do not treat arbitrary metadata keys as policy directives unless the current API explicitly defines them.

Policy records

The dashboard can create named Policy records with modes:
  • enforce
  • shadow
  • disabled
The current dashboard does not expose a mature free-form rule editor or arbitrary predicate DSL. Do not document an assumed default mode for newly created customer policy records unless the current dashboard/API source explicitly proves it.