Agent Enrolment

Overview

Every agent that calls a governed tool has to exist in the Agentic Registry with an accountable owner, a risk tier, and its tool access. Reviewing each one by hand is correct for the first few agents and becomes the reason people stop enrolling agents at all once there are two hundred of them on a weekly deploy cadence — which produces shadow AI, not safety.

An enrolment policy states those facts once, for a class of workloads: “any agent this issuer vouches for, whose identity matches this pattern, is owned by this person, runs at this risk tier in this namespace, and draws its tool access from this role.” A workload that matches arrives already described. A workload that does not still lands in Work Queue, which then holds exceptions instead of the entire population.

Enrolment is not authorization

An enrolment policy describes an agent; it never decides a tool call. The agent still needs relationships that permit the tool and the action, and every call is still authorized at request time.

What makes automatic enrolment safe

A policy can only ever match a workload whose identity an identity provider verified. The identity provider is a required field, and matching happens against the verified claim in the agent’s workload token — never against a name the workload chose for itself. An agent that presents no workload proof is never matched by a policy.

Two further conditions bound what a policy may admit:

• Blueprint severity ceiling. Max scan finding is the worst static code-scan finding a policy will enrol an agent through. A workload whose code scan is worse than the ceiling is an exception by definition and goes to review. Leave it empty to require a completely clean scan.
• An accountable owner is mandatory. Removing the typing is the point; removing the named human is not. A policy cannot be saved without one.

Create an enrolment policy

1. Confirm the identity provider

   Open Agentic → Identities → Identity providers and make sure the issuer that vouches for this class of agents is connected and tested. See Agent workload identity.

2. Open Agentic → Enrolment

   Select New policy.

3. Set the match predicate

   Field	Meaning
   Identity provider	Required. The issuer whose verified tokens this policy trusts.
   Matches	Any — every agent that provider vouches for; Prefix — identities carrying one of the listed prefixes; List — exactly the listed identities.
   Identity values	Comma-separated values for the prefix and list modes.
   Priority	Evaluation order, lowest first. Ties break deterministically on creation time.
   Max scan finding	The worst blueprint finding severity this policy will enrol through. Anything worse goes to review.

4. Set the defaults applied on match

   Field	Meaning
   Accountable owner	Required. The named person answerable for agents enrolled by this policy.
   Grants via role	A role userset — for example role:reporting#assignee — that carries the class’s tool access. Assigning through a role is what turns one grant per tool into one assignment.
   Risk tier	The default risk level recorded on the agent.
   Namespace	The default namespace the agent is filed under.

5. Enable and verify

   Save the policy enabled, then start one matching workload. Confirm it appears in Assets → Agents already described, and that Enrolment shows a match count and a last-matched time for the policy.

A policy saved disabled stays disabled. Disable a policy to stop it describing new agents; agents it already enrolled are unaffected.

Re-enrolling after a denial

A denied registration is not edited — the audit trail grows rather than being rewritten. An operator supersedes the denial with a new registration that references and overrides it, so the original decision and its reason remain readable. Until that happens, status() reports denied and the workload can enrol under a different agent name instead.

Code changes after approval

An approved agent whose code changes is re-scanned, and the new scan is compared against its approved baseline rather than judged from scratch:

• A change that introduces no new finding and escalates none is admitted without another review.
• A new or escalated finding sends the agent back to review and quarantines it in the meantime.
• Findings the change resolved are shown in the delta so a reviewer sees the whole picture, not only the bad half.

The scanner still runs on every code digest. What the delta removes is a re-review of findings a human already accepted.

Automation and CI

Governance objects — identity providers, enrolment policies, grants, agents — are control-plane objects, so mutating them normally requires an operator signed in to the workspace. A control-plane token is the machine credential that lets the same objects be declared in version control and applied by a pipeline.

Route	Purpose
GET /api/agentic-new/control-plane-tokens	List tokens in the active workspace.
POST /api/agentic-new/control-plane-tokens	Issue a token. Body: {"name": "...", "lifetime_days": 90}.
DELETE /api/agentic-new/control-plane-tokens/{id}	Revoke a token immediately.

Token handling

• The secret is returned once, by the create call, and is never stored — only its hash is. A lost token is replaced, not recovered.
• An expiry is required. A machine credential with no expiry becomes a permanent key in a CI variable that nobody rotates.
• A token is scoped to one workspace and is refused if presented against another.
• A control-plane token cannot manage control-plane tokens. Issuing and revoking require an operator session, so a leaked token cannot mint itself a replacement ahead of revocation.

Next steps

• Agent workload identity — verified agent tokens, proof-of-possession, and SPIFFE.
• Agentic — the full control-plane workflow.
• Relationship Authorization — roles, resources, tools, actions, and delegation.