Notifications
Clear all
Topic starter
06/07/2026 9:39 am
TL;DR: The bigger issue is that identity governance now has to account for agent-driven access to security workflows, not just machine identities themselves, according to Token Security, whose MCP server for non-human identities lets teams query inventory, surface risk, and generate remediation guidance through natural language, while also linking AI assistants to actions such as ticketing and notifications.
NHIMG editorial — what this means for AI and NHI governance
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams govern AI assistants that can query and act on NHI data?
A: Security teams should treat AI assistants as delegated actors with named scopes, approval boundaries, and audit requirements.
Q: Why do MCP-connected workflows increase identity risk for NHI programmes?
A: MCP-connected workflows increase risk because they let an AI layer discover tools and act on identity data in ways that are harder to reason about than static integrations.
Q: What do security teams get wrong about AI-powered remediation for NHIs?
A: Teams often assume that faster remediation is automatically safer.
Practitioner guidance
- Define MCP tool scopes as identity entitlements Catalogue every MCP tool, resource, and prompt exposed to AI assistants, then assign explicit owners, purposes, and approval requirements for each path.
- Separate read access from execution paths Keep investigative queries, remediation script generation, and state-changing actions in different permission tiers.
- Instrument delegated actions end to end Log the prompt, tool call, returned context, and downstream action for every AI-assisted identity workflow.
What's in the full announcement
Token Security's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how the MCP server turns plain-language prompts into Token-specific operations.
- Demonstrations of customer-specific remediation guidance, including scripts and CLI commands for identity fixes.
- Use cases showing how the interface identifies owners, prioritises inactive identities, and surfaces cross-cloud relationships.
- Walkthroughs of agent-driven workflows that generate tickets, notify stakeholders, and follow up on unresolved issues.
👉 Read Token Security's analysis of its MCP server for NHI security →
MCP for NHI security: are your controls ready for agent-driven queries?
Explore further
06/07/2026 9:55 am
MCP turns NHI governance into a protocol problem, not just an identity problem. Once an AI model can discover tools and move from context to action, the security boundary shifts to what the protocol exposes and how much trust the server grants. That means traditional NHI inventory controls are necessary but insufficient on their own. Practitioners should treat MCP exposure as part of the identity attack surface.
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.
- Only 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
A question worth separating out:
Q: How do organisations know if agentic identity workflows are safe enough to use?
A: Look for three signals: every tool has a named owner, every state-changing action has an approval boundary, and every AI-assisted step is logged well enough to reconstruct the chain of decisions. If any of those are missing, the workflow may be efficient, but it is not yet governable.
👉 Read our full editorial: MCP for NHI security changes how teams query and remediate risk
