​

Limitations

This page lists what ProofRail currently supports and where the boundaries are. It exists so you can decide upfront whether ProofRail 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

ProofRail 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 policy evaluation algorithm in the SDK is the same one that runs on the backend (parity tested), so you can read and audit the decision logic yourself.

​

Region

Single region: US-East. Backend is hosted in us-east-1. European and APAC users see ~100-150ms added latency per backend round-trip. The local fast-path mitigates this for most actions (sub-5ms locally), but actions that require backend evaluation are slower outside North America. Multi-region is on the roadmap. No firm date.

​

Backend round-trip required for most actions

The local fast-path handles obviously-safe actions (read-only operations, non-financial tool calls under thresholds) without contacting the backend. Everything else — anything that touches financial values, external communications, or approaches a chain-level threshold — requires a backend round-trip. Typical latency: 50-200ms per backend-evaluated action. For workflows with many sequential agent actions, this adds up. Plan for it in latency-sensitive applications.

​

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 proofrail.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 ProofRail’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 a chain would exceed your organization’s monthly LLM budget, ProofRail 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 proofrail.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["PROOFRAIL_API_KEY"]) and pass the value to init() yourself.

​

Chain metadata is opaque

The metadata parameter on proofrail.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, use custom policies in the dashboard that match on chain name.

​

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 ProofRail is not

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

• Not a runtime sandbox. ProofRail records and governs agent actions, but doesn’t sandbox agent execution. If an agent does something the policy didn’t anticipate, ProofRail 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.) — ProofRail complements those.
• Not a vulnerability scanner. ProofRail doesn’t analyze agent prompts or LLM outputs for security issues. It governs actions, not content.
• Not an LLM provider. ProofRail 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. ProofRail catches problems at runtime that code review missed; it doesn’t replace the review itself.

​

When ProofRail is a good fit

ProofRail 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 ProofRail is the wrong tool

Be honest with yourself about cases where ProofRail 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 ProofRail for audit purposes, but most teams don’t need it.
• Strictly synchronous, latency-sensitive workflows — 50-200ms per action latency may matter more than governance.
• Air-gapped environments — ProofRail 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. We’ll respond within 24 hours.

​

Where to go next