​

Limitations

This page lists what Arclasp currently supports and where the boundaries are. It exists so you can decide upfront whether Arclasp fits your use case rather than discovering edges after integration. If any limitation here is a blocker for your work, email us and we’ll tell you honestly whether to wait for it, work around it, or pick a different tool.

​

Current version: public beta

Arclasp 0.1.x is the first public release. The product is functional and tested, but it’s a beta — expect rough edges in onboarding, occasional bugs, and gaps that we’ll close in subsequent releases. The SDK is Apache 2.0 open source. The backend and dashboard are closed source for the beta period. The backend is the sole authority for governance decisions — the SDK is a client that submits events and enforces the resulting decision; it does not decide policy locally. An earlier local-evaluation code path still exists in the SDK for compatibility but is deprecated and is not used to make current governed decisions — see Backend round-trip required for every governed action below.

​

Region

Single region: US-East. Backend is hosted in us-east-1. Users farther from that region see additional network latency on every backend round-trip — see Backend round-trip required for every governed action below. Multi-region is on the roadmap. No firm date.

​

Backend round-trip required for every governed action

Every call to record_agent_action() requires a network round-trip to the backend — there is no local decision path in the current architecture. (A deprecated enable_local_fast_path setting still exists on init() for compatibility; it has no effect on governed execution — see Configuration.) There is currently no way to reduce this by evaluating some actions locally — network and server-side processing time are both part of every governed action’s execution time. Exact latency varies with your network conditions, deployment region relative to us-east-1, and current policy evaluation load; we aren’t publishing a fixed per-action latency figure or SLA at this stage. For workflows with many sequential agent actions, this adds up — plan for it in latency-sensitive applications.

​

Backend unavailability fails closed

If the backend can’t be reached (after the SDK’s built-in retries), record_agent_action() raises BackendUnavailableError and the action does not execute. There is no local fallback that continues, allows, or buffers the action for later governance in the current architecture — offline or delegated governance is not currently supported. Design your availability expectations around this: a backend outage stops governed actions, it doesn’t quietly relax them.

​

Framework support

The 0.1 release supports four frameworks:

• LangGraph 0.2.0 - 0.3.x
• LangChain 0.2.x - 0.3.x
• CrewAI 1.10.x - 2.0.x (with the post-execution governance caveat)
• MCP Python SDK 1.0.x

Not currently supported:

• AutoGen
• LlamaIndex
• Semantic Kernel
• Browser-based agents
• Any framework not Python (JavaScript/TypeScript SDK coming after Python is stable)

For unsupported frameworks, the framework-agnostic arclasp.Chain works — you call record_agent_action manually at the points you want governed. This is more code than govern() but works with any orchestration tool.

​

Policy evaluation runs on our servers

For custom policies, evaluation happens server-side. The reference algorithm is open source in the SDK, so you can run it locally to test policy behavior, but production decisions are made on Arclasp’s backend. Self-hosted policy evaluation (and self-hosted deployment generally) is on the roadmap. The motivation is regulated industries that can’t send data to a third party for evaluation. Not yet available.

​

Approval notifications: email only

Approvals are delivered via email through Resend. We don’t yet support:

• Slack notifications
• Microsoft Teams notifications
• PagerDuty for high-priority approvals
• SMS or push notifications
• Webhooks for custom routing

For time-sensitive approvals, configure short timeouts and ensure your approvers monitor email. Slack and Teams integrations are on the roadmap.

​

Approval polling

The SDK polls for approval decisions every 5 seconds throughout the wait window. The interval is constant — there’s no tiered cadence or exponential backoff in the current version. For approvals that resolve quickly, the worst case is a 5-second delay between the human clicking and your code unblocking.

​

Time-boxed exceptions: granted yes, revoked no

When an approver approves an action, they can grant a time-boxed exception (1 hour, 1 day, 1 week, 1 month) that covers similar future actions. Exceptions auto-expire at the configured duration. What’s not exposed yet: a dashboard UI for admins to view active exceptions and revoke them early. The backend supports revocation; the UI is on the roadmap. If you need an exception revoked before it expires, email us and we can do it directly.

​

Authentication

Authentication is via Clerk. We support what Clerk supports natively:

• Email/password
• OAuth providers (Google, GitHub, Microsoft, etc.) that Clerk has built in
• Magic links

We don’t yet support:

• Custom SAML SSO
• Custom OIDC SSO
• LDAP / Active Directory
• Hardware key authentication beyond what Clerk supports

SSO is on the roadmap for enterprise deployments. For the beta, Clerk’s defaults cover most teams.

​

Budget enforcement: single mode

When newly recorded LLM token-cost estimates cross your organization’s configured monthly budget, Arclasp triggers a require_approval gate. This is currently the only enforcement mode. The spec defines three modes (deny, require_approval, flag) but the other two aren’t implemented yet. If you’d benefit from deny (hard block when budget exceeded) or flag (allow but audit), let us know — we’ll prioritize based on customer demand.

​

SDK environment variables

The SDK does not read any environment variables. All configuration must be passed to arclasp.init() as keyword arguments. If you want to keep your API key out of source code, read it from your own environment variable (e.g., os.environ["ARCLASP_API_KEY"]) and pass the value to init() yourself.

​

Chain metadata is opaque

The metadata parameter on arclasp.Chain(...) stores arbitrary data on the chain record but does not change SDK behavior. Specifically, you cannot override approvers or approval timeouts on a per-chain basis through metadata. For per-workflow approval configuration, initialize the SDK separately per workflow boundary, or use chain.add_financial_threshold() for a per-chain financial-threshold override — see Configuration.

​

Data retention

All chain events, approvals, and receipts are retained indefinitely by default during the beta. We reserve the right to introduce retention tiers for paid plans in the future (e.g., free tier keeps 90 days, paid keeps 7 years), but no current users will be downgraded — your existing data stays. We don’t currently offer:

• Configurable retention per organization
• Right-to-be-forgotten workflows for GDPR (in development)
• Data export in bulk (per-receipt JSON download is available)

If you have specific compliance retention requirements, email us and we’ll discuss what’s possible.

​

Performance limits

The beta backend is sized for early-stage usage. Specific capacity numbers will firm up as we observe real load patterns; if you anticipate sustained high-volume usage (10K+ events per minute), email us to coordinate before launching.

​

Team roles

Three roles in the dashboard:

• admin — full access, including kill switch, audit log, team management, and budget configuration
• approver — see chains and receipts, decide approvals
• developer — create API keys, view chains and receipts

We don’t currently support:

• Custom roles
• Per-policy approver routing rules
• Per-chain access restrictions

Custom roles are on the roadmap, but the three built-in roles cover most teams’ needs.

​

Versioning and compatibility

Supported framework version ranges are pinned in sdk/pyproject.toml. Install with a compatible version of your framework already present in your environment. The Python version constraint is enforced by pip at install time. For breaking changes in supported frameworks (e.g., LangChain releases a 0.4 with a different callback API), we’ll ship an updated SDK as soon as we’ve validated the integration. Until then, pin your frameworks to the supported range.

​

What Arclasp is not

A few things Arclasp is explicitly not, in case it isn’t clear:

• Not a runtime sandbox. Arclasp records and governs agent actions, but doesn’t sandbox agent execution. If an agent does something the policy didn’t anticipate, Arclasp records it but doesn’t prevent the underlying tool call from executing. For sandboxing, you need a different layer (Docker containers, restricted IAM roles, etc.) — Arclasp complements those.
• Not a vulnerability scanner. Arclasp doesn’t analyze agent prompts or LLM outputs for security issues. It governs actions, not content.
• Not an LLM provider. Arclasp observes calls to LLMs (and tracks cost), but doesn’t proxy them or make decisions about what to send.
• Not a replacement for code review. Your agent code, prompts, and tool implementations still need review. Arclasp catches problems at runtime that code review missed; it doesn’t replace the review itself.

​

When Arclasp is a good fit

Arclasp works well for:

• Multi-agent workflows where cumulative behavior matters more than individual calls
• AI products that interact with external APIs, send communications, or move money
• Teams that need an audit trail for compliance (SOC 2, internal audit, regulator inquiries)
• Workflows where some actions should pause for human approval based on dynamic conditions
• Startups that want governance from day one without building it themselves

​

When Arclasp is the wrong tool

Be honest with yourself about cases where Arclasp isn’t right:

• Single-agent, single-tool-call workflows — chain-level governance is overkill. Per-call governance (Permit.io, Cerbos) is simpler.
• Workflows that don’t move money, send communications, or modify data — the default policies don’t help much. You can still use Arclasp for audit purposes, but most teams don’t need it.
• Strictly synchronous, latency-sensitive workflows — every governed action requires a backend round-trip with no local fallback; that added latency may matter more than governance for these workflows.
• Air-gapped environments — Arclasp requires a backend connection. Self-hosted is on the roadmap; offline is not.
• Non-Python applications — until the JavaScript/TypeScript SDK ships, only Python applications can integrate.

​

How to give feedback

If something on this page is a blocker, or you want to vote on a roadmap item, the fastest path is email: hello@proofrail.dev. For security issues specifically, use security@proofrail.dev.

​

Where to go next