Notifications
Clear all
Topic starter
24/06/2026 10:50 pm
TL;DR: Claude Enterprise extends developer permissions into agentic workflows, so broad local access, static MCP keys, OAuth scope abuse, and prompt injection can all magnify identity risk inside daily operations, according to P0 Security. The real failure is assuming AI assistance inherits safe limits from human workflows; once the agent mirrors standing privilege, those limits disappear.
NHIMG editorial — based on content published by P0 Security: Anthropic’s Claude Enterprise by Neha Duggal
By the numbers:
- 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 agents that inherit developer permissions?
A: Treat the host account as the real control plane.
Q: Why do AI agents complicate least privilege in IAM programmes?
A: Because least privilege is usually defined at provisioning time for a stable human or service account.
Q: What do security teams get wrong about MCP server access?
A: They often treat connectors as lightweight integrations instead of identity-bearing trust paths.
Practitioner guidance
- Rebase developer access before enabling agents Remove standing admin rights, narrow repo and cloud permissions, and make agent execution depend on the least-privileged human account available.
- Register every MCP server and connector Document the authentication method, token type, data scope, and owner for each integration.
- Keep human confirmation on sensitive actions Require approval for secret access, production changes, and data movement that an agent can trigger from untrusted content.
What's in the full article
P0 Security's full analysis covers the operational detail this post intentionally leaves for the source:
- How Claude Code behaves across local user context, confirmed operations, and auto-approve settings
- Specific examples of MCP server authentication patterns and where static API keys create standing privilege
- Practical guidance for reviewing role explosion, managed settings, and auditability in AI-enabled workspaces
- Lifecycle handling for joiners, movers, and leavers when AI access is tied to developer accounts
👉 Read P0 Security's analysis of Claude Enterprise identity risk →
Claude Enterprise identity risk: are your IAM controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 7:40 am
Claude Enterprise does not create a separate trust domain when it inherits developer identity. The agent operates inside the same OS-level context as the user, so the security model is still anchored to the developer's standing privileges. That means the governance question is not whether the AI is clever enough to be safe, but whether the underlying human account was ever appropriate for machine reuse. Practitioners should treat the developer workstation as a privileged execution environment, not a neutral workspace.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
A question worth separating out:
Q: Who is accountable when an AI agent exfiltrates sensitive data?
A: Accountability sits with the organisation that allowed the agent to inherit broad access and with the team that approved the connector and oversight model. If the workflow can move secrets or production data without durable auditability, the governance failure is in access design, not only in model behaviour.
👉 Read our full editorial: Claude Enterprise exposes a new identity attack surface for IAM
