Core capabilities available/Zero-trust gateway for AI agents

Someone else’s AI agent wants access to your API. Atria is how you say yes.

A zero-trust proxy in front of the APIs you already run. Every agent carries a 15-minute certificate, every request is checked against boundaries you keep in git, and every decision — allowed or denied — lands in an append-only log with its reason code. No SDK, no backend change, and nothing on the request path leaves your network. Core enforcement, identity, and audit capabilities are ready for commercial deployment.

01Security modeltrust boundary, failure modes, crypto 02Evaluate offlineone command, nothing reported back 03Control mappingwhat your auditor is asking for

atria-gateway · live intercept

streaming

Incoming agent request

{
  "agent": "agent://acme.procurement.v2",
  "org": "Acme Corp",
  "action": "invoices.read",
  "resource": "/v1/finance/invoices"
}

POLICY PASSED

Execution log

mTLS handshake · cert signed by atria-ca
identity resolved · CN=acme.procurement.v2
revocation check · not in CRL (synced 4s ago)
policy match · GET /v1/finance/invoices in boundary
action allowed · forwarding to origin
audit entry written · append-only

For the person who signs off

Four questions you will be asked about agent access

Answers you can give with a mechanism behind them, not an assurance.

Who is this agent, and who is answerable for it?

Each agent presents a certificate issued against a named API key. The agent id and the key id are both on every log line, so an action resolves to an account — not just to a role somebody could have reused.

What can it do — and what can it never do?

A YAML allow-list you keep in git: method and path, calls per minute, and a transaction-value ceiling. Paths match by segment, so /orders never admits /orders-export. Anything not granted is denied.

What did it do at 14:00 last Tuesday?

One append-only JSON line per request: agent, credential, endpoint, allowed or denied, the reason code behind the decision, and whether the revocation list was current at the time.

What breaks when your vendor has an outage?

Nothing on the request path. Certificates verify against a CA public key pinned at install, and revocation is a list the proxy already holds. Our cloud is not in the call — by construction, not by SLA.

And for the platform team that has to run it

A reverse proxy in front of the API you already have. No SDK, no framework, no change to your service, and no rewrite of your API scopes — agents enrol themselves against an API key, so onboarding one is not a ticket queue.

Architecture

Every request flows through one enforcement point

Agents never talk to your systems directly. Atria intercepts, verifies, and records each call before it ever reaches an origin.

External AI Agent

Cross-org · untrusted

MCP client
Autonomous loop
Tool calls

Atria Policy Gateway

Authenticate · authorize · audit

Certificate identity
Revocation check
Policy engine

Enterprise API

Protected origin

Internal services
Databases
Private tools

allowed → forwarded to origin denied → rejected at gateway every event → written to audit log

agents enroll once → short-lived Atria certificate gateway verifies offline against a pinned CA key revocations sync from Atria Cloud

Policy

One YAML file your team already owns

No console to learn. Policy lives in your repo, keyed by agent identity, and reloads without a restart — an agent with no entry is denied by default.

policies.yaml

# Keyed by agent id, taken from the certificate subject.
# No entry here means no access — there is no implicit allow.

agents:
  acme-procurement-v2:
    allowed_endpoints:
      - method: POST
        path: /api/v1/orders
      - method: GET
        path: /api/v1/orders/*

    # Counted per agent id, across all its certificates.
    rate_limit_per_minute: 100

    # Any transaction_value in the body, at any depth.
    max_transaction_value: 1000.0

Default-deny — an unlisted agent, endpoint, or method is rejected, not ignored.
A bad edit is refused; the previous policy keeps enforcing until it’s fixed.
Apply changes with one call to the admin API — no restart, no downtime.
Version-controlled like any other file in your repo, reviewed the same way.

Core capabilities

A security layer purpose-built for autonomous agents

Atria sits between external agents and your systems, turning every request into an authenticated, authorized, and auditable event.

RBAC for LLMs

Dynamic Policy Enforcement

Role-based access control built for LLMs. Define granular action boundaries per agent, org, and resource — evaluated on every request.

Offline validation

Identity Without Shared Secrets

Unlike JWT, the gateway validates any Atria-issued certificate against a pinned public key — no secret to distribute, no call to our cloud on the request path.

Append-only

Complete Audit Trails

Every intercepted action is written to an append-only log — which agent, which endpoint, allowed or denied, and the reason code behind the decision.

mTLS or header proof

Works Behind Your Existing Edge

Where a CDN or load balancer terminates TLS before the proxy sees it, the certificate and a signed proof of possession travel in a header instead, with replay protection. Every log line records which mode decided it, so one log stays readable across a mixed fleet.

Protocol-agnostic

Any Agent, Any Framework

Drop Atria in front of any MCP server, tool endpoint, or enterprise API — no changes to your backend. Agents enroll once for a session certificate; no SDK, no framework lock-in.

GitOps

Policy as Code

Policy is a YAML file you own, reviewed in your pull requests. A rejected edit leaves the previous policy in force, and a reload takes effect on the next request — no restart, no dropped connections.

The fair objections

What we hear in the second meeting

We already have an API gateway.

Keep it. A gateway authenticates callers you enrolled and shapes their traffic; it was not built to hold a per-session identity for somebody else’s autonomous process, to bound the value of an action inside the request body, or to attribute a denial to a credential you can revoke centrally in fifteen minutes. Atria goes in front of it or behind it — it is a reverse proxy, not a platform.

Why not just issue them an API key?

Because a key is a bearer secret with the lifetime of whoever forgets to rotate it, and it is copied into an agent framework you do not operate. A 15-minute certificate re-enrolled against a revocable credential changes what a leak costs, from "until someone notices" to "until it expires".

Isn’t this what the model vendor’s guardrails do?

Those bound what a model says. This bounds what its actions reach. The prompt is not where the money moves — the API call is, and that call arrives at your edge whether or not the reasoning that produced it was well behaved.

We are not putting another vendor in the request path.

Neither are we. Nothing of ours is in the call: certificates verify against a public key pinned into the proxy at install, revocation is a list already on the box, and the proxy is a binary you run on your own hardware. If our infrastructure vanished tomorrow, your agents would keep being checked.

Control mapping

Where agent access lands in your control set

“How is third-party AI access governed?” is now a question on assessments that were written before agents existed. These are the controls it usually falls under, and the artifact you hand over when someone asks for proof.

FrameworkWhat Atria enforcesWhat you hand the auditor

ISO/IEC 27001:2022

A.5.15 Access control · A.8.2 Privileged access rights

Per-agent allow-list of method and path, issued against a named credential and revocable independently of it.

The policy file in your git history, plus the revocation list the proxy pulls.

ISO/IEC 27001:2022

A.8.15 Logging · A.8.16 Monitoring activities

One record per request — allowed or denied, with the reason code and the credential behind it.

Append-only newline-delimited JSON, written locally, shipped wherever you already ship logs.

SOC 2 (Trust Services Criteria)

CC6.1 logical access · CC6.6 external threats · CC7.2 monitoring

External, non-employee automation authenticated with short-lived certificates and bounded at the edge of your API.

Certificate lifetime and issuance trail, plus the decision log for the audit period.

NIST CSF 2.0

PR.AA identity & access · DE.CM continuous monitoring

Identity proofing for a non-human actor, with authorisation re-evaluated on every single request rather than at session start.

Per-request decisions, including the ones that were denied — usually the harder half to produce.

EU AI Act

Art. 12 record-keeping · Art. 26 deployer log retention

Automatic recording of events over the lifetime of an AI system you deploy or expose to third parties.

A log line per agent action, retained on your infrastructure and under your retention policy.

To be exact about it: Atria holds no certification of its own, and nothing here says your programme is compliant. It says which control the mechanism satisfies and what evidence it produces — the part an auditor actually asks for. Our own certification status is on the security page, stated plainly.

Measured, not targeted

What the security check actually costs

Release build, p99, on one machine. The decision itself is microseconds; what you pay for is the extra hop and its TLS handshake.

Per decision

Policy evaluation: 1.6 µs
Revocation lookupflat from 0 to 10,000 revoked certificates: 0.1 µs
Identity parse: 5 µs

Added p99, end to end

1 connection: 0.57 ms
8 connections: 1.57 ms
32 connections: 5.37 ms

The benchmark's backend shares a process with the proxy, so the loaded rows include contention that a real deployment does not have. Read them as a ceiling. Beyond 32 concurrent connections on one core-constrained box, overhead grows faster than linearly — ask us for the full table rather than assuming it flattens.

15-minute agent certificates by default, 24 hours maximum
Mutual TLS 1.2 / 1.3, ECDSA P-256, CA pinned at install
No unsafe code in the proxy — 59 Rust source files, zero blocks
~5,000 requests/second per proxy before latency climbs

Development log

Now available for commercial use

Pinned2026-08-07

Session certificates now cover the full enrollment flow

Agents enroll with a registration key and receive a short-lived Atria session certificate — no shared secrets on the wire, verified offline against a pinned CA key.

2026-07-22

Revocation pull-and-cache landed in the proxy

The proxy now pulls a signed revocation list on an interval and fails open on the last good copy rather than blocking traffic when Atria Cloud is unreachable.

2026-07-01

Policy engine moved to customer-owned YAML

Dropped the Redis dependency for policy storage — policies are a YAML file you own and version control, parsed at startup and on explicit reload.