Cross-tenant
Credential or code bleed
One compromised agent instance with ambient keys can read or push across tenants. Isolation makes that path structurally unavailable.
For security, platform, and compliance teams
Tenant isolation agents cannot talk around
Sandboxes, SPIFFE identity, and a credential broker keep customer code and secrets behind fail-closed boundaries. No ambient keys in a shared process.
- No ambient credentials in sandboxes
- SPIFFE identity per workload
- Fail closed on every boundary
Project sandbox
One job, one codebase, one workload identity
No leftover GitHub or model secrets in the environment
Runner
Clone, edit, approved commands only
No open shell. Job identity must match the pod
Credential broker
Inject a credential or deny
mTLS identity, scoped mint, deny on failure
GitHub
Model API
Registries
The category
Autonomous agents clone repos, edit files, and open PRs with real authority. Isolation is the stack that keeps one job from becoming every tenant's problem.
A compromised sandbox must not mint tokens for another tenant or repo.
A malicious repository must not escalate from one job to the platform.
Arvad staff with cluster access must not casually read a running working tree.
Misrouted control-plane requests must fail at the broker, not leak credentials.
The gap
What fails without hard isolation
Shared-process agents look fast until the blast radius shows up. These failure modes are what the architecture closes.
Malicious repo
Prompt injection and hostile builds
Poisoned configs, adversarial comments, and hostile dependencies stay inside one job. They cannot mint broader tokens or reach other sandboxes.
Staff access
Need-to-know for production ops
Ordinary SRE tooling sees health and ownership, not the working tree. Confidential Runtime adds hardware attestation so even host root cannot casually decrypt.
Ambient secrets
Dumping the sandbox finds placeholders
GitHub and model credentials live in an Envoy path the sandbox does not control. Code execution inside the job does not equal secret possession.
Principles every boundary obeys
When a mechanism looks complex, two or three of these usually compound.
Least privilege at every boundary
Plan cannot write the repo. Read cannot spend model budget on tools. Execute mints tokens only for the exact repository in scope.
Mode-scoped GitHub permissions at mint time
Defense in depth
Broker, network policy, sandbox isolation, and SPIFFE allowlists each stand alone. No single control is load-bearing.
Bypass one layer; the others still deny
Cryptographic identity for every workload
SPIFFE SVIDs (short-lived x509 proofs) authenticate connections. No shared API keys traveling in logs or env dumps.
spiffe://arvad.internal/… per workload
No ambient credentials in sandboxes
The sandbox never holds GitHub or Anthropic secrets. Envoy injects them per authorized request after the broker decides.
Env dump yields placeholders, not tokens
Fail closed everywhere
Unknown identity, unverified envelope, failed attestation: deny. Silent fallback-to-open is never the answer.
Deny metrics are the health signal
Single-tenant runners
Each runner serves one job. No multi-tenant routing in the sandbox, so nothing else to leak even if a check were ignored.
Isolation is architectural, not procedural
Architecture
Five components, one choke point for secrets
The isolation stack is a credential broker, sandbox runtime, runner service, deterministic wrapper, and SPIFFE identity fabric, each with a narrow interface.
- The broker answers one question: may this sandbox make this request, and with which credential?
- Sandboxes are pluggable: Fargate (default), Kubernetes, Nitro Enclaves, or BYOC.
- The runner accepts typed RPCs with signed job envelopes, not an open shell.
- The wrapper owns secret scan, CI-fix caps, PR open, and audit, not the model.
Ask an engineer to walk the path for your compliance tier.
Credential broker
Envoy ExtAuthz consults the broker before outbound HTTPS. Identity comes from the mTLS peer cert, never a header. Unknown hosts deny without a mint attempt.
- SPIFFE-extracted identity
- Repo ownership checked before GitHub mint
- Mode-scoped installation tokens
Allow with injected credential, or deny
Sandbox never sees the token. Broker never sees the request body.
Sandbox backends
Same interfaces, four points on a cost-versus-strength curve. Fargate for strong tenant isolation by default; Nitro for cryptographic proof staff cannot decrypt; BYOC when compute never enters Arvad's cloud.
- Firecracker microVMs (Fargate)
- Cilium deny-by-default (Kubernetes)
- PCR-gated KMS (Nitro Confidential Runtime)
FargateDefault: VM-level isolation
KubernetesOn-cluster / customer deploy
Nitro EnclavesConfidential Runtime tier
BYOCCustomer-owned compute
Identity fabric
Control plane workloads get stable SPIFFE URIs. Sandboxes get templated identities encoding tenant, job, and mode, so the broker can tell Plan from Execute without trusting the payload.
- 15-minute sandbox SVID rotation
- mTLS between every workload
- No static service-account keys
spiffe://arvad.internal/tenant/…/job/…/mode/executeIdentity travels with the connection, not the payload.
Four trust boundaries that matter
What trusts what: the fastest way to read the isolation model.
What trusts what: the fastest way to read the isolation model.
01Control plane ↔ sandbox
02Sandbox ↔ outbound network
03Sandbox ↔ sandbox
04Staff ↔ running jobs
Control plane ↔ sandbox
The control plane is trusted; the sandbox is not. Signed job envelopes authorize actions. The sandbox cannot reach the control plane except through a narrow verified gRPC surface.
Ed25519 envelopes + env-bound tenant/job checks
Sandbox ↔ outbound network
All egress goes through Envoy: L4 host allowlist plus L7 broker authorization. TLS is terminated, credential injected, then re-established upstream.
Sandbox never sees the credential
Sandbox ↔ sandbox
Different tenants, jobs, and even modes run in separate pods or microVMs. Deny-by-default network policy, with no lateral movement path in the runtime.
Same-tenant jobs are still isolated from each other
Shared agent runtime vs isolated stack
Shared processArvad isolation
Arvad sits where the thread keeps the plan, staging, spend, and checks.
| Capability | Shared process | Arvad isolation |
|---|---|---|
| Where credentials live | In-process / env beside other tenants | Broker + Envoy injection only |
| Cross-tenant separation | Procedural checks | Separate sandboxes + SPIFFE scope |
| Outbound network | Broad egress | Deny-by-default + per-mode allowlist |
| Staff access to working trees | Often possible with host access | Blocked by design; Nitro attests |
| Model can escalate permissions | Often in-band | No. Customer installs repos explicitly |
| Failed auth check | Fallback / retry open | Fail closed |
Straight answers
Limits stated plainly. No demo theater.
One question
When the build finishes, can you show a teammate the plan, preview, tests, and deploy status without digging through chat?
If you cannot, you still have a chat log. Arvad keeps that work in one workspace.
Keep exploring
Walk the isolation path for your tier
Bring your compliance posture. Map Fargate, Nitro, or BYOC to the controls you need with an engineer.