Many terms belong to a specific layer. Corbits is three layers: apps on top, a control plane that runs and governs agents, and an agent runtime beneath. The definitions below say which layer each term belongs to. See The Corbits Platform for the layered picture.
Layers and products
Corbits. The platform for deploying secure, auditable agents with organizational guardrails: the run, audit, and manage layer you run agents on. See Overview. Control plane. The layer that runs, governs, and audits agents. It resolves credentials, materializes grants, gates the API, and keeps a signed record of what an agent did. It does not decide everything: some checks run in the agent runtime while an agent is going. Most terms in this glossary belong to the control plane. Agent runtime (Interchange). The execution engine beneath the control plane. It runs the agents and handles model choice, speaking to the major model providers natively. It also evaluates grants itself: whether a running agent may invoke a given tool is decided here, against the grants that deployment holds, rather than in the control plane. Agent. A defined set of capabilities, instructions, and goals that runs as a loop within a durable workflow. An agent can run locally, built directly on the Interchange libraries, or be deployed on the control plane and provisioned onto a sidecar for managed use. See Overview. Apps. The finished products people use, built on the stack. Corbits ships two: Workbench and Corbits Code. Workbench. The first-party multiplayer workspace for humans and agents, sharing benches and conversations. It runs on the control plane and inherits its credentials and grants. See Workbench. Corbits Code. A standalone coding-agent CLI that applies the same guardrail discipline in its own process rather than on the control plane. See Corbits Code. Bench. In Workbench, the shared space a team works in, holding its members, its agents, and its history. A bench is a control-plane tenant underneath, so belonging to one is a principal record and what you may do in it is decided by grants. See Workbench. Channel. In Workbench, a conversation inside a bench. A channel is minted as its own control-plane tenant parented under that bench, which gives it an identity and a place to hang membership, though the routes serving it authorize against the bench above. See Workbench.Authorization
These are the credential and grant terms. The control plane resolves credentials and materializes grants; the agent runtime decides some of what an agent may do while it runs, and a few decisions consult no grant at all. See Guardrails for which is which. Principal. An entity within the control plane, joined to a tenant. A principal is a user or a workflow. Grants attach to principals, either directly or through a role. Tenant. An organizational scope that owns credentials, roles, and grants. Tenants nest into a hierarchy of sub-tenants. Inheritance and shadowing. Credentials resolve up the tenant hierarchy: the control plane checks the current tenant, then walks up the parent chain, so a child tenant can resolve a credential defined at a parent. A child can shadow a parent’s credential by defining one with the same name, since names are unique within a tenant. Grants do not inherit at all: authorization evaluates only the grants held in the acting tenant. Role. A named bundle of grants scoped to a tenant. Every tenant has the system roles owner, admin, and member. Roles carry authority when a person calls the control-plane API; a running workflow’s authority comes from the grants on its own principal. Grant. A row saying that some principal may take some action on some resource, carrying three fields: resource, action, and effect. Most of what a principal may do is decided by evaluating grants, though not all of it: a model-provider credential is authorized by tenant ownership with no grant involved. Resource. The part of a grant that names what is authorized, as a glob pattern:tool:bash, credential:crd_gdrive, tool:*.
Action. The part of a grant that names the operation, as a verb: invoke, read, use.
Effect. The decision a grant carries: allow, deny, or ask. When more than one grant matches, the most specific wins, and at equal specificity deny beats ask beats allow.
Fail-closed. Where either layer decides from grants, an action proceeds on the strength of a grant that permits it, and on nothing else. There is no implicit allow. Which decisions are made that way, and which are not, is set out on Guardrails.
Credential. A runtime secret an agent uses to authenticate with an outside provider: an API key, an OAuth token, or a certificate. Owned and stored by your organization, and delivered to a deployment by the control plane rather than looked up by the agent.
Provider. The outside service a credential authenticates to, such as GitHub, Slack, or a model provider like OpenAI. Every credential belongs to a provider.
Organizational vs. personal credential. An organizational credential has no principal owner and is shared across the tenant. A personal credential is owned by a specific user.
Git token. A bearer secret a caller presents to reach the durable state described on Guardrails, minted by the control plane as either a personal access token or a service token. It is a separate concept from a credential: a credential is what an agent authenticates to an outside provider with, while a git token is what a caller authenticates to us with. Its claims narrow the actions a holder may take, the refs they may touch, and how long the token lives, and the control plane intersects them with a grant verdict on every repository operation.
Requirement. What a deployed definition declares it needs, rather than a live grant. The control plane resolves credential requirements when a definition is deployed and grant requirements when it first triggers, rather than letting an agent look anything up while it runs. Credential requirements and grant requirements are declared separately, and the two accept different sources.
Source. A field on a requirement that names where its authority comes from. A credential requirement draws from tenant (the organization’s), creator (the definition author’s), or invoker (the user launching the agent). A grant requirement draws from creator or invoker only; there is no tenant-sourced grant requirement. Source is about the provenance of authority, not about sharing.
Tool. A capability a principal can invoke. The agent runtime checks every invocation against a tool:<name> grant that the control plane froze when the deployment was created, taken from what the workflow declared rather than from a set an operator chose. The effect that grant carries comes from the tool’s own declaration in the same way: a tool declaring an approval mark carries ask. Not every tool reaching an outside provider needs a credential.
Execution
These terms name the agent-runtime pieces involved in running the code you deploy. See Isolation for the full treatment. Sidecar. The managed host that runs deployed agents and workflows. The control plane provisions work onto sidecars, tracks their health, and routes to the deployments each one hosts. See Isolation. Deployment. A workflow or agent placed onto a sidecar and made addressable, carrying its own mail address and signing key. It is the unit the control plane provisions, routes to, and tears down. Supervisor. The trusted half of a running deployment. It holds the deployment’s identity, meaning its signing key, its address on the message bus, and the credentials it was granted, and it starts and oversees the process that runs your code. See Isolation. Workflow process. The other half: where the code you deployed actually runs, meaning your tools, prompts, and agent logic. It is treated as the untrusted side of the pair, and it cannot act as the deployment or reach its signing key. See Isolation. Harness. The agent-runtime component that drives an agent’s loop and mediates everything it touches: tools, messages, inference, and storage. It is what keeps grants, keys, and audit records out of the agent’s reach. See Isolation.Approvals
These terms belong to workflow runs. The control plane evaluates theask decision, and the run is what suspends and resumes. See Approvals.
Suspend and park. When a tool call in a workflow run resolves to the ask effect, the call is suspended and parked durably to await a human decision, and the exact call is resumed once approved.
Approval. A parked decision awaiting a human: approve-once or reject, resolved through the API by whoever holds the grant to resolve it.
Snapshot. The record captured when a call is parked: the tool’s name, its description and input schema, and the actual call arguments, so an approver reviews the real operation rather than an opaque id.