Notifications
Clear all
Topic starter
02/09/2026 3:57 pm
TL;DR: MCP and agent adoption are exposing a gap in traditional IAM: authenticating the user behind an agent does not control which tools the agent can call, what arguments it can pass, or what data can flow back, according to Highflame. The real requirement is policy and inspection at the tool layer, because authentication alone cannot govern agent behaviour.
NHIMG editorial — based on content published by Highflame: MCP server security needs policy control beyond user authentication
Questions worth separating out
Q: How should security teams govern managed MCP access for AI clients?
A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task.
Q: Why do authenticated agents still create security risk in MCP environments?
A: Authenticated agents still create risk because authentication only proves that a subject entered the system.
Q: What are the signs that MCP session controls are failing?
A: Warning signs include permissions carrying over between sessions, inconsistent approval behaviour, and tool calls appearing in an order that does not match the intended workflow.
Practitioner guidance
- Implement tool-level authorisation checks Evaluate every MCP call against principal type, tool name, target resource, and contextual rules before forwarding the request.
- Separate user identity from agent authority Model the human user and the acting agent as distinct decision inputs so that delegated access can be narrowed without assuming the user token is sufficient.
- Inspect tool arguments before execution Scan payloads for prompt injection, SQL injection, shell commands, and other malicious patterns before backend systems receive them.
What's in the full article
Highflame's full analysis covers the operational detail this post intentionally leaves for the source:
- Examples of policy rules for tool execution, including principal type, action, and resource context.
- The inspection layer needed to catch prompt injection, malicious payloads, and unsafe tool responses.
- The practical distinction between user authentication and agent authorisation in MCP architectures.
- How teams can model destructive actions such as exports, admin changes, and transfers as governed workflows.
👉 Read Highflame's analysis of MCP security beyond user authentication →
MCP tool calls: are your access controls keeping up?
Explore further
02/09/2026 3:58 pm
Identity authentication is the wrong control boundary for MCP. MCP requests can be user-authenticated and still be wrong, because the agent selects the tool and timing at runtime. That means the real boundary is tool authorisation, not session authentication, and the governance model has to move with the action surface. Practitioners should treat the authenticated user as only one input to the decision, not the decision itself.
A few things that frame the scale:
- 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 tool calls governed by authentication alone.
A question worth separating out:
Q: What should organisations do immediately when an MCP tool can modify data or infrastructure?
A: Organisations should require an explicit deny-by-default rule for high-risk tools and then add approval or step-up checks before any destructive or infrastructure-changing action can run. That should be paired with argument inspection and response filtering so a valid agent session cannot silently convert into a high-impact change operation.
👉 Read our full editorial: MCP server security needs policy control beyond user authentication
