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. Organizational guardrails live here: what an agent may touch, which credentials it can use, and a signed record of what it did. 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; the control plane decides what the agents running on it are permitted to do. Agent. A defined set of capabilities, instructions, and goals that runs as a loop on the agent runtime. 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 Intercode. Workbench. A first-party go-to-market workspace that runs on the control plane and inherits its credentials, grants, and audit trail. See Workbench. Intercode. A standalone coding-agent CLI that applies the same guardrail discipline in its own process rather than on the control plane. See Intercode.Authorization
These are control-plane terms. They are the model behind every decision about what an agent may do. See Guardrails for the full treatment. Principal. An identity the control plane can authorize, joined to a tenant. A principal is a user, an agent, 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. The single exception is the check that authorizes using an inherited credential, which widens grant collection to the ancestor chain. Role. A named bundle of grants scoped to a tenant and assigned to users and agents. Every tenant has the system roles owner, admin, and member. Grant. The atomic unit of authorization. Every decision about what an agent may do is made by evaluating grants. A grant carries three fields: resource, action, and effect. 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. The default posture: if no grant explicitly allows an action, it is denied. There is no implicit allow.
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, never discovered 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 or agent.
Requirement. What a deployed definition declares it needs, rather than a live grant. The control plane resolves each requirement against real authority when the work is started, rather than letting an agent look one 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 an agent can invoke. A tool is inert without a grant; a tool that reaches an outside provider is additionally inert without a resolved 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.