Notifications
Clear all
Topic starter
25/06/2026 2:44 pm
TL;DR: MCP servers create a new attack surface where prompt injection, spoofed identities, tool abuse, and context tampering can expose sensitive data without password theft, according to Aembit. The security assumption that identity is enough at authentication time is too weak for AI workflows that decide and act through trusted context.
NHIMG editorial — based on content published by Aembit: MCP server security for AI agents and identity controls
Questions worth separating out
Q: How should security teams govern MCP servers in agentic workflows?
A: Security teams should govern MCP servers as identity enforcement points, not simple integration middleware.
Q: Why do encrypted MCP channels still leave AI agents exposed?
A: Encrypted channels stop eavesdropping, but they do not stop context manipulation, spoofed endpoints, or unsafe tool invocation.
Q: What do teams get wrong about least privilege for AI agents?
A: They often apply least privilege at the account level and stop there.
Practitioner guidance
- Enforce tool-level policy at the MCP server boundary Define which agents can invoke which tools, under what attributes, and with which parameter limits.
- Validate and isolate all context before agent consumption Sanitize structured fields, reject malformed payloads, and clear session memory at the end of each interaction.
- Bind workload identity to short-lived credentials Use verified workload attributes, short validity periods, and audience-scoped tokens so one credential cannot be replayed across servers.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step transport hardening guidance, including TLS 1.3, mTLS, DPoP, and selective certificate pinning for exposed MCP servers
- Practical examples of context sanitization, session isolation, and anomaly detection rules for agent-server traffic
- Authorization design guidance for tool scoping, parameter validation, rate limits, and audit logging across MCP sessions
- Deployment considerations for workload identity, short-lived credentials, and secretless patterns in production environments
👉 Read Aembit's analysis of MCP server security for AI agents and identity controls →
MCP server security: what it means for IAM and NHI teams?
Explore further
25/06/2026 3:51 pm
MCP security is now an identity governance problem, not a transport problem. The moment a server brokers tool calls, the security boundary shifts from packet inspection to control of who may act, what they may access, and which context they are allowed to trust. Encryption is necessary, but it does not govern intent, tool scope, or session-level abuse. Practitioners should treat MCP as part of the identity plane, not a separate integration layer.
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.
- Another finding from the same research shows that only 18% of MCP server deployments implement any form of access scoping for tool permissions.
A question worth separating out:
Q: Who is accountable when an agent leaks data through an MCP server?
A: Accountability sits with the teams that defined the trust boundary and the controls that failed to enforce it, usually identity, platform, and security owners together. If tool authorization, context validation, or monitoring was missing, the breach is a governance failure, not just a runtime incident. Shared ownership must be explicit before deployment.
👉 Read our full editorial: MCP server security is now an identity governance problem
