Skip to main content
A Tower runs the control plane, agent runtime, and data on-box. But the regulated primitives — cards, phone, formation, verification, trading — depend on real provider relationships (Stripe Issuing, Surge, a formation agent, KYC, a broker) that a box does not hold keys for. Rather than ship provider secrets to every box, a box in production transacts these over governed cloud rails.

​
Two environments, two paths

Every regulated action first gets a governor verdict carrying a target:
  • sandbox → the synthetic sandbox adapter. No real effect, ever — a stamped synthetic resource. Unchanged on a box.
  • production (live) → the real rails. On cloud that’s the local provider adapter. On a box, the primitive becomes a thin API client to the cloud.

​
The box → cloud path

In production on a box (NAIVE_BUILD=tower), a regulated action is forwarded to api.usenaive.ai through the box egress-gateway:
  • Auth = the owner’s cloud key, sealed in vaultd. The api never reads it (vaultd has no reveal on a Tower). The egress-gateway’s terminating forward injects the sealed key and adds its own TLS — the same credential-injection mechanism used for every production provider call.
  • Tenant scope = X-Naive-User-Id. The cloud resolves the operator from the header (subject resolution), so per-operator scoping and audit hold.
  • Governed + audited. The call goes through the gateway, so it is subject to the same allow/deny + audit trail as any other egress.

​
Opt-in and isolated

This path is entirely opt-in: it activates only when NAIVE_BUILD=tower AND a gateway forward is configured (NAIVE_REGULATED_RAILS_FORWARD). Unset, the box behaves exactly as before (the production executor 501s without local keys), and cloud is never affected. Sandbox always stays synthetic.

​
Follow-on

The MVP holds the owner’s cloud key in vaultd. A device-scoped short-lived token and device-attributed billing (plan §8) are a hardening follow-on — not required to transact.