Security model

Plain language. What's encrypted, what's isolated, what agentry can and can't see.

Three properties

1. Your data lives on your server

Every app you build, every database it writes, every customer record it stores — physically on the machine you connected. agentry doesn't copy any of it to our infrastructure.

This includes:

• Source code your AI writes
• App databases and files
• Build artifacts (container images)
• App logs

What's on our side:

• Account metadata (your email, the names of your servers, the IDs of your deployments)
• Audit logs of API calls (who created what, when)

We're a routing layer, not a hosting provider

The pattern matters. Most "AI app builders" host your app on their infrastructure — they hold the database, they hold the code. agentry's model is the opposite: your machine is the host, ours is the front door. If you turn agentry off, your apps don't move. They were already on your server.

2. Your servers stay invisible

agentry doesn't need open ports on your machine. Your server dials out to the agentry bridge; visitors hit the bridge from the internet, and the bridge tunnels their request back to your server through the connection your server opened.

What this buys you:

• Nothing for the internet to port-scan.
• No firewall rules to write.
• No DNS records to manage.
• No certificates to renew.

The bridge is proven network technology for connecting to infrastructure behind firewalls.

3. Per-device cryptographic identity

When you sign in on a new device, agentry mints a unique cryptographic identity for that device. Not a password, not a shared API key — a real key pair tied to that machine.

Consequences:

• Lose a laptop → revoke that device in the dashboard. Other devices keep working.
• A leaked key on one device doesn't compromise others.
• The system can prove which device did what, in audit logs.

How requests are authenticated

End-to-end at every hop:

your harness ──(MCP, local)──→ agentry CLI ──(mTLS over HTTPS)──→ control plane
                                                                        ↓
                                                            scoped to your org
                                                                        ↓
                                            dispatched to your server's tunnel
                                                                        ↓
                                          decoded, authorized, executed in sandbox

• Local MCP: your harness talks to the local agentry mcp process via stdio. No network here.
• CLI → control plane: mutual TLS using your device cert. Every API call is signed.
• Control plane → server: routed over the the bridge tunnel your server opened, also mTLS, with the server's own identity.

Every cluster, sandbox, and deployment is scoped to your organization. The control plane refuses to route a request from one org's harness to another org's server.

Multi-tenancy

agentry is multi-tenant — many organizations on the same control plane and edge. Isolation is enforced cryptographically:

• Each org has its own identity SAN on the device + server certs.
• Routes from bridge.agentry.run and *.agentry.live are checked at runtime: a route for org A can only land on a server owned by org A.
• The MCP server attached to one device cert refuses to dispatch into another org's servers.

If you spot a way to cross those boundaries, please report it — see security disclosures below.

What we can see in transit

HTTPS traffic for your deploy URLs (*.agentry.live) passes through the bridge. We terminate TLS at the edge using a wildcard certificate and re-encrypt to your server inside the tunnel.

That means:

• the bridge sees the request/response bytes in flight.
• We don't store them.
• We don't log payloads — only the high-level routing metadata (which hostname, response code, byte counts).

Applications that handle regulated data and need end-to-end TLS without intermediation require a different topology (dedicated mTLS without the wildcard edge), which agentry-as-a-service does not provide.

Build env vars

When you deploy, your environment variables get baked into the container image at build time. This is required for frameworks like Next.js that read env at module load. Implications:

• Secret values referenced by build-time code (NEXT_PUBLIC_* or process.env.X outside a function body) end up in image layers.
• Those images are pushed to the private registry you connect (GitHub Container Registry or Docker Hub) — never to anything public. If you haven't connected a registry, the image stays only on your server. Either way, treat access to your registry as sensitive, since baked-in build values travel with the image.
• Each build gets a unique image tag, so one app's image can't be confused for another's.

Best practice:

• Only mark vars NEXT_PUBLIC_* (or equivalent) if they're actually safe to expose.
• Keep server-only secrets (DB passwords, API keys) in regular env. Those load at runtime, not build time.

What about my AI keys?

Your model API key lives in your harness configuration (Claude Code config, Cursor settings, etc.). agentry never sees it. The harness uses the key to call the model directly; agentry only sees the harness's MCP tool calls into your sandbox.

If you bind an AI provider as a service (so apps you deploy can use it server-side), you put the key in the dashboard once; it's stored encrypted at rest in agentry's control plane and exposed to the binding's target sandbox via an env var.

Disclosure

Found a vulnerability? Please send details to security@agentry.run. We respond within one business day.

If the issue affects deploy URLs serving traffic, we'll route around it within the same window.

Audit

Every API call, every authentication event, every deployment trigger lands in an audit log keyed to your organization. The dashboard exposes the recent slice; full history is retained for one year.

Audit entries include: user / device, action, target resource, IP, timestamp. They don't include payload bodies.

Compliance

agentry-as-a-service is not currently certified for SOC 2, HIPAA, or GDPR processor obligations. If you need those signoffs, agentry-as-a-service is not the right fit for that workload.

Next

• Wire up your harness — start building.
• Prompting — patterns the agent reliably follows.