Skip to content
Agent authorization · runtime policy · audit

Identity for the agents
that act on your behalf.

Arcane is the identity, authorization, and policy enforcement layer for AI agents. Let agents interact with real systems — APIs, SaaS, internal tools, MCP servers — without handing them unchecked access.

Guardrail · Live
policy_ver 042latency 3ms
01 · Inbound
taskreconcile-invoices-q3
actionjira.read
resourceproject: FIN-OPS
useru.olsen@acme
agentagent.pk-93f · tier 2
workloadpod.sre-prod-4 · attested
netcorp-vpn
02 · Evaluate
workload.attested
user.role == finance
action in allow_set
rate.within_limits
Matched rule
jira_finance.allow · line 14
03 · Outcome
ALLOW
Request forwarded to resource · audit entry signed
trace_idtrc_allow_7f3a…
signed_bysts.arcane · jwks#k2
auditstreamed to siem · kept 2y
24h · 14.2M evals
ALLOW92.4%
REVIEW5.1%
DENY2.5%
Deployed insideSIGILOBELISKHEXROWAEGISORYX
Composite identity
user · agent · workload
Runtime decisions
< 5ms · deterministic
Enforcement
SDK + transparent proxy
The problem

Agents are not users.
Agents are not service accounts.

A human clicks one action. A service account does one narrow job. An agent accepts an abstract task, plans steps, decides what tools to call, transforms parameters, and performs hundreds of delegated actions in a day on behalf of a single employee.

Traditional OAuth scopes and API keys tell you the ceiling of what is possible, not the safe subset of what should happen in a specific task.

Arcane adds the missing layer.
Agent behaviorLegacy auth expressesGap
Plans a series of steps across toolsOAuth scope: app.read, app.writeCannot bound a single task
Chains reads, writes, escalations in one taskBearer token says "authorized"No per-action decision point
Runs on behalf of a specific employeeService account with shared rightsDelegation is invisible
Operates at machine speed, 100s of calls/dayStatic API key, broad ceilingNo constraints on context
Executes from a specific runtimeIP allowlist at bestWorkload trust cannot be expressed
May request escalation mid-taskAll-or-nothing at issuanceNo conditional / review lane
Architecture at a glance

One policy engine. Two paths to the resource. Every action explained.

A user delegates to an agent. The agent executes on a workload. Arcane binds all three, issues a short-lived token for the task, evaluates it against policy, and enforces the decision in-line.

△ System diagram
schema v1 · last rev 26.4.18
Arcane architecture overviewA user and an agent delegate through a workload, exchange at the Security Token Service for an Arcane Token, the token is evaluated by the policy fabric, and enforcement reaches the resource via either an embedded SDK or a transparent proxy.◆ IDENTITY INPUTS◆ ARCANE CONTROL PLANE◆ ENFORCEMENT◆ RESOURCEARCANE · sts.arcane / policy.arcane01 · USERu.olsen@acmeIdP: Okta · role: finance02 · AGENTagent.pk-93fclient · trust tier 203 · WORKLOADpod.sre-prod-4attested · SPIFFE04 · STSSecurity Token ServiceRFC 8693 · compose + sign05 · ARCANE TOKENscoped · task-boundttl 15m · signed06 · POLICY FABRICevaluate()rego · cedar · abac07a · SDKMCP SDKembedded · in-proc07b · PROXYArcane Proxytransparent · inline08ToolMCP · internal08SaaSthird-partydeterministic · < 5 ms · cryptographically logged
01
User
Identity provider — Okta, Entra, Google
02
Agent
Registered software actor · trust tier
03
Workload
Attested runtime · SPIFFE / platform OIDC
04
STS
RFC 8693 exchange · composite binding
05
Arcane Token
Scoped · task-bound · ttl 15m
06
Policy fabric
Rego · Cedar · ABAC · dry-run
07
Enforcement
MCP SDK · transparent proxy
08
Resource
APIs · SaaS · internal tools · MCP
◆ Composite identity
schema v1
Composite identityThree principal rings — user, agent, and workload — overlap to form the Arcane Token at their intersection.USERPrincipalu.olsen@acmeAGENTIdentityagent.pk-93fWORKLOADAttestationpod.sre-prod-4ARCANE TOKENComposite binding∩ intersection · ttl 15m
Primitive 01 · Composite identity

Who is acting, through what agent, from what trusted environment.

A composite identity binds three independent layers into a single, verifiable authorization context — answering not just "who is asking?" but "who is asking, through what software, running where?"

User principal
The human delegating the action
u.olsen@acme · role · entitlements
issued by the IdP (Okta, Entra)
Agent identity
The logical software actor
agent.pk-93f · trust tier · version
registered client credentials
Workload principal
The runtime actually executing
pod.sre-prod-4 · attested · corp-vpn
SPIFFE SVID / platform OIDC token
The insight

Composite token scopes are the intersection of what each layer allows — not the union. All three must agree.

→ User U delegated to Agent A, executing on Workload W, against Resource R.

Primitive 02 · Delegation & tokenization

Short-lived. Scoped. Bound to the task.

The Security Token Service turns a composite identity into a credential an agent can actually use. It evaluates the delegation context and issues an Arcane Token carrying only the permissions policy grants — for this task, in this environment, right now.

Not a bearer token. It doesn't just say "this caller is authorized." It says "this caller is authorized to do these specific things, in this context, right now."

Arcane_token · decoded
issued 14:02:07 UTC
{
  "iss": "sts.arcane",
  "sub": "composite/u.olsen@acme|agent.pk-93f|pod.sre-prod-4",
  "task": "reconcile-invoices-q3",
  "scopes": ["jira.read:proj/FIN", "confluence.write:space/FIN-OPS"],
  "constraints": { "net": "corp-vpn", "rate": 60 },
  "exp": 1744209120  // ttl: 15m
}
△ STS flow
exchange → validate → issue → expire
◇ EVERY ACTION · EPHEMERAL · SCOPED TO THE TASK01 · DELEGATEUser delegatestask descriptor02 · EXCHANGESecurity Tokensts.evaluate()03 · ISSUEDArcane Tokenscoped · ttl 15m04 · CONSUMEResource callpolicy-boundsts.exchange → validate composite → issue → expire
01
Delegate
task descriptor
02
Exchange
sts.evaluate()
03
Issue
scoped · ttl 15m
04
Consume
policy-bound call
Primitive 03 · Authorization policy

Declarative rules. Deterministic decisions.

The policy engine evaluates the Arcane Token's composite identity and task context against your rules — rules that draw on the user's role, the agent's trust tier, the workload's network zone, or attributes of the target resource itself.

policy / jira_finance.rego
● ACTIVE
# agents on the reconcile workflow may read Jira
# in FIN projects, from corporate network only.
allow {
  input.agent.trust_tier >= 2
  input.action == "jira.read"
  startswith(input.resource.project, "FIN-")
  input.workload.network == "corp-vpn"
}
RegoCedarAttribute-basedDry-run against real trafficVersioned · signed
△ Decision lanes
24h · 14.2M evals
INBOUNDarcane.tokenPOLICY FABRICevaluate()allowreviewdenydeterministic · < 5ms · cryptographically logged
Allow
92.4%
Review
5.1%
Deny
2.5%
Primitive 04 · Enforcement plane

Two integration modes. One policy engine behind both.

Enforcement is where the decision becomes a fact. Arcane ships two modes so you can protect every system you run — not just the ones you can modify.

△ Two enforcement modes
one policy engine behind both
◆ MCP SDK · EMBEDDEDAgentMCP SERVERarcane.sdk.authorize()Tool◇ PROXY · TRANSPARENTAgentARCANE PROXYinspect · enforceLegacySaaS · API
MCP SDK

Embedded at the tool boundary

A drop-in library for MCP server developers. Extracts the Arcane Token from the request context, calls the policy engine, enforces the result — before the tool runs.

Identity propagation
Token validation
Authorization at invocation
Use when
You own the server and can add a dependency.
Proxy model

Transparent enforcement for the rest

For systems you cannot modify — third-party SaaS, legacy APIs, tools with no plugin model. The agent calls through Arcane; policy decides; the upstream never knows Arcane exists.

Zero upstream integration
Fine-grained over SaaS
Inline deny without leakage
Use when
The upstream is closed-source or off-limits.
Defense in depth

Every layer has to agree. That's the point.

No single identity layer covers every attack. Binding them gives you specific failure modes — so when something is wrong, the system can tell you which layer flagged it.

Attack
Stolen user token used from attacker's laptop
Caught by
Workload attestation fails
Workload
Attack
Compromised agent in prod cluster
Caught by
Agent identity not in allow-list
Agent
Attack
Legitimate agent deployed to rogue environment
Caught by
Workload attestation doesn't match
Workload
Attack
Insider using approved tooling from approved infra, but outside their role
Caught by
User principal lacks the required group
User
Attack
Agent issued a broad token, asked to do something narrow
Caught by
Token scope is task-intersected, not role-wide
Token
Attack
Legacy SaaS can't check tokens
Caught by
Proxy enforces at the request boundary
Enforcement
Observability & audit

Every decision is logged, signed, and explainable.

Nothing reaches the resource without a policy decision and a signed audit entry. Dry-run policy against real traffic before you ship it. Version policies. Attribute every allow and every deny to the rule that made the call.

Decision log

Cryptographically signed

Every allow, review, and deny records the composite identity, the task, the matching rule, and the outcome.

Policy versioning

Dry-run against live traffic

Promote a new policy in shadow mode. Compare lanes against production. Ship only when the deltas are acceptable.

Metrics

Allow · review · deny over time

Per-agent, per-policy, per-resource. Integrates with Prometheus, Datadog, OpenTelemetry.

Replay

Trace any action end-to-end

From delegation to enforcement. Reproduce the exact decision context for audit, IR, and policy tuning.

Compliance posture

Built for regulated enterprise from day one.

Arcane is the control plane. We never see your codebase, your agent traffic, or your resource contents. What we see — and what we attest to — is the authorization decision.

SOC 2 Type IIISO 27001Data residency · US / EUVPC-native deploy
◆ Operating tenets
  • 01We never see your codebase. A Claude Code skill generates a BOM of your agent's dependencies locally; only that declaration reaches us.
  • 02Policy evaluation runs inside your VPC. No traffic leaves your perimeter for an allow/deny.
  • 03Tokens are signed with keys you can rotate. JWKS lives in your control plane.
  • 04The proxy is deployable as a sidecar, gateway, or per-region fleet. You own the topology.
Adopt the control plane

Ship agents to production.
Keep your compliance posture.

Arcane Identity is in limited availability. We work directly with security and platform teams at regulated enterprises that are putting agents on the critical path.