Notifications
Clear all
Topic starter
06/06/2026 1:53 am
TL;DR: AI agents connected through MCP are taking actions across internal systems with elevated privileges, while organisations still struggle to monitor granted versus used access, according to Oasis Security. The governance gap is not technical novelty but identity scope, ownership, and logging that were built for slower, human-paced access models.
NHIMG editorial — based on content published by Oasis Security: A real security challenge behind this artificial intelligence
By the numbers:
- LLMs are used by over 90% of fortune 500 companies, according to Oasis Security.
- The MCP repository has already been forked over 4,000 times, according to Oasis Security.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to NHIMG research.
Questions worth separating out
Q: How should security teams govern AI agents that use MCP to access internal systems?
A: Security teams should govern MCP-connected AI agents as privileged non-human identities with owners, scoped permissions, and usage logging.
Q: Why do AI agents complicate least-privilege design in IAM programmes?
A: AI agents complicate least privilege because their runtime actions can vary by context, data, and tool availability.
Q: What breaks when AI agents are connected through personal accounts or shared credentials?
A: Shared or personal credentials break accountability, lifecycle control, and revocation.
Practitioner guidance
- Inventory every AI-connected identity Create a complete register of AI agents, MCP servers, and third-party integrations with source, owner, data touchpoints, and production status.
- Compare granted permissions to actual use Review each agent or integration for the permissions it was given versus the actions it actually performs.
- Separate personal accounts from machine access paths Block the practice of wiring AI services through personal OAuth accounts or developer credentials.
What's in the full article
Oasis Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Examples of how AI agents are connected to CRMs, cloud services, and ITSM platforms in live environments.
- Step-by-step guidance for identifying ownership, business justification, and privilege scope for each integration.
- The article's checklist for inventorying, permission analysis, behaviour monitoring, and secure self-service access.
- Specific examples of how developers can accidentally expose credentials in configuration files and repositories.
👉 Read Oasis Security's analysis of AI agent and MCP identity risk →
AI agent and MCP identity risk - are your controls keeping up?
Explore further
06/06/2026 3:15 am
AI agents are becoming privileged non-human identities before most organisations have built governance for them. The article shows that agents are being granted access to internal systems with elevated permissions and minimal oversight. That places them squarely in the NHI governance problem space, not in a separate AI-only category. The practical conclusion is that identity teams must classify these workloads as governed identities, not experimental tools.
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, which means secret handling remains a common exposure path.
A question worth separating out:
Q: How do organisations know whether AI identity monitoring is actually working?
A: Monitoring is working when teams can see which agent initiated each action, which tool was used, what data was touched, and whether the sequence matches the approved purpose. If logs show activity but cannot connect it to an owner, workflow, and entitlement set, the programme still has a visibility gap.
👉 Read our full editorial: AI agent and MCP identity risk outpaces enterprise IAM controls
