Notifications
Clear all
Topic starter
04/06/2026 3:00 pm
TL;DR: Agentic workflows are turning AI clients into a distinct identity governance problem, with runtime access, MCP connectivity, and auditability now central to enterprise control design, according to Strata Identity. The editorial point is clear: conventional IAM assumptions break once software begins selecting tools and actions dynamically.
NHIMG editorial — based on content published by Strata Identity: Agentic Identity and MCP governance for workforce AI clients
Questions worth separating out
Q: How should security teams govern AI clients that use MCP to reach enterprise tools?
A: Security teams should treat MCP-connected AI clients as governed identities with explicit scope, owner, and revocation controls.
Q: Why do AI clients complicate traditional IAM models?
A: AI clients complicate IAM because their access is not always static or fully predictable at provisioning time.
Q: What do security teams get wrong about agentic identity?
A: The common mistake is assuming an AI client can be governed like a normal service account with one stable use case.
Practitioner guidance
- Classify AI clients as governed identities Assign each AI client an explicit identity owner, access purpose, and revocation path before it is connected to enterprise tools.
- Enforce policy at MCP boundaries Require identity assertion, scope checking, and audit logging at the MCP server or gateway rather than relying on downstream tools to interpret agent intent.
- Replace shared secrets with delegated access Remove hardcoded tokens and reused credentials from agent workflows wherever federation or short-lived delegation is possible.
What's in the full article
Strata Identity's full article covers the operational detail this post intentionally leaves for the source:
- A step-by-step tutorial for connecting AWS Bedrock AgentCore to an OAuth-protected MCP server.
- A practical example of federated identity for workforce AI clients inside Maverics.
- A technical build log showing how an AI agent identity gateway enforces runtime policy and visibility.
- A discussion of agentic sprawl and why AI client identities can outnumber human identities quickly.
👉 Read Strata Identity's analysis of agentic identity and MCP access control →
Agentic identity governance for AI clients: are your controls ready?
Explore further
04/06/2026 3:12 pm
Agentic identity is now a distinct governance category, not a variant of service identity. The article shows why AI clients with tool access cannot be managed as ordinary workload identities once they begin selecting actions at runtime. That changes the control problem from simple authentication to delegated authority, traceability, and constrained execution. Practitioners should treat these clients as a separate governance class with their own lifecycle and review model.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 44% of organisations have implemented policies to govern AI agents, even though 92% agree that agent governance is critical to enterprise security.
A question worth separating out:
Q: How can organisations reduce risk from AI clients without blocking adoption?
A: Organisations should reduce risk by removing shared secrets, narrowing tool scopes, and making delegation reviewable. That lets AI clients operate with less standing privilege while still preserving business value. The goal is not to stop agent use, but to make every access path attributable and revocable.
👉 Read our full editorial: Agentic identity governance for AI clients is becoming an IAM problem
