How Arc Relay works

A proxy between your MCP clients and servers that adds auth, policy, middleware, and management without modifying your existing MCP servers.

The middleware pipeline in action

Every tool call passes through Arc Relay before reaching your MCP servers. Here is the request lifecycle, stage by stage.

1

Authenticate

Client connects via SSE. Arc Relay identifies the user and loads their profile, role, and per-tool permissions.

2

Authorize

Tool call is checked against the user's profile, access tier, and rate limits. Calls to tools the user does not have access to are rejected before any work happens.

3

Sanitizer middleware

PII patterns - credit cards, SSNs, emails, custom regex - are stripped from arguments. Sensitive data never leaves your environment.

4

Content sizer middleware

Response size limits enforced per server or per tool. Large responses are truncated or rejected before they blow your context budget.

5

Alerter middleware

Pattern monitoring fires alerts when specific tools are called, when arguments match thresholds, or when error rates spike.

6a

Execute against local containerized MCPs

For Docker-managed MCPs, the Docker lifecycle layer auto-starts the container if needed, runs health checks, and recovers crashes. The cleaned, authorized call is forwarded to the local server inside your environment.

6b

Execute against remote hosted MCPs

For remote hosted MCPs (Shortcut, Sentry, GitHub, etc.), the call is passed straight through to the upstream service. No Docker lifecycle, no local container - the same auth, policy, and middleware still apply.

7

Archive middleware

Full request/response recorded with user, timing, status, and result. Local by default, optionally encrypted and shipped to a compliance endpoint.

Configure each pipeline stage per-server from the management UI

Security controls

TLS 1.3 in transit

All data encrypted in transit with modern TLS. No exceptions.

NaCl Box encryption

Optional archive records encrypted at the source using NaCl Box (Curve25519 + XSalsa20 + Poly1305) before leaving your environment.

Tenant key isolation

Every tenant gets isolated encryption keys. Your data is cryptographically separated from every other customer.

Tamper-evident records

Hash chains ensure archived records cannot be modified after ingestion. Any tampering is detectable.

Credential encryption at rest

All stored secrets - API keys, tokens, server credentials - are encrypted at rest in the local database.

Per-user session management

Authenticated sessions with configurable expiry. Every action is tied to a specific user identity.

Compliance controls

Per-user identity on every call

Every tool invocation is bound to an authenticated user. No anonymous access, no shared service accounts.

Full audit trail

Request logs capture user, server, tool, arguments, result, timing, and status. Searchable from the web UI.

Per-tool access control - the 2 of 15 problem

Most MCP servers ship 15 tools where 2 are dangerous. Profiles let you map roles to specific capabilities - accounting writes to QuickBooks but cannot delete transactions, reporting gets read-only across financial MCPs, only trusted admins reach the dangerous tools.

PII redaction at the boundary

Sanitizer middleware strips configured patterns before they leave your environment for upstream services.

Optional compliance archive

Connect to an external archive endpoint to ship encrypted records for retention and legal hold.

Rate limiting and quotas

Per-user, per-tool, per-server limits keep runaway agents from generating unlimited cost or load.

BCBS 239-aligned data integrity

Hash-chained, append-only, tenant-isolated records with end-to-end lineage from capture through export. Built on the data-integrity principles (accuracy, completeness, timeliness, adaptability) global banking supervisors apply to risk-data pipelines under BCBS 239.

Frameworks we map to

Frequently asked questions

Where does Arc sit in my stack?
Arc Relay sits between your AI clients (Claude Desktop, Cursor, custom agents) and the MCP servers they call. It is a proxy: clients connect to Arc Relay, Arc Relay enforces policy and middleware, then forwards calls to the actual server. The same pattern extends to Arc Gate for raw LLM API traffic and Arc Bridge for self-hosted models.
How is the data encrypted?
Captured records are encrypted with NaCl Box (Curve25519 + XSalsa20-Poly1305) using tenant-isolated keys. Each tenant gets its own keypair; Comma operators cannot decrypt records without the tenant key. Records are written append-only with content-addressed hashing so any later modification is detectable.
Does Arc see plaintext prompts and tool arguments?
Yes - Arc has to see plaintext to enforce middleware (PII redaction, policy matching) and to write the archive. Plaintext lives in memory only during the request. The archive itself is encrypted at rest with keys Comma operators do not hold.
What happens if Arc Relay goes down?
Arc Relay is designed for fail-open or fail-closed depending on policy. Fail-open mode passes traffic through with a log gap and an alert; fail-closed mode rejects new requests until Arc is healthy. The choice is per-deployment. We recommend fail-closed for regulated workloads.
How do I prove tamper-evidence to an auditor?
Records are hash-chained: each archived record includes the hash of the previous one in the same conversation. Modifying any record breaks the chain for everything after it. We expose a verification endpoint that auditors can call to confirm the chain is intact for a given conversation or time range.
Can I bring my own keys?
Yes. Customer-managed encryption keys via AWS KMS or Azure Key Vault are supported for enterprise deployments. The tenant-isolated NaCl keys can be derived from your KMS-controlled root, so revoking the root locks the tenant out of their own archive.

See Arc Relay in action

Walk through the architecture with our team - or just run it yourself.

View on GitHub Request Demo