What is the difference between directory registration and runtime authorisation for agents?

Where directory registration ends and runtime authorisation begins

Directory registration is the control-plane act of recognising an agent as a known entity, attaching ownership, metadata, and a standing trust context. runtime authorisation is the per-request decision that checks what that agent may do in this exact invocation, against this resource, at this moment. The two are related, but they solve different security problems.

That separation matters because a registered agent can still be over-scoped, blocked, or forced into a narrower path at runtime. Registration answers “who is this and should we recognise it?” while runtime authorisation answers “what is this request allowed to do right now?” If you blur them together, you lose the ability to apply least privilege to individual actions.

For agent systems, the practical distinction is between identity standing and action permission. A directory entry may prove the agent exists, who owns it, and whether it is active; it does not automatically justify every tool call, data access, or downstream side effect. That is why Agentic AI Identity Guide is useful as the broader lifecycle context, while AI Agent Authorisation Guide focuses on the runtime decision layer.

In mature implementations, registration is relatively stable and auditable, while runtime authorisation is dynamic and context-sensitive. That means the second control can incorporate request scope, target resource, risk signals, task step, user approval, or policy state without changing the agent’s underlying identity record. This is the difference between being known and being permitted.

Why separating standing access from per-request decisions improves control

Directory registration is useful because it creates inventory, ownership, and accountability. It gives operators a place to attach lifecycle events such as onboarding, suspension, and retirement. But if that record is treated as proof of unlimited future access, the directory becomes a standing permission registry instead of an identity source.

Runtime authorisation is the layer that prevents that mistake. It can reduce the blast radius of a compromised agent, constrain a legitimate agent that has wandered outside its intended task, and force step-up approval for sensitive actions. The distinction is especially clear in externalised policy systems, where Authorisation Models Guide explains how policy-based checks differ from role assignment, and IAM and IGA Basics separates provisioning from enforcement.

For agents, standing access is usually too coarse to be safe on its own. A registered agent may be legitimate for one workflow, one tenant, or one dataset, yet still need denied scopes for a particular call. Runtime policy is what lets you say yes to the agent in general but no to this request.

How practitioners should model the difference in an agent architecture

Think of directory registration as the source of truth for the agent’s existence, ownership, and baseline posture, and runtime authorisation as the source of truth for each action decision. The first should be relatively infrequent and governed by lifecycle process; the second should happen every time the agent invokes a tool, reads a record, or attempts a privileged operation.

A useful design test is whether the control still makes sense if the agent remains registered but loses access to a specific capability. If the answer is yes, you are dealing with runtime authorisation. If the agent must be created, disabled, or removed from the directory to fix the issue, you are dealing with registration or lifecycle governance. That is why NHI Lifecycle Management Guide is the right anchor for standing identity hygiene, while Agentic AI Security Policy Template addresses approval and control of agent actions.

In practice, good architectures keep the registry, policy engine, and enforcement point separate. That separation lets you change policy without re-registering agents, revoke one capability without tearing down the whole identity, and preserve an audit trail that shows both identity state and decision state.

Practitioner Guidance

What to verify: Confirm that registration metadata and runtime scopes are stored and governed separately. If ownership, environment, or intended task can be edited only by lifecycle admins, but tool access can be changed independently by policy, the split is probably healthy.

Decision rule: If the control question is “should this agent exist and be trusted as a known entity?”, treat it as registration. If the question is “may this exact invocation access this resource or perform this action?”, treat it as runtime authorisation. Do not let a directory approval implicitly grant every future action.

Common mistake: Teams often approve an agent once, then rely on that approval as a permanent pass. That is where excessive agency appears: the directory record survives longer than the task that justified it, while the runtime layer is never asked to narrow or deny.

What good looks like: The agent can be listed, owned, and reviewed without being broadly empowered. Each sensitive call is checked against policy, and the result is observable, explainable, and revocable without reworking the whole identity record.

Practitioner takeaway: Directory registration should establish who the agent is in the system, but runtime authorisation must still decide what that agent is allowed to do in the moment. Treating those as one control creates standing privilege where you needed bounded action.

Related resources from NHI Mgmt Group

• What is the difference between managed identities and hardcoded secrets for AI agents?
• What is the difference between workload identity and API keys for AI agents?
• What is the difference between logging actions and logging intent for AI agents?
• What is the difference between human identity governance and AI agent governance?