Agents

An agent is a first‑class, governed identity — not an anonymous client. Registering an agent is what lets policy reason about “this agent, acting for this user, on this surface” instead of just “some caller.”

What an agent carries

• Owner — the team or person accountable for it.
• Scope — the environments and client surfaces it may operate in.
• Delegated context — the user identity it acts on behalf of at runtime.
• Lifecycle — submission, approval, and revocation, like other governed objects.

Client surfaces stay open-ended

A client surface describes where a governed request enters, such as an IDE, a desktop assistant, an internal portal, or a hosted automation runtime. The registry is customer-owned and accepts new surface IDs. It is not a fixed list of client vendors.

When registering an agent, choose an approved surface by its display name or enter a custom surface ID for a new or private MCP client. The exact ID remains visible for audit and API automation. Unknown clients can use a tenant’s broad compatible surface when policy permits it; customers can add a dedicated surface later when they need a narrower policy or reporting boundary.

Discover vs. call

Policy distinguishes two actions. An agent’s catalog is filtered to what it may discover, and each call is independently authorized. An agent can be allowed to see a tool but denied a particular invocation based on context (surface, environment, credential mode). Tools it can’t discover are simply absent — see Authorization & policy.

Revocation

Revoking an agent (or a break‑glass emergency disable) propagates through the projection and takes effect on the next request, tearing down active sessions. See Emergency-disable a resource.

If an agent owns an upstream credential, read Agent-scoped credentials to see how signed identity, policy, credential resolution, and audit fit together.

Note

Register and govern agents the same three ways as everything else — see Register an agent for the UI, API, and CLI.