Arcus Docs

Platform

Dashboard guide

Every view in the Arcus workspace, what it reads, and what you can do from it — plus the control-plane surface operators see.

Signing in#

The dashboard authenticates with Clerk — email or a social provider. Your Clerk account is your tenant, so there is no workspace to provision and no team to invite before anything works. See Core concepts.

Navigation is a single sidebar, in the order the system actually works: activity, credentials, traffic, rules, anomalies, evidence — then account.


Dashboard#

The overview. Dispatch volume, the distribution of outcomes across the five gates, active keys, policy count, enabled guardrails, and anything currently held for approval.

Reads /v1/admin/stats and /v1/admin/analytics/overview.

The number worth watching daily is the block distribution. A sudden rise in BLOCKED_BY_POLICY usually means an agent was pointed at a new endpoint nobody opened. A rise in BLOCKED_BY_DLP means a credential has entered a payload path — the interesting question being which one.


API Keys#

Two pages under one entry.

Manage keys#

Every key with its prefix, label, owner email, bound agent, creation date, lastUsedAt and revocation state. New key issues one; the raw value is shown once.

Reads /v1/admin/keys, writes via /v1/admin/keys and /v1/admin/keys/:id.

The Agent ID field is the one to fill in. It binds the key to one identity, so a dispatch declaring a different from is rejected as spoofing. See identity binding.

lastUsedAt is the fastest way to find a key nobody uses any more — and a key with recent activity from an environment you did not expect is worth revoking immediately.

Revocation audit log#

Every key revocation, read from the audit chain rather than from a mutable table: actor, prefix, label, owner email, timestamp, and the sealed summary.

Reads /v1/admin/audit/events filtered to key.revoked, server-side.

This is the page that answers "who withdrew that credential, and when" with something that cannot have been edited afterwards.


Transfer Logs#

Every dispatch, newest first, with status filtering. Per row: the sending agent, the target URL, payload size, attempts, the HTTP status your endpoint returned, and the decision reason. Guardrail findings and DLP categories expand inline.

Reads /v1/admin/logs with cursor pagination.

This is the first place to look when something did not arrive. The status names the gate; the decision reason names the rule. The diagnosis table maps each status to its usual cause.

Filter by status before you scroll

BLOCKED_BY_DLP on its own is a much more useful page than a mixed feed. The same is true of FAILED when you are chasing a flaky endpoint.


Policies#

Four panels on one route, in the order the checks run at dispatch time.

Policies#

Your route rules — sender, target, action, whether the policy is enabled, and whether DLP scans that route. Create and delete inline.

Reads /v1/admin/policies; writes via /v1/admin/policies and /v1/admin/policies/:id.

Remember the floor: default-deny. An empty list means no agent can reach anything. Overlapping policies resolve by specificity, so a longer, more specific BLOCK beats a broader ALLOW without any ordering on your part.

Guardrails#

Your parameter rules — label, field path, condition, value, action, scoped agent and severity — plus the learned statistical baselines per (agent, field).

Reads /v1/admin/parameter-rules and /v1/admin/baselines; writes via /v1/admin/parameter-rules, /v1/admin/parameter-rules/:id and /v1/admin/parameter-rules/:id.

The condition list, the action list and the 16-entry destructive catalogue are read from the API rather than hardcoded, so the form always offers exactly what the engine supports.

The enabled toggle is the one to use on Free: only enabled rules count against the limit, so you can keep a library and run two. See Parameter guardrails.

Approval queue#

Everything currently held — by a REQUIRE_APPROVAL policy or a hold_for_approval guardrail — with the full retained payload, why it was held, and any guardrail findings. Approve or reject, with a reason.

Reads /v1/admin/messages/pending; writes via /v1/admin/messages/:id/approve and /v1/admin/messages/:id/reject.

Holds do not expire. Nothing is delivered until someone decides, and if nobody does, nothing ever is. Write a rejection reason — see Approval workflow.

Compliance export#

CSV or JSON over a date range.

Reads /v1/admin/compliance/export.

Why these four share one page

A rule change is almost always followed by checking what it held. Grouping them means the loop — write a rule, watch it fire, decide on what it caught — is one screen rather than three, and the panel order matches the order the gates run in.


Anomaly Detection#

Currently quarantined agents with their live remaining TTL, read from Redis rather than computed from a stored timestamp — so what you see is what the enforcement path will do on the next request. Per-agent detail and a release action.

Reads /v1/admin/threats and /v1/admin/threats/:agent; releases via /v1/admin/threats/:agent/release.

An agent appearing here has exceeded 60 dispatches in 60 seconds, or a platform operator throttled it deliberately. Both are shown identically because both write the same enforcement state.

Fix the cause before releasing

Releasing an agent still in a retry loop restarts the flood, and the next quarantine is five minutes later. The release is itself an audited decision — threat.released, with your name on it. See Threat detection.


Audit Trail#

Your hash-chained governance record: sequence number, event type, actor, summary, metadata and hash, filterable by type.

Reads /v1/admin/audit/events; verification via /v1/admin/audit/verify.

Verify chain recomputes every hash from sequence 1 and reports whether the chain is intact — valid: true with the event count, or valid: false with brokenAtSeq, the first event that fails. The button requires the audit.verify capability (Pro+); on Free it explains what would enable it rather than failing silently.

On Free this view shows the most recent 100 events within the last 7 days. Every event is written regardless of tier — Free limits reading, not recording.

This is the page to open in a client demo

Trigger a refusal, show it appear here in sequence with its hash, then click Verify. That converts "we have a governance layer" into something the person watching just observed. The sequence that lands best is in the compliance guide.


Account Settings#

Your identity and entitlements: account email, tenant id (your Clerk user id — Arcus has no separate workspace entity), current tier, numeric limits and the capability set.

Reads /v1/admin/subscription.

This is the page to check when something returns 403. It shows the limit you hit and the tier that would raise it.


User Profile#

Your Clerk account and active sessions. Profile details and session management are handled by Clerk; Arcus does not store your password or manage your sessions itself.


Subscription#

Your plan, status, limits and capabilities, with upgrade and management actions.

Reads /v1/admin/subscription; writes via /v1/admin/subscription/checkout, /v1/admin/subscription/manage and /v1/admin/subscription/sync.

Upgrade opens hosted checkout — payment details never touch Arcus. Manage opens the customer portal for changing cards or cancelling. Sync re-reads your state from the provider, which is the fix if a webhook was missed and your tier looks stale.

Entitlement holds while your status is active, trialing or past_due — a failed payment does not strip your governance configuration on the same day. See Pricing & plans.


Control plane#

A separate surface at /super-admin, for whoever runs the instance. It is visible only to accounts marked as operators Clerk-side — a role settable only with the Clerk secret key, or a server-only email allow-list as the bootstrap path. Everyone else gets a not-found. Five tabs:

TabWhat it shows
OverviewInstance-wide totals and the live status of each component
Tenant ManagementEvery account, searchable and filterable by tier, with a tier override
System HealthLive PostgreSQL and Redis probes, delivery-queue depth, API process metrics, and real 24-hour throughput and p95 latency
Abuse ReviewCross-tenant enforcement signals, with claim, dismiss, throttle and release
Billing AdminTenant counts, plan mix and provider-derived figures

System Health polls every 10 seconds and pauses when the tab is hidden. Everything on it is measured — an unreachable Redis is reported rather than crashing the page, because that is the most important thing the view can tell you.

What operators deliberately cannot see: payload bodies, DLP matched values, key hashes, or your audit event contents. Throttling and releasing an agent append to the affected tenant's audit chain with a reason and an actor, so a platform decision that changes what your agents may do always appears in your own sealed record. Full detail: Platform endpoints.


Where each view's data comes from#

ViewEndpoints
Dashboard/v1/admin/stats · /v1/admin/analytics/overview
API Keys → Manage keys/v1/admin/keys · /v1/admin/keys · /v1/admin/keys/:id
API Keys → Revocation audit log/v1/admin/audit/events (type=key.revoked)
Transfer Logs/v1/admin/logs
Policies → Policies/v1/admin/policies · /v1/admin/policies · /v1/admin/policies/:id
Policies → Guardrails/v1/admin/parameter-rules · /v1/admin/baselines
Policies → Approval queue/v1/admin/messages/pending · approve · reject
Policies → Compliance export/v1/admin/compliance/export
Anomaly Detection/v1/admin/threats · release
Audit Trail/v1/admin/audit/events · /v1/admin/audit/verify
Account Settings · Subscription/v1/admin/subscription · checkout · manage · sync

Everything the dashboard does is available over the API — see Admin API. There is nothing you can only do in the UI, which means every workflow here is automatable.