Arcane
ARCHITECTURE BRIEF

How the control plane composes.

Four ideas, stacked. Identity, policy, enforcement, and audit — each pulling its weight, each visible to operators.

The shape

One plane between agent and resource.

Identity binding, policy evaluation, and audit emission are the three things Arcane does on every call. Everything else — IdPs, registries, downstream services — Arcane integrates with, not replaces.

The four ideas

From boot to steady state.

01

Genesis

An agent boots. Your IdP issues a user session. Your registry confirms the agent. The runtime attests itself. Arcane binds the three into a composite identity — signed, expiring, not stored as a static secret.

02

Composite identity

The principal that hits policy isn't just the agent. It's user × agent × workload. Three signals, one binding. If any one shifts, the binding is invalidated; no standing trust survives a runtime change.

03

Contextual policy

Policies aren't authored from imagination. Arcane reads what your agent declares and observes its first calls in shadow mode. The drafted policy is a proposal you accept, edit, or reject. Static role bundles disappear.

04

Adaptive policy

Production traffic feeds back into the policy engine. Drift becomes a proposal, not a paging event. The longer an agent runs, the tighter Arcane's understanding of what 'normal' is — and the smaller the surface a compromised run can touch.