Request-Path Authorisation

How Request-Path Authorisation Works

Request-path authorisation separates proposal from permission. An agent or application can describe an intended action, but an independent policy decision determines whether that exact request is allowed before any tool call, data access, or side effect occurs.

This matters because it creates a control point between intent and execution. The authorisation layer can inspect the current context, identity, scope, requested resource, and action type, then return allow or deny without relying on the model to self-restrict.

Why It Matters for Tool and Resource Access

Request-path authorisation is most useful where a system can reach many tools, APIs, or records, but not every request should be treated equally. It is a practical way to apply least privilege at the moment of use, rather than assuming that a general-purpose agent should inherit broad standing access.

For agentic systems, this helps distinguish harmless conversation from privileged execution. A model may be able to draft a command, fetch data, or chain steps together, yet still be blocked when the request falls outside the approved path, policy, or current workflow state.

That idea aligns closely with established authorisation models, including the distinctions between role-based, attribute-based, relationship-based, and policy-based decisions described in the Authorisation Models Guide.

How It Differs from Authentication and Simple Allow Lists

Request-path authorisation is not the same as proving who or what is present. Authentication answers whether a caller is trusted to begin interacting; request-path authorisation answers whether this specific action, on this specific path, is allowed right now.

It also differs from coarse allow lists or static role grants. Static permissioning can be too broad for systems that change context rapidly, especially when tool choice, data sensitivity, user intent, or downstream side effects vary from one request to the next.

In practice, the strongest implementations pair the request-time decision with explicit ownership of access pathways, lifecycle controls, and reviewable policy rules, as reflected in the IAM and IGA Basics and the AI Agent Authorisation Guide.

Common Design Patterns and Failure Modes

Two patterns are common. One is a policy decision point that evaluates each request before a tool or resource is reached. The other is a policy enforcement point that sits between the caller and the protected action, making the decision operational rather than advisory.

Failure usually comes from mismatched granularity. If the policy only checks whether an agent is generally trusted, it may miss whether the specific tool call is sensitive, whether the data is scoped correctly, or whether the request is being made in the right task, tenant, or approval state.

Another common weakness is confusing model intent with policy approval. A model can produce a plausible rationale for an action and still be wrong, overreaching, or manipulated. Externalised controls help keep the decision anchored in policy rather than in model confidence.

The same control logic is often discussed in broader API and resource-authorisation guidance, including the Permission-Aware RAG Guide, where access checks must happen before retrieval or disclosure.

Practitioner Guidance

Governance implication: Treat request-path authorisation as a policy boundary, not a prompt-engineering feature. The important decision is whether the system can prove that an action is authorised at the point of execution, with enough context to deny unsafe requests without depending on model restraint.

What to watch for: Be careful when the same control plane must support many tools, users, and workflow states. As the action space grows, request-path policy becomes more valuable, but only if policies stay specific enough to distinguish harmless requests from privileged ones.

Practitioner takeaway: The control is strongest when the policy layer is independent, contextual, and enforceable before any side effect occurs.

Related resources from NHI Mgmt Group

• When should teams prioritise request-path controls over more AI dashboards?
• What breaks when an MCP gateway depends on external calls in the request path?
• What breaks when request-path interpreters are not tightly bounded?
• What is the difference between using one JWT and multiple JWTs in an authorisation request?