Notifications
Clear all
Topic starter
15/08/2026 6:13 pm
TL;DR: OAuth still works for delegated API access, but it breaks down when MCP-based AI agents plan and act across multiple tools with context-dependent permissions, according to Britive. Static scopes cannot express action-level intent, so practitioners need runtime authorization, short-lived access, and tighter guardrails around agent behaviour.
NHIMG editorial — based on content published by Britive: When Agents Act, OAuth Isn’t Enough: Securing MCP With Runtime Authorization
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
Questions worth separating out
Q: How should teams secure MCP authorization beyond OAuth scopes?
A: Teams should use OAuth scopes only as a coarse capability layer and enforce the real authorization decision on the server.
Q: Why do MCP agents make static access scopes risky?
A: Because agents can sequence multiple tools in one task, and the needed permissions change as the task unfolds.
Q: What breaks when organizations treat OAuth token issuance as the final control?
A: They lose action-level governance.
Practitioner guidance
- Separate transport from authorization Keep OAuth as the delegated transport mechanism, but place a runtime policy layer in front of every tool and resource decision.
- Scope permissions to the action, not the session Grant the smallest usable permission for a specific resource and revoke it automatically after completion.
- Map non-API resources into the same governance model Extend policy coverage to databases, file systems, data warehouses, and object storage so MCP does not become a side channel around your API controls.
What's in the full article
Britive's full analysis covers the operational detail this post intentionally leaves for the source:
- A concrete runtime authorization pattern for MCP workflows that spans agent decisions, tool access, and revocation timing.
- Examples of how to layer policy across APIs, databases, and file systems without relying on static OAuth scope design.
- The practical distinction between delegated transport tokens and the real authorization decision for agent actions.
- Guidance on combining on-behalf-of boundaries with human approval for higher-risk access requests.
👉 Read Britive's analysis of runtime authorization for MCP agent access →
MCP runtime authorization: are your agent controls keeping up?
Explore further
15/08/2026 6:20 pm
Runtime authorization is the correct control plane for MCP agents, not OAuth alone. OAuth answers whether a client may use an API on behalf of a user. It does not answer whether an agent should be allowed to take the next action, on the next tool, against the next resource, under the current task context. That gap becomes visible as soon as the actor can chain decisions across multiple systems. Practitioners should stop treating token issuance as the final authorization event.
A few things that frame the scale:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
- 97% of NHIs carry excessive privileges, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when an MCP client grants access too broadly?
A: Accountability sits with the team operating the client, the server, and the authorization policy, because MCP failures usually come from broken relationship handling rather than a single bad request. Security and platform teams should document who owns consent registration, token validation, and local execution restrictions.
👉 Read our full editorial: Runtime authorization for MCP agents: why OAuth alone falls short
