Skip to main content

COG-20: Agent Admission

Status:      Draft
Version:     0.3
Created:     2026-08-30
Updated:     2026-10-30
Authors:     Mike Anderson

:::note Related specifications This standard adds one admission class to the access rules for hosted agents in COG-14 §4 — a target-side policy the agent's owner declares on the record — alongside the existing owner and capability (COG-13) classes. It introduces no new token, no new authority primitive and no change to execution identity: it decides only whether a principal may ask an agent without presenting a delegation. :::

Agents need to converse and delegate across users — an operator's administrative agent taking requests from a resident's assistant, two users' assistants corresponding. Capability delegation (COG-13) covers this in principle, but for the common standing arrangement it is the wrong tool: the caller must hold and present a token for every target, and an agent holds none. The natural authority is the target owner's: "these principals may talk to my agent." This standard lets the owner say so once, on the record, and has the venue honour it at the same point where it would otherwise look for a delegation.

Principles​

  • Who may ask, nothing more. Admission answers one question: who may ask this agent? Whoever may ask can ask, by any route — a native operation, MCP, A2A or any other. The agent then acts as itself, deciding what to do with the request. Its authority does not depend on who asked.
  • The target decides. Admission is the target owner's standing policy on the target's record. Callers present nothing.
  • Exact, never inferred. An allowlist names principals by DID and matches them exactly. No prefixes, no families: a user is not its agents, and an agent is not its owner.
  • The operator is a class of one. "The venue" means the venue operator — the venue principal and the agents it owns — and is clearly distinguished from every other user the venue hosts. "Everyone on this venue" is not a class.
  • Anyone is a deliberate choice. An owner MAY admit every caller, the venue's anonymous public principal included. Whether anonymous callers may ask anything at all remains the operator's decision, through the public capability ceiling.
  • Talking only. Admission covers submitting requests and messages. Reading an agent, changing it or controlling it still requires a delegation.
  • Provenance, not instruction. The admitted caller is recorded as the initiator and shown to the agent as venue-verified fact — never as a claim inside the request.

Specification​

1. The admission policy​

An agent record MAY carry an admission policy, accepts, in its configuration. Its value is one of:

ValueAdmits
"owner" (default when absent)nobody beyond the owner; other callers need a delegation
"venue"the venue operator: principals whose user is the venue's own DID — the venue acting directly, and agents it owns
"anyone"every caller, including the venue's public (anonymous) principal
an array of principal DIDsexactly those principals: a user DID admits that user only; an agent DID (<userDID>:g:<agentId>, COG-13) admits that one agent only. The keyword "venue" MAY appear as an entry

Any other value is malformed. A venue MUST reject a malformed policy when the record is created or updated, and MUST treat a malformed policy it nevertheless holds as admitting nobody.

A policy that admits callers other than the owner hands on the right to ask the agent. When a record is created with such a policy, or updated to a different one, the venue MUST refuse the change unless its author itself holds agent/request and agent/message on the agent.

2. What admission covers​

Admission applies to the abilities that mean "talk to this agent" — submitting a request or a message (agent/request and agent/message in the ability vocabulary of COG-13) — and to the agent record as the resource, <ownerDID>/g/<agentId>. It MUST NOT extend to any other ability on that resource (reading, writing, forking, control), nor to any path beneath it (the agent's workspace or sessions).

3. Evaluation​

When a principal other than the owner addresses an agent, the venue evaluates admission at the same point at which — and before — it evaluates presented delegations (COG-13); the two are alternatives, and either suffices. The venue MUST evaluate admission the same way however the request arrives: as a native operation, over MCP, over A2A (COG-14) or by any other route.

Matching is exact on the caller's acting principal DID. For "venue", the test is whether the caller's user — the owner for an agent principal, the principal itself otherwise — is the venue's own DID (or its did:web alias). Only "anyone" admits the venue's public (anonymous) principal.

Admission does not replace the caller's own authority. Asking is still the caller's invocation of the operation that asks, so the caller must be allowed to invoke it. An anonymous caller asks only if the venue's public capability ceiling allows that invocation.

4. Execution and provenance​

Admission changes nothing about execution identity: the agent runs as its own sub-principal within its owner's namespace (COG-13), with its own authority, whoever asked. The request or message is the caller's own unit of work. The caller follows and cancels it under its own authority, and reaches nothing else of the owner's through it. The venue MUST record the caller as the initiator on that unit of work.

Each request or message the agent receives carries its provenance, written by the venue and never taken from the request content:

  • the caller — the principal the request comes from;
  • the authentication record, when the caller was identified through a channel binding (COG-3 §7).

The venue MUST keep the provenance with the turn in the agent's history for as long as it keeps the turn, and MUST present it to the agent as venue-verified fact, distinct from the request content: the caller's user, its agent id if it is an agent, its venue where its DID names one, and the channel through which it was identified. The presentation MUST derive from the recorded provenance and the agent's own identity alone, so a turn is presented the same way every time. It MUST NOT present names or titles chosen on the platform as venue-verified identity.

5. Denial​

A caller that is neither the owner, admitted, nor delegated is denied exactly as COG-14 §4 prescribes. The denial SHOULD say that the target's admission policy does not admit the caller.

Security considerations​

  • The agent's authority is what the owner offers everyone admitted. The agent acts with the same authority whoever asked, and an agent's reading of a request can be talked round. An owner who trusts different callers differently gives them different agents.
  • Anonymous callers share one identity. Every anonymous caller is the venue's one public principal, so their units of work are shared: what one anonymous caller may do with another's is whatever the public capability ceiling allows. A channel's authentication record tells them apart in provenance only.

Out of scope​

  • Agents holding and presenting delegations of their own — the general mechanism that admission short-cuts.
  • Cross-venue addressing of agents (COG-15).
  • Admission on other per-user resources, such as a human-in-the-loop inbox (COG-16).