Platform
Pricing & plans
Three plans. All five enforcement gates run on every request on every one of them, including free. Paid tiers buy more keys, more rules, deeper visibility and reporting — never the protection itself.
The commercial position, stated plainly#
Security is not a paid feature.
Policy enforcement, DLP scanning, parameter guardrails, threat quarantine and the tamper-evident audit chain run on every request, on every plan, including free. There is no tier at which Arcus stops checking payloads, no tier at which the default-deny floor is relaxed, and no tier at which decisions go unrecorded.
A product that puts the actual security behind an enterprise tier is selling you the absence of a vulnerability it chose to leave open. What Arcus charges for is scale, configurability, visibility and reporting.
The three plans#
Free
$0 — all five gates, 2 keys, 2 guardrail rules, 7 days of readable audit history. For a first agent, a prototype, or evaluating whether the enforcement model fits.
Pro
$10/month — 10 keys, unlimited guardrails, custom policies, DLP match paths, statistical baselines, chain verification and full audit history. The working plan for a real deployment.
Max
$30/month — 50 keys, everything in Pro, plus the anomaly surface and period compliance reports. For fleets and for teams who have to produce evidence on a schedule.
Prices shown are the standard published rates
Billing is handled by a payment provider, and the authoritative price for your account is the one shown at checkout and in your customer portal. If those differ from the figures here — a promotional rate, a currency conversion, an annual arrangement — the provider's figure is the one that applies.
What runs on every plan#
Do not skim this table. It is the point of the product.
| Free | Pro | Max | |
|---|---|---|---|
| Threat detection & quarantine (gate 1) | Yes | Yes | Yes |
| Identity binding (gate 2) | Yes | Yes | Yes |
| Default-deny policy enforcement (gate 3) | Yes | Yes | Yes |
| DLP payload scanning, 7 categories (gate 4) | Yes | Yes | Yes |
| Parameter guardrails (gate 5) | Yes | Yes | Yes |
| Destructive-operation catalogue, 16 patterns | Yes | Yes | Yes |
| Approval holds and human review | Yes | Yes | Yes |
| Audit events written and hash-sealed | Yes | Yes | Yes |
| Transfer logs, full history | Yes | Yes | Yes |
| Asynchronous delivery with retries | Yes | Yes | Yes |
An account on Free has the same enforcement posture as an account on Max. The refusals are identical, the audit chain is written identically, and the gates run in the same order.
What the tiers change#
Numeric limits#
| Free | Pro | Max | |
|---|---|---|---|
| Active API keys | 2 | 10 | 50 |
| Enabled guardrail rules | 2 | Unlimited | Unlimited |
Both count only what is active. Revoked keys do not consume a slot, so rotating never requires going below your limit first. Disabled guardrails do not count either — on Free you can maintain a library of five rules and run two.
Exceeding a limit returns 403 with everything you need to act on:
{
"error": "Free accounts can keep 2 parameter rules enabled",
"code": "PARAMETER_RULE_LIMIT_REACHED",
"tier": "free", "limit": 2, "activeRules": 2,
"upgradeAvailable": true, "requiredTier": "pro"
}Capabilities#
Eight named permissions. They gate control and visibility, never enforcement.
| Capability | What it unlocks | Free | Pro | Max |
|---|---|---|---|---|
identity.advanced | Advanced identity binding controls | — | Yes | Yes |
audit.full | Audit history beyond 100 rows / 7 days | — | Yes | Yes |
audit.verify | Chain verification endpoint and button | — | Yes | Yes |
policy.custom | Authoring your own policy rules | — | Yes | Yes |
dlp.configure | DLP match paths in refusals; per-route DLP control | — | Yes | Yes |
guardrails.baseline | Statistical baselines per (agent, field) | — | Yes | Yes |
anomaly | The anomaly surface | — | — | Yes |
reports | Period compliance reports | — | — | Yes |
Free has none of these and still gets all five gates. Every capability is about seeing further into the enforcement or configuring it more finely.
Audit history#
| Free | Pro / Max | |
|---|---|---|
| Events written and sealed | All | All |
| Events readable | Most recent 100 | Full history |
| Window readable | Last 7 days | Full history |
| Chain verification | — | Yes |
| Export (CSV / JSON) | Yes, within the window | Yes, full range |
The distinction that matters: every event is written on every plan. The chain is complete and the hashes are computed regardless of tier. Free limits how far back you can read, so upgrading reveals history that was recorded all along — it does not begin recording.
On Free, export on a schedule from day one
The 7-day read window is the constraint, not the record. If compliance evidence matters and you are on Free, run /v1/admin/compliance/export weekly and archive it — otherwise the events exist but roll out of your reach. See Compliance reporting.
What is actually enforced#
Worth being precise about, because plan pages elsewhere in the industry are not.
Hard limits — enforced, and they return 403:
- Active API keys: 2 / 10 / 50
- Enabled guardrail rules: 2 / unlimited / unlimited
- Capability-gated endpoints: verification, reports, baselines, DLP paths
Advisory figures — not enforced anywhere:
Indicative monthly request volumes per tier (in the region of 10,000 on Free, 250,000 on Pro, 2,000,000 on Max) describe the scale each plan is sized for. No endpoint rejects a request for exceeding a monthly count, nothing meters you toward a cutoff, and no dispatch has ever been refused for this reason. They are capacity guidance, not quotas.
Why say this out loud
Because you will otherwise plan around a cap that does not exist, or fear one that will not fire. The only rate limit Arcus enforces is the per-agent dispatch limit — 60 dispatches per 60 seconds, identical on every plan, and it is a safety mechanism rather than a billing one. See Threat detection.
Entitlement and payment status#
Your capabilities hold while your subscription status is active, trialing or past_due.
A failed payment does not immediately strip your governance configuration. A card expiring should not silently disable your audit verification and shrink your guardrail set on the same day — that turns a billing problem into a security incident. You keep entitlement through the retry window while the provider attempts collection.
Read your current state:
curl -sS "$ARCUS_URL/v1/admin/subscription" \
-H "Authorization: Bearer <clerk-session-token>"{
"tier": "pro",
"status": "active",
"limits": { "keys": 10, "parameterRules": null },
"capabilities": ["identity.advanced", "audit.full", "audit.verify",
"policy.custom", "dlp.configure", "guardrails.baseline"]
}parameterRules: null means unlimited.
Upgrading#
From the dashboard: Subscription → Upgrade. Or via the API:
curl -sS -X POST "$ARCUS_URL/v1/admin/subscription/checkout" \
-H "Authorization: Bearer <clerk-session-token>" \
-H "Content-Type: application/json" \
-d '{ "email": "billing@yourcompany.com",
"successUrl": "https://yourcompany.com/arcus/upgraded",
"tier": "pro" }'Returns a hosted checkout URL. Payment details never touch Arcus.
Capabilities apply as soon as the subscription is active. If a webhook was missed and your tier looks stale:
curl -sS -X POST "$ARCUS_URL/v1/admin/subscription/sync" \
-H "Authorization: Bearer <clerk-session-token>"Manage payment details or cancel:
curl -sS -X POST "$ARCUS_URL/v1/admin/subscription/manage" \
-H "Authorization: Bearer <clerk-session-token>"Both a tier change and a manual override append subscription.changed to your audit chain.
Downgrading#
Your enforcement does not stop. What happens is that limits reassert:
- Keys over the new limit keep working; you cannot create new ones until you are under it. Nothing is revoked automatically — Arcus will not silently break a running agent.
- Guardrail rules over the new limit stay defined. Disable down to the limit yourself; until then you cannot enable another.
- Capabilities are withdrawn — verification, baselines and reports stop being available.
- Audit history returns to the 100-row / 7-day read window. The events remain written and sealed; you simply cannot read past the window until you upgrade again.
Export before you downgrade
The events are not deleted, but they become unreadable beyond the window. One /v1/admin/compliance/export over your full range, archived, costs nothing and preserves the record you already paid to accumulate.
Choosing#
Free is right for one agent, a prototype, or a security review of the enforcement model itself. Two keys and two rules is enough to prove the gateway does what it claims. Its real constraint is the 7-day audit read window.
Pro is right for a production deployment. The three things that make the difference in practice are unlimited guardrails (so rules are shaped by your risk rather than your plan), full audit history with verification (so the chain is evidence rather than a recent log), and DLP match paths (so a refusal tells you where the credential entered).
Max is right for a fleet — the key count is the visible reason, the anomaly surface and period reports are the real ones. If someone asks you quarterly to demonstrate that agent governance held, reports is that artefact.
Common questions#
Does a free account get worse security? No. Same five gates, same order, same refusals, same sealed chain. The difference is how many keys and rules you may have, and how far back you can read.
Are payload contents ever stored? No, on any plan — only payloadSize. The one exception is a dispatch held for approval, retained until decided, because approving what you cannot see is not review.
What happens at a limit? A 403 naming the limit, your tier and the tier that raises it. Existing resources keep working; you cannot add more.
Is there a per-request charge? No. Plans are flat monthly, and the advisory volume figures are not metered.
Can an operator see my data? No payload bodies, no DLP matched values, no key hashes. They can impose or lift a quarantine and change a tier — and every one of those actions appears in your sealed audit chain with a reason and an actor. See Platform endpoints.
What if I self-host? Tier limits are enforced in the application, so a self-hosted instance still honours them — but you control SUPER_ADMIN_EMAILS and the tier-override endpoint, which means you can provision your own accounts at any tier. See Running Arcus.