What is the difference between capability and authorisation for agents?

Capability and authorisation separate different questions

Capability answers what an agent can technically execute. Authorisation answers whether that execution is permitted under policy, delegation, and the current trust context. Keeping them separate matters because a function being available in the runtime does not automatically mean the agent should be allowed to use it.

A useful mental model is that capability describes the reachable action surface, while authorisation describes the decision to allow a specific action in a specific context. The same agent may be capable of reading, writing, calling, or chaining tools, but each of those actions still needs an explicit permission check before it is treated as acceptable behaviour.

This separation is especially important when people design agent systems around tool availability. A broad tool list can make an agent look powerful, but power and permission are not the same thing. A secure design treats tool presence, tool scope, and per-action approval as separate controls rather than one blended entitlement.

Why the distinction matters in agent design

When capability and authorisation are conflated, agents inherit ambient authority. That means the system quietly assumes that because the agent can reach a tool or dataset, it should be able to use it for any task the model produces. In practice, that is how excessive access, accidental misuse, and confused-deputy behaviour start.

Separation also helps with delegated authority. An agent can be given a technical ability, such as a scoped token or a tool interface, without being granted unlimited standing permission. That lets you narrow access to the task, time, resource, or action being requested instead of treating the agent as if it owns the underlying authority forever.

For agent systems, the most robust pattern is to evaluate each action at the moment it is requested, not at the moment the agent is deployed. That is the difference between a built-in function that exists in code and a policy decision that says the action is acceptable right now.

Where teams get the model wrong

One common mistake is to define capability at the product level and authorisation at the identity level, then assume the two are interchangeable. They are not. A tool may be installed, reachable, and technically usable, but still require a separate policy decision before the agent can invoke it for a given user, dataset, or business action.

Another mistake is to make authorisation too coarse. If every agent action is treated as equally allowed once the agent is “trusted,” the control becomes a one-time gate instead of an ongoing decision. That design makes it hard to distinguish harmless automation from actions that can change records, move money, delete data, or trigger external side effects.

Capability also needs to be understood as revocable and bounded. If a function or connector is no longer required, removing it reduces the reachable surface immediately. If permission is removed but the capability remains, you still want the policy layer to fail closed so the agent cannot act just because the code path exists.

Risk and Threat Considerations

Conflating capability with authorisation creates a direct exposure path: the agent can exercise more power than the delegation intended. That increases the blast radius of prompt injection, tool abuse, confused-deputy behaviour, and operator mistakes, especially when the agent can chain multiple tools or act across systems.

Failure mechanism: The runtime exposes a capability, then the surrounding control plane treats that existence as implicit permission, so the agent can execute an action that was never explicitly approved for that context.

Impact: The result can be unauthorised data access, unintended writes, destructive changes, or policy bypass, and those effects are harder to contain once the agent can combine several permitted primitives into an unapproved outcome.

Practitioner Guidance

What to verify: Check that your agent policy evaluates the requested action, target, and context separately from whether the tool or API is technically reachable. If the answer is “the agent has the function, so it may use it,” the control is too weak.

Decision rule: If a capability can affect production systems, customer data, or external services, require an explicit authorisation decision at runtime, not just a static build-time approval. If it cannot do material harm, you can often keep the policy lighter, but you still need a clear boundary.

Common mistake: Do not use “least privilege” as a synonym for “few tools.” A small toolset can still be over-authorised, and a larger toolset can still be safe if every action is tightly scoped, reviewed, and logged.

Practitioner takeaway: Treat capability as technical possibility and authorisation as governed permission, because secure agent design depends on checking both, independently, at the moment an action is requested.

Related resources from NHI Mgmt Group

• When is it crucial to implement least-privilege access for AI agents?
• What is the difference between managed identities and hardcoded secrets for AI agents?
• Why do AI agents make non-human identity governance harder?
• Why do AI agents create new risk in non-human identity management?