Limitations
Arclasp is a public beta. This page states the current boundaries so you can decide whether the product fits your workload before integration. Questions about product fit: hello@arclasp.com Security reports: security@arclasp.comHosted backend is required
The current product uses a hosted backend as the governance authority. Mature customer self-hosting is not a supported public product path today. Every governedrecord_agent_action() needs backend authority. If the backend is unavailable, the SDK fails closed rather than silently allowing the protected action.
Backend round-trip is part of governed latency
Current governed actions require a network round-trip to Arclasp. There is no supported local fast path that can authoritatively allow consequential work while the backend is unavailable. Do not assume a fixed latency SLA from the public beta. Measure the effect in your own workload.Python only
The public SDK is Python 3.10+. There are no mature customer-ready JavaScript/TypeScript, Java, Go, or other language SDKs today.Framework integration ranges
Current package constraints are:
The CrewAI optional dependency is installed only on Python versions below 3.14.
The framework-agnostic
arclasp.Chain API can still be used manually around Python workflows that do not use one of these adapters.
CrewAI prevention boundary
The CrewAI adapter does not provide a universal pre-execution barrier for every task body. If a side effect must not happen before approval or allow, instrument the exact task/tool boundary manually withrecord_agent_action() before the side effect.
See CrewAI.
MCP is not universal result capture
The MCP adapter governs the invocation before forwarding to the customer handler. It does not persist every arbitrary tool return value or execution exception as universal action evidence.Arclasp only governs instrumented boundaries
Arclasp cannot see, stop, or prove arbitrary customer-side activity that never crosses an Arclasp governance boundary. The customer application still executes its own tools. This means Arclasp is not a runtime sandbox.Kill switch scope
The organization kill switch denies governed Arclasp requests for that organization. It does not remotely terminate arbitrary customer processes or code that bypasses Arclasp. See Kill switch.Cost is an estimate, not provider billing
Arclasp governs recorded LLM token-cost estimates. It is not connected to your provider’s billing system as an authoritative spend cap. Unknown/unpriceable cost is not silently fabricated as$0.
Policy authoring is not a mature general DSL
The current dashboard supports policy records and modes such asenforce, shadow, and disabled.
It does not expose a mature arbitrary rule builder, JSON matching DSL, or general predicate engine for customers.
No first-class Tool Catalog
Arclasp records action/tool names, but there is no mature first-class customer Tool Catalog that generically rejects unknown or disabled tools.Enterprise identity and authorization are limited
The current product has organization roles and Clerk-backed authentication. Do not treat it as mature enterprise SSO, SCIM, custom RBAC, or fine-grained per-resource ACL infrastructure.Billing is not mature
The current product does not have a mature customer billing system. Do not describe budget governance as Arclasp billing.Retention / deletion / export controls are not fully productized
Evidence export surfaces exist, including structured/document outputs where available. But retention, bulk export, deletion, and compliance-oriented lifecycle controls are not yet a mature configurable enterprise product surface. Do not promise indefinite retention, specific future paid retention periods, or “existing data will never be downgraded” unless those commitments are formally adopted.No maximum-scale guarantee
Arclasp has substantial automated test coverage and concurrency testing for specific scenarios. That is not a maximum production-capacity benchmark. The public beta does not make a guaranteed events-per-minute capacity claim or SLA.Verification is evidence verification
Receipts and approval evidence are designed to be tamper-evident and verifiable through supported Arclasp surfaces. They do not automatically establish:- legal admissibility;
- legal non-repudiation;
- regulatory compliance;
- that an uninstrumented real-world action happened exactly as described;
- exactly-once execution of customer tools.
Historical receipt differences
Historical and current receipts can expose different verification layers because the receipt architecture evolved over time. Use the verification result for the specific artifact rather than assuming every receipt has identical modern cryptographic material.Authentication providers
Arclasp uses Clerk for dashboard authentication. Do not assume that every provider Clerk can support as a product is automatically enabled in the Arclasp tenant. The sign-in UI for the current deployment is the source of truth for enabled methods.Approval notifications
Email notification is supported through the current approval service. Do not assume Slack, Teams, PagerDuty, SMS, push, or arbitrary webhook approval routing exists unless a current product surface explicitly exposes it.What Arclasp is not
Arclasp is not:- a tool executor;
- a sandbox;
- a vulnerability scanner;
- an LLM provider;
- a replacement for IAM;
- a replacement for code review;
- a universal observability platform;
- a compliance certification product.
Good fit
Arclasp is strongest when:- multiple governed actions accumulate workflow risk;
- actions can spend money or change production state;
- agents communicate externally;
- a human approval boundary is useful;
- you need durable governance evidence around consequential work.
Poor fit
Arclasp is a poor fit today when you require:- passive logging only;
- fail-open execution when governance is unavailable;
- non-Python SDKs;
- mature self-hosting;
- mature enterprise SSO/custom RBAC;
- guaranteed maximum-scale benchmarks;
- a first-class Tool Catalog;
- universal tool-result capture.