Notifications
Clear all
Topic starter
21/08/2026 5:02 pm
TL;DR: Model Context Protocol gives AI systems direct access to enterprise tools and data, but AccuKnox argues that without identity-first controls, it creates privilege escalation, data exposure, and audit gaps across AI-driven workflows. The governing assumption fails because MCP connectivity does not equal authorisation, and AI sessions need the same scoped, traceable access discipline as human users.
NHIMG editorial — based on content published by AccuKnox: Securing MCPs. Why AI infrastructure needs identity-first access control
By the numbers:
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: What breaks when AI agents use MCP without strong scope enforcement?
A: Least privilege breaks in practice because the agent can execute far more than the business task requires.
Q: Why do MCP deployments complicate NHI governance?
A: MCP connects agents to tools in a way that can blur the line between a legitimate workload request and an uncontrolled execution path.
Q: How do teams know whether MCP permissions are actually under control?
A: Look for separate read and write entitlements, explicit per-tool scoping, and complete logs for both permitted and denied actions.
Practitioner guidance
- Scope every MCP server to a named identity Bind each AI session to a verifiable identity with explicit tool permissions, resource limits, and revocation rules.
- Replace long-lived secrets with short-lived session credentials Use certificates or tokens that expire quickly and are tied to the exact AI task, then revoke them automatically when the session ends.
- Enforce request-level policy before any tool call executes Evaluate the requested action, the actor context, and the target resource in real time so the AI cannot exceed its intended scope.
What's in the full article
AccuKnox's full article covers the operational detail this post intentionally leaves for the source:
- Detailed policy flow for prompt firewalling and response sanitisation across MCP-connected workflows
- Implementation guidance for short-lived certificates, request validation, and immutable audit logging
- Examples of how the control stack is integrated with CSPM, CWPP, and Kubernetes runtime protection
- Compliance mapping detail for NIST AI RMF, EU AI Act, and OWASP AI Top 10
👉 Read AccuKnox's analysis of securing MCP with identity-first access control →
MCP security and AI identity control: are your guardrails ready?
Explore further
21/08/2026 5:17 pm
MCP security is an identity problem before it is a protocol problem. The architectural failure is assuming that a functional connector can safely inherit trust from the model or the surrounding platform. In reality, MCP turns tool access into a privileged control plane, so authorisation, scoping, and traceability must exist at the session boundary, not only in the backend systems. Practitioners should treat MCP as a governed identity path, not a neutral integration layer.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to the State of MCP Server Security 2025.
- Another finding from the same research shows that 53% of MCP servers expose credentials through hard-coded values in configuration files.
A question worth separating out:
Q: Who is accountable when an AI agent takes action through an MCP server?
A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.
👉 Read our full editorial: Model Context Protocol security needs identity-first access control
