What you get
The rest of this page explains each row. If you are evaluating Corbits against a security review, the last two rows are the ones to read first.
Run the host isolated. This is the one deployment decision that matters most.If your workflows use shell or filesystem tools, run the machine hosting them inside a container, VM, or sandbox. Do not run it directly on a host you care about.Those tools hand deployed code the full reach of the account the host runs as, and Corbits does not narrow that reach. The host boundary is the only thing bounding it. Without one, a workflow can read any file that account can read, reach any network the host can reach, and consume whatever the host has.This is a deployment responsibility, not a setting to switch on. Nothing in Corbits enforces it for you.
The tenant boundary: who can reach it
A tenant is the control plane’s isolation boundary. Agents, credentials, grants, and roles are scoped to a tenant, and tenants nest into a hierarchy. Credentials resolve up that hierarchy, so a child tenant can use one defined at a parent. Grants do not inherit: authorization evaluates the grants held in the acting tenant. This is the boundary the rest of the docs already cover. See Guardrails for the grant model and the Glossary for the vocabulary.The trust boundary: what the agent can observe
The agent is treated as the untrusted party. It sees its tools, their results, its messages, and model responses. Of its own machinery, the agent runtime exposes none of the following to the agent:- Your policy. A blocked tool call returns a generic refusal, not the rule that stopped it, so the agent cannot reason about routing around a control it cannot see.
- Key material. The agent’s keys are held and used on its behalf. The agent cannot export or influence them.
- Audit records. The agent has no read or write path to the record of what it did.
- Its own history. Conversation context and audit records live in a store the runtime owns. The agent cannot inspect, branch, or rewrite it.
The process boundary: what deployed code can reach
A running deployment is split in two. A supervisor holds the deployment’s identity: its signing key, its address on the message bus, and the credentials it was granted. A separate workflow process runs the code you deployed, meaning your tools, prompts, and agent logic. The supervisor is the trusted half and the workflow process is not. The channel between them is authenticated in both directions, so neither half can impersonate the other, and a message that does not verify is rejected rather than acted on. What this buys you: if the code you deployed is compromised, it still cannot sign records as your deployment, take over its address, or issue instructions to the half that holds the keys.One limit worth stating, because it is the question a security reviewer asks next. Provider API keys do reach the workflow process. It is what calls your model and tool providers, so the keys for those providers are in its memory while it runs. What stays out of its reach is the deployment’s own signing key and its address on the bus.
What is not available today
Corbits does not confine your workflow code at the operating-system level. Specifically, there is no filesystem jail, no network policy, no syscall filtering, and no memory or CPU limit applied to the process running your code. If your workflow spawns a shell, that shell has the reach of the account the machine runs as. This is why the deployment recommendation above is not optional in practice. The only host-level confinement available today is the one you bring: run the machine hosting your agents inside a container, VM, or sandbox. If workflows have shell or filesystem access, treat that as a requirement of running Corbits rather than a hardening step to get to later. Note the granularity when you do. An isolated host confines everything on it as a group, rather than drawing a boundary around each workflow, so workflows sharing a host are not isolated from each other. Corbits is built so a per-process boundary can be added later without redesigning the runtime around it. Treat that as an architectural affordance rather than a commitment, and plan against what the table above says is available now. One clarification, because it is a common source of confusion: Intercode applies path controls of its own, including a secret-path denylist on file reads and shell commands. Those are Intercode features, not runtime features, and they do not extend to workflows you deploy yourself.“So is my agent sandboxed?” Not by Corbits, and you should sandbox it yourself. What Corbits gives you is a separation of authority: your code runs somewhere that cannot act as your deployment, cannot reach its signing key, and cannot instruct the half that holds it. The operating-system boundary is yours to supply, by running the host inside a container, VM, or sandbox. If your workflows have shell or filesystem access, do that before you run anything you would not hand the host account to.