TL;DR: MCP is emerging as a standard way for AI systems and agents to reach enterprise data, but static credentials, limited session controls, and weak auditability leave material governance gaps, according to Teleport’s analysis of AI infrastructure security. The central issue is that agentic access behaves more like identity delegation than application integration, so existing IAM assumptions break quickly.
NHIMG editorial — based on content published by Teleport: Securing Model Context Protocol (MCP) with Teleport and AWS
Questions worth separating out
Q: How should security teams govern AI agents that access enterprise data through MCP?
A: Treat the agent, connector, and downstream credential path as one identity surface.
Q: Why do static credentials create more risk in MCP deployments?
A: Static credentials create standing access that outlives the specific task the AI is performing.
Q: What do teams get wrong about AI access logs?
A: They often log connectivity but not enough context to prove what the AI touched or why.
Practitioner guidance
- Inventory every MCP-connected AI access path Map each AI system, MCP server, database connector, and cloud service it can reach.
- Replace persistent secrets with short-lived identities Eliminate static API keys and long-lived passwords where the workflow allows it.
- Bind audit logs to identity and task context Require logging that captures which AI identity accessed which resource, under what policy, and for what business context.
What's in the full article
Teleport's full blog covers the operational detail this post intentionally leaves for the source:
- How its infrastructure identity model maps humans, workloads, and AI systems into one policy layer
- Implementation guidance for replacing static MCP secrets with ephemeral credentials and mutual TLS
- Audit design details for capturing AI identity, accessed resources, and business context in one trail
- A step-by-step roadmap for securing AI-driven database access across enterprise environments
👉 Read Teleport's analysis of securing MCP and AI-driven database access →
MCP and AI agents: what identity controls are still missing?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
MCP exposes an identity governance problem before it exposes an application problem. The protocol is often discussed as a connectivity layer, but the real security failure is that it creates new delegated access paths without a corresponding governance model. When AI systems can touch enterprise resources through reusable connectors, identity becomes the control plane, not the model layer. Practitioners should read MCP deployments as a test of whether their NHI programme can govern dynamic, machine-driven access with the same rigour applied to privileged human access.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, 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, according to AI Agents: The New Attack Surface report.
A question worth separating out:
Q: How do MCP-based AI systems change zero trust assumptions?
A: They shift the trust boundary from user login to machine-mediated delegation. Zero trust still applies, but the control point moves to authentication, authorization, and revocation around the connector and its credentials. Teams need to verify every request, not assume the workflow is safe because the model is inside the perimeter.
👉 Read our full editorial: Securing MCP with identity governance for agentic AI access