Hardened enclaves
for AI agents.
Sealed execution environments where agents push code, call APIs, and access services. Every outbound request is intercepted. Credentials are injected at the boundary, never visible inside.
Launch an enclave. Run anything inside it.
Three lines to a sandboxed environment. Every request your code makes is intercepted at the trust boundary, whether it comes from your script, an AI agent, or a full dev session.
Create a sandbox in three lines
Spin up an enclave from your CI pipeline, a script, or your agent framework. It boots in seconds, runs the task, and self-destructs. Every outbound call the code makes is mediated through the policy you set.
- ›Boots in seconds, destroyed on completion
- ›All egress mediated through the trust boundary
- ›No credentials inside the sandbox
# spin up a sandboxed environment in 3 lines import celeris enclave = celeris.create( image="node:20", policy="ci-readonly", ttl="30m" ) result = enclave.exec("npm test") print(result.stdout)
Run Claude Code inside an enclave
Give an AI coding agent a real development environment with access to your repos, without handing it raw tokens. The enclave handles auth scoping, and Claude can push code to approved branches without ever seeing your GitHub PAT.
- ›Agent gets real tools, not real credentials
- ›Push scoped to specific repos and branches
- ›Full audit trail of every action
$ celeris agent run \ --agent claude-code \ --policy coding-agent \ --auth-pack github:org/frontend \ --ttl 2h ✓ Enclave booted ✓ Policy loaded: coding-agent ✓ Auth pack: github (repo:org/frontend, push:feature/*) ● Claude Code is running... # Claude pushes to feature/add-auth # Token injected at proxy, never visible to agent # All git operations logged to audit trail
SSH into a persistent enclave
Provision a full development environment with SSH access, a persistent filesystem, and months of uptime. It works like a remote dev box, but every outbound connection is mediated. Other sandbox providers cannot keep state this long.
- ›Persistent filesystem across sessions
- ›Months of uptime, not minutes
- ›Same policy enforcement as ephemeral sandboxes
$ celeris env create \ --image ubuntu:22.04 \ --ssh --disk 50gb \ --ttl 90d \ --policy dev-standard ✓ Environment ready ✓ SSH: dev@enclave-4f2a.celeris.io ✓ Filesystem: 50GB persistent ✓ Policy: dev-standard (mediated egress) $ ssh dev@enclave-4f2a.celeris.io Welcome to Celeris Enclave 4f2a ubuntu@enclave:~$ _
Every request is mediated
before it leaves the enclave
The agent can use tools, call APIs, and interact with services. Every action passes through a policy-enforcing mediation layer first.
Enclave boots
A hardened, isolated environment starts with no secrets, no credentials, and an immutable root filesystem. No sudo. No privilege escalation.
Agent starts with nothing
The agent process runs with zero API keys, zero tokens. It can execute code and call tools, but has no secrets to leak or exfiltrate.
Outbound request intercepted
When the agent calls an external API, the request is caught at the trust boundary before it leaves the enclave. No direct egress.
Policy engine evaluates
The mediation layer checks the destination host, HTTP method, request scope, and rate against the declared policy. Deny-by-default.
Scoped credential injected
If the request is allowed, the narrowest possible credential is injected at the proxy layer. The agent never sees it.
Request forwarded or blocked
Allowed requests proceed to the destination. Disallowed requests are denied. Every action is logged to the audit trail.
Agent runtimes give too much trust to untrusted code
Every time an agent runs with access to real API keys, tokens, or secrets, you are trusting autonomous code with your most sensitive resources.
API_KEY, GH_TOKEN, AWS_ACCESS_KEY sitting in env vars, readable by any process in the sandbox.
Nothing stops the agent from sending your credentials to an arbitrary endpoint. Exfiltration is one curl away.
Prompt instructions and framework guardrails are the only defense. They are trivially bypassed by injection.
A compromised agent inherits every permission the credentials authorize. No scoping, no narrowing.
The agent process starts with an empty credential store. No API keys. No tokens. Nothing to leak.
Every outbound request routes through the mediation layer. No direct network access. No bypasses.
Policy is enforced at the trust boundary, not in application code, not in prompts.
Access is scoped per service, per action, per environment. A compromised agent reaches nothing else.
Ephemeral sandboxes or persistent environments.
Your call.
Spin up sandboxes from code for one-off agent tasks, or provision long-lived environments engineers can SSH into for months. Same trust boundary either way.
Create enclaves from your CI pipeline, an API call, or your agent framework. They boot in seconds, run a task, and self-destruct. Like Vercel sandboxes, but with a full trust boundary around every request.
# create from code enclave = celeris.create( image="node:20", policy="ci-readonly", ttl="30m" ) enclave.exec("npm test")
- ›Created programmatically via SDK or API
- ›Boots in seconds
- ›Auto-destroyed on task completion
- ›Perfect for CI/CD, agent tasks, one-off jobs
Full development environments with SSH access and persistent filesystems that survive reboots. Engineers get a real workstation behind the trust boundary. Other sandbox providers cannot keep state this long.
# persistent dev environment $ celeris env create \ --image ubuntu:22.04 \ --ttl 90d \ --disk 50gb \ --ssh $ ssh dev@enclave-4f2a.celeris.io
- ›SSH access for engineers
- ›Persistent filesystem across sessions
- ›Months of uptime, not minutes
- ›Same mediation and policy enforcement
One token. Scoped access. Your rules.
Connect a single personal access token and let the enclave handle scoping, restriction, and enforcement. Or bring your own authorization logic.
One PAT, scoped per agent
Provide a single GitHub personal access token. The enclave restricts which repos, branches, and actions each agent can use. No need to mint per-agent tokens.
auth_pack: provider: github token: $GH_PAT repos: - org/frontend - org/api branches: [main, feature/*] actions: [read, push]
Your logic at the proxy
Run your own authorization logic at the mediation layer. Filter API responses, redact sensitive fields, or enforce business rules before data reaches the agent.
authorizer: type: webhook url: https://auth.corp/check filter_response: true redact_fields: - ssn - credit_card
Define access in words
Describe what an agent should be able to do in plain English. The enclave translates it into a scoped policy with the right auth packs, host rules, and restrictions.
“This agent can read from the frontend repo and push to feature branches on the api repo. It cannot access the secrets manager or any internal admin endpoints.”
Collaboration built in
Multiple engineers can share an enclave. Each user gets their own auth pack and scoped credentials. One environment, isolated access per collaborator.
user:bob → read-only
agent:ci-bot → push feature/*
Define exactly what agents can do. Deny everything else.
Policies are declared in one file. Allowed hosts, scoped credentials, rate limits, and enforcement mode. Readable, auditable, version-controlled.
# Enclave policy definition version: "1" mode: deny-by-default allowed_hosts: - host: "github.com/api/*" auth_pack: github-repo-scoped methods: [GET, POST, PATCH] rate_limit: 60/min - host: "s3.amazonaws.com" auth_pack: aws-s3-readonly methods: [GET, HEAD] auth_packs: github-repo-scoped: type: pat scope: "repo:org/app" branches: ["main", "feature/*"] audit: log_all_requests: true retention: 90d
- ›github.com/api/* (GET, POST, PATCH)
- ›s3.amazonaws.com (GET, HEAD only)
- ›All other hosts
- ›Direct IP access
- ›DNS-over-HTTPS bypass
- ›GitHub: repo-scoped PAT (org/app, feature branches)
- ›AWS: IAM role, s3:GetObject, bucket-scoped
- ›Mode: deny-by-default
- ›Rate limit: 60 req/min per host
- ›Audit: all requests logged, 90-day retention
More than isolation. A real trust boundary.
Other sandboxes isolate processes. Enclaves mediate every interaction between the agent and the outside world by intercepting, scoping, and enforcing policy at the boundary.
Infrastructure-enforced security
Security is not a feature bolted on top. It is the architecture. Every layer exists to enforce the trust boundary between the agent and the outside world.
Zero credential exposure
The agent runtime never contains API keys, tokens, or secrets. Credentials exist only at the proxy layer and are injected per-request.
Deny by default
All outbound traffic is blocked unless explicitly allowed by policy. No implicit permissions. No ambient authority.
Infrastructure-level enforcement
Policy is enforced at the network and execution boundary, not in application code, not in prompts, not in framework hooks.
Immutable runtime
Read-only root filesystem, restricted privileges, no sudo, no privilege escalation. The environment cannot be modified by the agent.
All egress mediated
Every outbound request routes through the mediation layer. Inspected, evaluated, scoped, and logged before it leaves the boundary.
Scoped access
Credentials are narrowed to specific services, repos, methods, actions, and environments. No broad permissions. No wildcard tokens.
Full audit trail
Every intercepted request, every policy decision, every credential injection is logged and reviewable. Retention configurable per policy.
Exfiltration prevention
Data cannot leave through unauthorized channels. Outbound allowlists prevent extraction to uncontrolled destinations.
Ship agents your security team will approve
Standardize how agents access code, APIs, and internal systems. Reduce blast radius. Simplify compliance. Clear the security review.
Safer agent rollout
Deploy coding agents and automation with controlled, auditable access to real systems. No more "just trust the agent" conversations.
Reduced blast radius
A compromised agent can only reach what policy allows. Everything else is denied. Incident scope is bounded by design.
Compliance posture
Full audit trail, scoped access, infrastructure enforcement. Ready for SOC 2, HIPAA, and internal security review.
Standard trust boundary
One policy model across agents, tools, and vendors. No more per-tool trust decisions. One boundary for everything.
Easier security review
Security teams review the policy, not the agent's internal logic. Clear ownership. Clear boundary. Reviewable in minutes.
Platform-ready
Internal developer platforms can offer agents with built-in trust boundaries. Self-service agent execution, safely.
Build on a real trust boundary
Let agents act without giving them the keys. Secure execution for the next generation of software.