Context-based access control for MCP servers is now mandatory

At a glance

What this is: This analysis argues that Model Context Protocol environments require context-based access control because static roles and ACLs cannot safely govern AI agent requests as prompts, payloads, and goals change in real time.

Why it matters: IAM and NHI teams need a runtime authorization model that can evaluate what an agent is carrying and trying to do, not just who it is.

👉 Read Aembit's analysis of context-based access control for MCP servers

Context

Model Context Protocol changes the access problem because AI agents do not make one stable request and stop. They carry prompts, data payloads, and goals that change at runtime, so a static IAM decision can be correct at login and wrong a second later. That makes MCP a governance problem for NHI, not just an integration pattern.

The core issue is context bleed. When an authenticated agent moves through tools and handoffs, a fixed role or ACL keeps granting the same permission even when the data becomes more sensitive or the route becomes less trusted. For teams already working from the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10, that is a familiar pattern: identity alone is not enough when workloads are autonomous.

Key questions

Q: How should security teams govern AI agents that use MCP servers?

A: They should treat every MCP request as a runtime authorization event, not a static role check. Identity, payload sensitivity, request source, and target tool all need to be evaluated together. That approach reduces overprivilege, limits context bleed, and gives teams a defensible way to apply least privilege to autonomous workflows.

Q: When does RBAC become too weak for AI agent access control?

A: RBAC becomes too weak when the same agent can carry different data, goals, or trust levels through the same tool chain. At that point, role membership no longer reflects real risk. If the context changes faster than the role does, the organisation needs a context-aware policy layer above RBAC.

Q: What is the difference between static ACLs and context-based access control?

A: Static ACLs make a fixed allow or deny decision based on identity or role. Context-based access control adds runtime signals such as data sensitivity, origin, posture, and intended action. The result is a more precise decision that can change as the workflow changes, which is essential for MCP and other agentic systems.

Q: Why do MCP environments increase NHI governance risk?

A: MCP increases NHI governance risk because agents can move through tools with valid credentials while the surrounding context shifts underneath them. That creates hidden privilege expansion, especially when teams rely on one-time authentication and broad tool permissions. Governance must follow the request flow, not just the identity token.

Technical breakdown

Why static ACLs fail in MCP server environments

Static access control lists assume the request conditions stay stable from decision to decision. In MCP, the payload can change from harmless to sensitive as it moves between agents, tools, and data sources, which means a rule that looked safe at entry can be unsafe at the next hop. The problem is not authentication alone. The problem is that authorization is evaluated without enough runtime signal about what the agent is carrying, where the request came from, and whether the current action is still appropriate. That is why overprovisioning becomes the default failure mode in autonomous workflows.

Practical implication: Treat static ACLs as a coarse filter only, not as the final authorization layer for MCP traffic.

How context-based access control evaluates identity, context, and resource

Context-based access control, or CBAC, authorizes a request by combining three inputs: the agent identity, the context it carries, and the target resource. That can include sensitivity markers, request origin, data type, environment posture, and intended action. Instead of issuing one blanket allow or deny decision, the policy engine can permit, deny, redact, reroute, or require more verification. In practical terms, CBAC turns authorization into a runtime control that adapts to the current state of the workflow rather than to a precomputed role assignment.

Practical implication: Use policy logic that can change the outcome based on data sensitivity, request source, and target tool.

Why workload identity and auditability still matter in CBAC

CBAC does not replace workload identity. It depends on cryptographically verifiable identities so the policy engine can trust the source of the request before it evaluates context. It also depends on logs that preserve the identity, policy, and context used in each decision. Without that trace, teams cannot explain why access was allowed or denied, and they cannot tune policies safely. For MCP, the control plane needs both runtime verification and audit evidence, or the organisation will end up with smart policy logic and weak accountability.

Practical implication: Anchor CBAC in strong workload identity and decision logging before you try to centralise policy.

Threat narrative

Attacker objective: The attacker or malicious workflow seeks to move sensitive context through trusted tools and extract data under valid-looking access decisions.

1. Entry occurs when an authenticated agent reaches an MCP tool through a static allow rule that was designed for normal, low-risk requests.
2. Escalation happens when the same agent processes higher-sensitivity context, but the ACL does not reevaluate the changed payload or goal.
3. Impact follows when overly broad permissions let sensitive data flow into tools that were not intended to handle it.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static authorization is the wrong mental model for agentic workflows. MCP does not just increase request volume. It changes the meaning of a request because the security relevance sits in the payload, the source, and the goal as much as in the identity. Teams that keep treating authorization as a role lookup will overgrant access to preserve uptime, and that is how context leakage becomes a design choice rather than an accident. Practitioners should move from fixed permissions to runtime policy.

Context is becoming the real security boundary for AI agents. In classic IAM, the principal is the centre of gravity. In MCP, the principal is only one input, because the same agent can become safe or unsafe depending on what it is carrying. That is the shift CBAC formalises. The practical conclusion is simple: if the policy engine cannot see context classification, it cannot enforce least privilege for autonomous systems.

Identity blast radius is the right concept for MCP governance. A valid credential no longer tells you enough about risk if the surrounding context has changed. That creates a blast radius problem, where one trusted agent can move sensitive data farther than intended through otherwise legitimate hops. Teams should design to limit how far trust can travel, not just to validate who started the request.

Auditability becomes a control, not a reporting afterthought. Once authorization decisions depend on context, the evidence of why a request was allowed matters as much as the decision itself. Logging the policy inputs and the resulting action is what makes CBAC governable at scale. Without that, organisations will not be able to defend their exceptions, tune their controls, or investigate abuse with confidence.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which leaves most environments exposed to broad, static trust assumptions.
• For a broader control baseline, review OWASP Agentic Applications Top 10 for the agentic risks that make context-aware authorization necessary.

What this signals

Identity blast radius will become the practical measure of whether an MCP programme is governable. If a token, role, or service account can move across tools without re-evaluation, the access model is already too static for autonomous workflows. Teams should expect more demand for runtime policy engines, better context classification, and stronger decision logs as MCP usage expands.

With 53% of MCP servers exposing credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025, the baseline problem is not subtle. Organisations that cannot see or scope secrets will struggle even more to scope agent actions, so secret hygiene and context-aware authorization need to be built together.

The next governance step is to connect agent authorization to established identity and agentic AI guidance, including NIST SP 800-63 Digital Identity Guidelines and the OWASP Top 10 for Agentic Applications 2026. That combination gives teams a way to justify why MCP should be controlled as an identity and policy problem, not as a simple application-permission exercise.

For practitioners

• Implement context-aware policy gates Evaluate identity, data sensitivity, request origin, and target tool together before allowing MCP actions. Use deny, redact, or reroute outcomes instead of defaulting to broad allow rules.
• Classify sensitive payloads at ingestion Mark PHI, PII, financial records, and unverified user input as early as possible so downstream policy can apply the right restrictions without manual inspection.
• Limit privilege by workflow state Issue only the access needed for the current task and revoke it when the agent changes context or completes the step. Pair this with the Ultimate Guide to NHIs for lifecycle controls.
• Add decision logging for every authorization path Record the identity, policy inputs, context classification, and final action for each MCP request so exceptions can be explained and tuned later. Link logs to the 52 NHI Breaches Analysis when reviewing failure modes.
• Review agent-to-tool trust boundaries Map which agents can move data between tools, which environments they can reach, and where static ACLs still override runtime judgement. Use the OWASP Agentic Applications Top 10 to prioritise tool misuse scenarios.

Key takeaways

• MCP breaks static access control because the security meaning of a request changes as the agent’s context changes.
• Context-based access control is the right control pattern when identity alone cannot explain whether an autonomous request should proceed.
• Teams that want governable agentic systems need runtime policy, workload identity, and decision logging working together.

Key terms

• Context-based access control: A policy model that authorizes access using the request’s identity, payload, origin, and intended action together. It is designed for systems where risk changes at runtime, especially AI agents and other NHI workloads that move through multiple tools and data sources.
• Identity blast radius: The amount of damage a valid identity can do if its permissions, context, or trust assumptions are too broad. In NHI environments, blast radius is shaped by credential scope, tool reach, and whether policy is reevaluated as the workflow changes.
• Context bleed: The unintentional movement of sensitive information or trust from one step in a workflow into another step that should not receive it. In MCP and agentic systems, context bleed often appears when static access rules fail to notice that the request has become more sensitive.
• Runtime policy engine: An authorization layer that makes decisions at the moment of the request instead of relying on precomputed roles alone. It can allow, deny, redact, reroute, or require more verification based on live identity, context, and resource signals.

Deepen your knowledge

Context-based access control for MCP servers is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are translating agentic workflows into a governable access model, it is a practical place to start.

This post draws on content published by Aembit: Context-Based Access Control for MCP Servers: Why Static Rules Fail. Read the original.