“Can use the MCP server” is a surprisingly large permission when the server exposes search, file writes, process launch, messaging, and administrative configuration.
Break that permission into the actions an operator can explain.
Start with three users
Consider a fictional reporting service used by an analyst, a release agent, and a platform administrator. All three can authenticate. Their jobs require different actions:
| Action | Analyst | Release agent | Platform administrator |
|---|---|---|---|
| Read approved reports | Scoped access | If needed | If needed |
| Publish a release artifact | Deny | Approved release only | Separate release policy |
| Register an MCP server | Deny | Deny | Reviewed change |
| Run arbitrary shell commands | Deny | Deny | Separate controlled capability |
This is an example policy, not a universal role model. Its purpose is to expose decisions hidden by a connection-level allow rule.
The LiteLLM findings and Bifrost registration issue make the stakes tangible. Administrative operations can select code, routes, and tool processes with much more authority than ordinary API use.
Evaluate the resolved action
A policy decision needs the authenticated principal, tenant, tool, target resource, sensitive arguments, environment, and approval state.
Evaluate those after defaults and aliases have been resolved. A tool named “export report” may accept an external destination. The destination determines whether the action keeps data within the organization or sends it elsewhere.
Use resource constraints as well as tool permissions. A user allowed to read one project should not be able to substitute another project's identifier.
Put approval where the consequence changes
Process launch, package installation, external messages, and administrative changes often deserve additional review. Make the approval identify the concrete action, resource, and recipient.
An approval for one message should not become a permanent grant to send any message. An approval for one server artifact should not silently cover its replacement.
The model can propose an action and supply context. Enforce the permission in application or infrastructure code before the side effect begins.
Give denials an operational use
Record rejected calls with enough context to explain the rule, while redacting secrets. Repeated attempts to use a forbidden capability may indicate malicious instructions, an overly broad tool contract, or a legitimate workflow that needs a better permission.
Use those findings to improve policy. A useful authorization system makes both successful and denied behavior understandable.