TL;DR: A LangChain agent reaches an MCP gateway and LLM over a private, identity-based overlay instead of public endpoints, according to NetFoundry's demo, with X.509 identity, continuous authorization and outbound-only connectivity removing inbound exposure while preserving access. The governance shift is from network perimeter exceptions to per-connection identity control.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on NetFoundry's blog post: LangChain agents can reach MCP gateways and LLMs through identity-based overlay networking, reducing exposed endpoints and enforcing continuous authorization.
Why it matters: IAM and NHI teams should treat MCP connectivity as an identity governance problem, because public endpoints, shared access paths and shadow IT create blind spots that networking controls alone do not close.
Context
The governance gap here is simple: AI agents and MCP services are often reachable through public endpoints before identity is established. That leaves security teams relying on network controls to compensate for an access model that was never built around identity-first enforcement, especially when business pressure pushes teams toward shadow IT.
This is not just a networking concern. When an agent can reach tools, model gateways and data sources without identity-bound policy, the control plane becomes harder to audit, isolate and revoke. The right question is whether the environment can prove who or what is connecting before the connection is allowed, not after.
Key questions
Q: How should teams secure MCP-connected services behind an AI gateway?
A: They should apply the same identity, device, and policy checks to MCP-connected services that they use for the gateway itself. If the upstream tool layer is looser than the front door, the gateway only hides where the real exposure begins.
Q: Why do public AI service endpoints create identity governance risk?
A: Public AI service endpoints create identity governance risk because they often expose shared APIs, long-lived tokens, and broad service accounts that are hard to attribute to one owner or purpose. If the endpoint is reachable without tight authentication, scoping, and audit logging, access can spread across teams and agents without clear approval, review, or offboarding.
Q: How does certificate-based identity change agent access control?
A: Certificate-based identity changes agent access control by binding an agent or workload to a cryptographic certificate instead of a shared secret or password. That lets systems authenticate the calling identity, map it to an allowed service account or workload role, and revoke access by rotating or invalidating the certificate. certificate-based identity
Q: What should teams do when agent access changes in real time?
A: Teams should treat real-time agent access changes as a privileged change event and update policy, tokens, and audit records immediately. Re-scope the agent’s allowed tools, refresh or revoke credentials, and confirm the human owner or approver behind the change. JIT grants, expiry controls, and central logging help keep runtime access aligned with current authority.
Technical breakdown
Why public MCP endpoints weaken identity control
Publicly reachable MCP gateways force an allow-before-authenticate pattern. That reverses the usual trust sequence because the endpoint must be open enough to accept traffic before the identity layer can decide whether the caller should proceed. In practice, that creates exposure for tooling that sits close to business data and makes segmentation depend on ACLs, port rules and exception handling. Once agents, gateways and model services share the same reachable surface, the attack surface expands faster than governance can track it. See the MCP Security Guide.
Practical implication: Map every externally reachable MCP or AI service to the identity control that actually governs it, not to the firewall rule that merely exposes it.
How X.509 identity changes agent access decisions
An X.509 certificate gives the agent a cryptographic identity that can be evaluated before traffic flows. That matters because policy can be bound to a specific principal, service and session rather than to a network location. The important design change is not the certificate alone, but the fact that authorization can be checked continuously after enrollment, so the connection is no longer a one-time perimeter event. That shifts access control from routing state to identity state. Read Zero Trust for AI Agents.
Practical implication: Treat certificate-based enrollment as the starting point for policy enforcement, not as the end of the access decision.
Why session isolation matters for MCP tool use
MCP gateways that aggregate tools per client can reduce cross-use of capabilities when multiple agents, teams or workloads share the same environment. Session isolation limits how far one principal's access can bleed into another's request path, which is critical when tool access is tied to business context and not just to infrastructure location. Without that isolation, tool availability can become a flat permission surface that is hard to explain, test or revoke. See the MCP Gateway and MCP Server Governance Guide.
Practical implication: Separate tool access by client session so the set of available tools matches the identity and purpose of each agent.
Breaches seen in the wild
- LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
- Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity-first access is the real control boundary for MCP and AI gateways: If a service can be reached before identity is established, the organisation is still operating a network-first trust model. That model turns gateways, MCP servers and model endpoints into shared exposure points instead of governed access points. The practical conclusion is that the access boundary must move to the principal, not stay at the port.
Public endpoint exposure creates governance drift between networking and IAM: When network teams own reachability and identity teams own authorization, neither side fully owns the full decision path. That split encourages exception handling, brittle ACLs and shadow IT workarounds that are difficult to monitor. The lesson is that MCP access governance has to be designed as one control plane, not stitched together after the fact.
Continuous authorization is more important than one-time enrollment: The demo shows access disappearing immediately when an attribute is removed, which is the correct governance shape for dynamic AI workloads. Identity state must remain live after connection establishment because agent access is not a static asset. Practitioners should assume that revocation latency is a control weakness, not a nuisance.
Per-client tool aggregation should be treated as a governance concept, not just an architecture choice: Tool aggregation can either reduce or amplify privilege depending on how tightly it is bound to identity and session. The named concept here is identity-bound tool aggregation: tool sets are only safe when they are assembled and isolated according to the authenticated principal and current policy state. That is the difference between governed access and shared capability sprawl.
Zero trust for AI agents depends on eliminating standing network privilege: The overlay approach works because it removes inbound reachability and replaces it with authenticated, policy-driven sessions. That is a better fit for agentic and NHI behaviour than broad network trust zones. Practitioners should interpret this as a signal to reassess where access is currently granted by topology rather than by identity.
From our research library:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- Read next: Zero Trust for AI Agents
What this signals
Identity-bound tool aggregation: MCP governance is becoming a test of whether tool access can be assembled per authenticated principal rather than shared across the environment. If the tool set is not tied to identity and session, the platform will drift back toward flat privileges that are hard to review and harder to revoke.
The practical pressure point is revocation latency. As AI services and agents become more dynamic, security teams need access controls that respond at session time, not controls that assume a stable network location or a long-lived login state.
Zero trust for AI systems will increasingly be measured by whether the organisation can hide service location, remove standing reachability and enforce policy per connection without creating operational friction.
For practitioners
- Audit exposed MCP and LLM endpoints Inventory every agent-facing endpoint that is currently reachable through public DNS, inbound firewall rules or port forwarding, then map each one to the identity control that should govern it.
- Move authorization to connection time Require each agent, workload or service to present a cryptographic identity before the first request is accepted, and ensure policy is evaluated at session start as well as during the session.
- Separate tool access by principal and session Assign tool sets per authenticated client so one agent cannot inherit or reuse another agent's access path, even when both consume the same MCP service.
- Remove stale access attributes immediately Test whether deleting an identity attribute or policy binding actually cuts off live access without waiting for manual intervention, cache expiry or network reconfiguration.
Key takeaways
- Publicly reachable MCP and LLM services create an identity governance problem as much as a network exposure problem.
- The demo's core security signal is continuous authorization, not one-time enrollment, because agent access can change mid-session.
- Per-client tool isolation and identity-bound sessions reduce the chance that agent capabilities turn into shared privilege sprawl.
Related NHI Mgmt Group resources: MCP Security Guide · Zero Trust for AI Agents · MCP Gateway and MCP Server Governance Guide · OWASP Agentic Applications Top 10
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent access is governed through identity, privilege and session state in this demo. |
| Recommendation — Bind agent privileges to authenticated identity and revoke access when policy changes. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The demo centres on cert-based identity and authenticated access for non-human actors. |
| NHI-05 — Overprivileged NHI | Per-client tool aggregation can drift into excess privilege without tight identity scoping. | |
| Recommendation — Require strong NHI authentication before any MCP or LLM session is established. Scope each agent's tool access to the minimum set needed for its current session. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Continuous authorization and attribute-based revocation map directly to access permission control. |
| Recommendation — Enforce identity-bound permissions and remove access immediately when policy changes. | ||
| NIST Zero Trust (SP 800-207) | 5.3 — Policy Continuity and Trusted Channels | The overlay model emphasizes policy-enforced sessions and trusted communication paths. |
| Recommendation — Apply zero trust policy to each AI connection instead of trusting the network path. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Exposed MCP and LLM endpoints can be used to reach data and move between services. |
| Recommendation — Map exposed endpoints to credential access and lateral movement hunt scenarios. | ||
Key terms
- MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
- X.509 Certificate: A digital certificate standard used to verify the identity of machines, services, and workloads in TLS/SSL connections. Certificates have expiry dates and must be rotated before expiry to avoid outages and security gaps.
- Identity-Bound Tool Aggregation: Identity-Bound Tool Aggregation is a control pattern where an agent’s tool set is grouped and authorised against a specific identity, such as a service account or workload identity. Each tool call is evaluated against that bound identity, so access scope, approval and revocation follow the agent’s assigned authority rather than a shared system-wide token.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org