Toolchain
Status: Accepted
Toolchain
Section titled “Toolchain”Decision
Section titled “Decision”Four components implement the two-wall architecture. Each is accessed through a provider-agnostic Go interface — arpi is not tied to any specific tool.
| Layer | Interface | Current tool | Role |
|---|---|---|---|
| Secrets + identity | IAMProvider | Infisical | Machine identities, dynamic secrets, zero-disk injection |
| LLM + MCP gateway (Wall 1) | GatewayProvider | Bifrost | Model routing, tool RBAC, rate limiting, audit, virtual keys |
| Sandbox (Wall 2) | SandboxProvider | OpenSandbox | gVisor/Kata/Firecracker isolation, credential proxy, egress filtering |
| Product auth | (separate concern) | Better Auth | MIT, in-process, replaces Clerk for end-user auth in products |
Provider interfaces
Section titled “Provider interfaces”arpi interacts with each tool through a Go interface in cli/internal/:
IAMProvider— login, get token, fetch secrets, resolve uid/euid. First implementation: Infisical Machine Identities +infisical run.GatewayProvider— configure routing, issue virtual keys, set tool RBAC per definition. First implementation: Bifrost.SandboxProvider— create sandbox, mount project, inject env via credential proxy, set egress rules, start/stop. Implementation: OpenSandbox (via its 3 OpenAPI specs: lifecycle, execd, egress).
Why these tools
Section titled “Why these tools”Infisical — OSS, self-hostable, dynamic secrets + Machine Identities. Vault is too heavy for a small team. 1Password lacks dynamic secrets. Doppler has no self-host.
Bifrost — Single control plane for LLM routing and MCP tool access. Go, <100us overhead. Replaces LiteLLM (which had a March 2026 supply chain incident and is Python/slower).
OpenSandbox — Apache 2.0, 3 OpenAPI specs (lifecycle, execd, egress), pluggable backends (gVisor, Kata, Firecracker, Apple Container). Our fork adds Apple Container backend, credential proxy, policy engine, and Go SDK. See sandbox-strategy.md.
Better Auth — MIT, in-process, TypeScript. Replaces Clerk (reliability issues). Handles end-user auth in products, not developer identity (that is Infisical’s domain).
What was rejected
Section titled “What was rejected”Docker Sandboxes — Proprietary, no open API spec, vendor lock-in to Docker. OpenSandbox provides the same isolation with an open spec.
mise — Removed from the toolchain. Runtime management is not arpi’s job. The definition declares what runtimes are needed; the developer or container image provides them.
Implementation
Section titled “Implementation”- Define
IAMProvider,GatewayProvider,SandboxProviderinterfaces in the control plane. - First implementations wrap Infisical SDK, Bifrost API, and OpenSandbox API respectively.
arpi spawn(via the control plane API) calls providers through interfaces — swapping a tool means implementing the interface, not rewriting spawn logic.- Better Auth is used in product auth, not in the arpi control plane itself.
- The CLI is a thin client to the control plane API. Provider interfaces live server-side. See
template-schema.mdfor the revised architecture.
Verification
Section titled “Verification”arpi spawnworks with provider interfaces, not direct tool calls- Infisical:
infisical runinjects secrets without writing to disk - Bifrost: routes LLM calls with OpenAI-compatible API, exposes tool groups per definition
- OpenSandbox: container blocks egress except to gateway, cannot read host filesystem outside project mount
- Swapping a provider implementation does not require changes to spawn logic