How ARC1 works, and where each part stands.

Start here

What ARC1 is, and the record it keeps.

• The trusted pathWhat ARC1 is: the control plane that approves AI use, puts the decision into every enforcement point an enterprise runs, and keeps a signed record of what happened.
• The receiptWhat one signed ARC1 record contains, what a verified chain of them proves, and what it does not.

The data plane

What happens to a model request or a tool call on its way through.

• The LLM proxyHow the ARC1 Gateway routes, fails over, holds keys and counts tokens and dollars, and how the same policy compiles into Kong, Azure API Management and LiteLLM.
• The MCP gatewayHow ARC1 governs agents’ tool use: a trusted registry of MCP servers, pinned tool definitions, exact-action authority and signed lineage for sub-agents.
• Agent Personas and Job DescriptionsLeast privilege by job: a job description compiles to exactly the models, tools, data classes and budget an agent needs, and comparing what was asked, granted and used keeps it that way.
• Sanitization and DLP for AIWhat ARC1 detects in AI traffic and where: structured identifiers, narrative text through external DLP, exact matches against your own rosters, prompt injection, privacy canaries, and the miss rates we publish.
• Budgets that actHow ARC1 turns a budget into an action: allowances admitted before dispatch, cheaper models armed at a threshold, alerts that pause a runaway agent through a second person, and a simulator that prices a limit before anyone sets it.

Policy and proof

How a rule is written once, approved by two people and proven afterwards.

• Policy IR and compiling everywhereOne declarative policy, compiled deterministically into each enforcement point’s own format, refused where a target cannot express it, and read back after it is applied.
• AuditabilityThe audit chain, decision records, anchors outside the database and offline proof bundles: how an auditor checks ARC1’s record without trusting ARC1.
• GovernanceTwo-person approval for every change that widens access, change control with readback and drift, and break-glass actions that can only narrow.

Operate

Seeing AI use across the company, and running the gateway yourself.

• VisibilityWhere AI money goes and where AI runs: the Command Center, coverage that admits what it cannot see, every path AI takes into a company, Defend, digests, SIEM delivery and OpenTelemetry.
• The applianceThe ARC1 Gateway packaged to run in your own Kubernetes cluster: pinned images, signed configuration, egress limited to named destinations, and signatures and bills of materials you can check before you install.

Reference

Every term in this documentation, one line each.

• GlossaryEvery term in ARC1’s documentation, one line each, with a link to the page that explains it.

Status words

Each page states where its parts stand in one of three words, and we use them narrowly.

LIVE

In the released product and running on our hosted production deployment, on a fictional health plan’s synthetic data. Live is not the same as running in a customer’s environment: no customer deployment is recorded yet.

LAB

Built or being built, and run only in our lab or against a vendor’s documented interface. Lab evidence names the system and version it ran on.

NEXT

Designed and not yet built. We list it so a reader can see the edge of what exists.

Lab-verified means a named system and version ran the control in our lab with synthetic traffic. Contract-tested means a connector was tested against the vendor’s documented interface without a live service. Customer-verified would mean acceptance in a customer’s own deployment; none is recorded yet.