A common language for what an agent may do.
Identity establishes who is acting. CLC defines the authority itself: which action, with what parameters, under which constraints, and why a request is allowed or denied.
Identity is not authority
An authenticated agent can still be asked to do the wrong thing. CLC makes the authorization decision explicit before execution.
Who
Certificates and tokens bind a cryptographic key to an agent and, through AIC, to an accountable principal.
What
CLC names the permitted action and the parameter boundary. The authority is more precise than “database access” or “tool use.”
Under what limits
Constraints, runtime policy, delegation depth, and unresolved obligations remain explicit rather than hidden in application code.
One decision model across the stack
CLC separates the grant, the requested operation, the decision, and the evidence surrounding that decision.
grant:
id: std/database-v1:query:SELECT
params: { limit: 100 }
operation:
id: std/database-v1:query:SELECT
params: { limit: 50 }
50 ≤ 100 stays inside the granted parameter boundary.Request
limit: 150 → params_exceed_grant.allow_unresolved. It is never silently treated as fully authorized.What CLC standardizes
The language is intentionally small. Its value comes from closing the semantic gaps between systems.
Capability identifiers
A structured namespace and path grammar for actions, with explicit wildcard rules and fail-closed coverage checks.
Parameter bounds
Numeric bounds, enums, cardinality, nested objects, optional keys, steps, and scheme-declared domains such as quantity and path prefixes.
Minimum privilege by intersection
Multiple grants combine by narrowing. A later source can restrict authority but cannot create authority absent from an earlier source.
Stable reason codes
Denials identify the semantic layer that failed, so implementations produce comparable outcomes rather than free-form error strings.
Delegation containment
CLC-D checks whether a child grant stays inside a parent grant and keeps constraints, carrier modes, and chain authentication in their proper layers.
Decision records
Inputs, context, and verdict can be bound into a canonical record suitable for reproducible verification and audit evidence.
Why it matters
CLC is a shared semantic layer, not another credential format.
Portable authority
The same grant and operation semantics can be projected from different carriers, policy systems, and execution environments.
Least privilege that composes
Principal grants, agent capabilities, gateway policy, and delegated scopes can be intersected without silently widening authority.
Deterministic enforcement
Canonical JSON, type-sensitive equality, bounded numeric handling, and ordered decision layers reduce cross-language disagreement.
Testable specification
The normative text ships with executable vectors, property cases, and cross-language runners rather than prose alone.
A specification with an executable corpus
Every semantic rule is expected to have a reproducible observation — positive, negative, or property-based.
Clear boundaries make better standards
CLC does not try to absorb identity, transport, evidence, or legal accountability into one layer.
Start with the language, then inspect the implementation.
Read the concise reference, follow a grant to a decision, or run the machine-readable corpus against a CLC implementation.