Notifications
Clear all
Topic starter
09/06/2026 11:01 pm
TL;DR: MCP standardises how AI systems connect to tools and data, but the real shift is in identity and authorization: agents need delegated, scoped access, session continuity, and runtime policy checks, according to Cerbos. The practical lesson is that AI integrations fail or succeed on governance assumptions, not just protocol design.
NHIMG editorial — based on content published by Cerbos: discussion of MCP, AI agents, and authorization design
Questions worth separating out
Q: How should security teams govern AI agents that use MCP tools?
A: Security teams should govern MCP-enabled agents as delegated identities with action-level limits, not as trusted extensions of the user.
Q: Why do AI agents complicate existing IAM controls?
A: AI agents complicate IAM because the request path is no longer a single human login followed by static app access.
Q: What breaks when an AI agent is given a blanket token?
A: A blanket token breaks least privilege by allowing the agent to use more rights than the task requires, and it breaks accountability because the resulting actions are hard to distinguish from broader app use.
Practitioner guidance
- Define agent-scoped authorization boundaries Map each MCP tool to a specific action class, data class, and risk tier so the agent never inherits broad application rights by default.
- Issue short-lived delegated credentials Use task-bound tokens with narrow scopes and clear expiry so the agent can complete the requested workflow without durable standing access.
- Enforce policy checks at execution time Place a policy decision point in front of every tool invocation so allow, deny, and step-up outcomes happen before the action executes.
What's in the full article
Cerbos's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step identity and authorization flow for an MCP client acting on behalf of a user
- How transaction tokens and consent screens are expected to work in practice
- Policy-engine patterns for enabling, denying, or step-up gating agent tool calls
- Implementation details for logging agent actions and reconnecting streaming sessions
👉 Read Cerbos's discussion of MCP, AI agents, and authorization design →
MCP for AI agents: what changes for identity and authz?
Explore further
10/06/2026 1:13 am
Blanket app tokens are the wrong mental model for AI agent access: MCP turns a one-shot integration into a delegated action chain, so the access question is no longer whether an app can connect, but what the agent can do at each step. The article shows why scopes, consent, and transaction limits need to be expressed per action, not per integration. Practitioners should treat every agent session as a bounded delegation event, not a durable entitlement.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: What frameworks should teams use to control MCP and agent access?
A: Teams should combine zero-trust authorization, NHI governance, and agent-risk guidance such as OWASP Agentic Applications Top 10. The practical test is whether each tool invocation is checked against identity, scope, and context before execution, with logs detailed enough to support review and incident investigation.
👉 Read our full editorial: MCP changes identity and authorization for AI agent workflows
