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. 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: a user or an agent, joined to a tenant. Grants attach to principals. Tenant. An organizational scope that owns credentials, roles, and grants. Tenants nest into a hierarchy of sub-tenants. Inheritance and shadowing. Credentials inherit down the tenant hierarchy, so a child tenant can resolve a parent’s. A child can also shadow a parent’s credential by defining one with the same name. 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 an agent definition declares it needs, rather than a live grant. The control plane resolves each requirement against real authority at launch.
Source. Where a requirement draws its authority from: tenant (the organization’s), creator (the definition author’s), or invoker (the user launching the agent). 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.
Offering. The set of capabilities an agent effectively has, fixed by which credentials and grants actually resolved for it.
Running an agent
These terms describe an agent’s life on the platform, from launch through the decisions made while it runs. The control plane orchestrates them; the agent runtime carries out the agent’s work. Agent. A deployed unit of work that runs on the agent runtime under the control plane’s authority. Agent definition. The manifest an agent ships. It carries requirements, not live grants; grants are materialized from it at launch. Launch. The moment an agent starts. Credentials are resolved and grants are materialized at launch, never pulled at runtime. Materialize. To turn an agent’s requirements into concrete grants on its own principal at launch. ask (effect), suspend, and park. When a grant resolves toask, the control plane suspends the call and parks it durably to await a human decision, then resumes the exact call once approved. See Approvals.
Approval. A parked decision awaiting a human: approve-once or reject, resolved through the API by whoever holds the grant to resolve it. See Approvals.
Snapshot. The record captured when a call is parked: the tool, its description and input schema, and the actual call arguments, so an approver reviews the real operation rather than an opaque id.