TL;DR: Agentic AI shifts identity from passive prompt handling to runtime action, multi-step delegation, and tool use across LLMs, MCP servers, and downstream services, creating authentication and authorization gaps that current IAM patterns do not fully cover, according to Aembit. The core problem is not just stronger auth, but governance built on assumptions that no longer hold once agents decide, act, and recompose permissions dynamically.
At a glance
What this is: This article explains how agentic AI turns authentication into a runtime governance problem across agents, MCP servers, and services, with dynamic permissions and delegation breaking older IAM assumptions.
Why it matters: IAM teams need to rethink how identities, scopes, and accountability work when software can plan, choose tools, and change the permission set it needs during execution.
Context
Agentic AI changes the identity problem because the software no longer only responds to prompts. It can plan, choose tools, and act across multiple services, which means authentication and authorisation are no longer static setup tasks but part of the runtime control surface for NHI and emerging agentic workloads.
The article also shows why Model Context Protocol matters to identity teams. MCP standardises how agents discover and call tools, but that standardisation shifts attention to trust boundaries, delegated access, and how much privilege a running agent should inherit when it calls into downstream services.
Key questions
Q: What breaks when agentic AI relies on static IAM assumptions?
A: Static IAM breaks when the system can decide new steps at runtime. In agentic flows, the necessary scopes may not be known until the agent inspects a task, calls a tool, or chains into another service. That makes fixed permission modelling incomplete and creates gaps between design-time approval and actual execution.
Q: Why do agent and service delegation chains create authorisation risk?
A: Because each hop can change the acting identity. If an MCP server or downstream service uses its own credentials instead of the original user or agent context, accountability becomes fragmented and permissions can broaden unintentionally. The risk is highest when heterogeneous systems cannot preserve the same delegation semantics end to end.
Q: How should security teams govern MCP tool access in enterprise environments?
A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools. A gateway can enforce policy at the edge, but governance only exists when the identity system knows who is calling, what they are allowed to do, and whether approval or offboarding has already occurred.
Q: When should organisations avoid inheriting user permissions into agent actions?
A: When the action can become broader than the original user request, especially if the agent can write, create, or update records after starting from a read-only intent. In those cases, inheriting the user’s permissions can hide the real decision-maker and let the agent exceed the scope that would be acceptable on its own.
Technical breakdown
Why agentic AI turns authentication into runtime delegation
Traditional applications usually authenticate once and then execute within a known scope. Agentic systems behave differently because the agent may decide which tool to use next, which service to call, and whether the next step is read-only or write-enabled. That means the permission set cannot always be fully known at design time. The article’s core technical point is that authentication, authorisation, and delegation converge inside the agent loop, especially when the agent chains actions across MCP servers and downstream services.
Practical implication: Model permissions around runtime decision points, not only around initial login or static app registration.
How MCP changes trust boundaries between agents and services
MCP standardises how a client discovers server capabilities and presents them to the LLM, which removes a lot of bespoke integration work. It does not remove the need to authenticate each boundary. The article shows three distinct trust boundaries: application to LLM API, MCP server to service, and MCP client to MCP server. The last one is especially important because many deployments run the server locally with no authentication, use shared secrets, or rely on early OAuth 2.1 implementations that are still uneven in practice.
Practical implication: Treat MCP server discovery and local execution as security-sensitive boundaries, not as an implementation convenience.
Why delegation breaks when technology stacks do not line up
Delegation works cleanly only when each hop can act on behalf of the original caller. The article highlights the familiar problem that downstream services often end up using their own identity rather than the upstream user or agent identity, especially when protocols or systems do not share a common authorisation model. That creates ambiguity in accountability and makes least privilege harder to preserve across an action chain. In agentic environments, this is not a corner case but a structural feature of mixed protocol estates.
Practical implication: Map where delegated identity stops and service identity begins before allowing agents to cross tool and system boundaries.
NHI Mgmt Group analysis
Runtime permission discovery is the new identity risk surface: Agentic systems do not merely consume permissions, they discover them while they work. That breaks the older assumption that least privilege can be completely specified before execution begins. The implication is that identity governance has to account for permission emergence during task execution, not just provisioning time.
Delegation chains now outlive the identity model that created them: Once an agent calls an MCP server, and that server calls a service, the chain may no longer preserve the originating subject in a meaningful way. This is not just an implementation detail. It means accountability, auditability, and authorisation context can fragment as soon as protocol boundaries shift. Practitioners need governance models that track where the acting identity changes.
Agentic AI authentication exposes a runtime governance gap: Least privilege was designed for software whose access pattern was largely knowable in advance. That assumption fails when the actor decides mid-session which tools to invoke and what new permissions are needed. The implication is that identity teams must rethink how they define and attest to scope when the scope itself is conditional on the agent’s next step.
MCP standardisation improves interoperability but also normalises capability expansion: A uniform way to publish tools to agents makes integration easier, yet it also makes privilege expansion easier to operationalise at runtime. That makes identity review, service registration, and boundary enforcement more important, not less. Practitioners should treat capability discovery as a governed event, not just a developer convenience.
Hybrid user-and-agent action paths create unresolved accountability: The article’s HR example shows how a benign read request can become a destructive write. That is the right warning sign for the field: the hardest problem is no longer whether access exists, but whose intent and identity should govern the action. Identity programmes need a policy model for blended agency before scale forces one into production.
From our research library:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Identity Guide
What this signals
Agentic AI authentication is no longer just about proving who started the session. The programme question is whether identity governance can still hold when permissions are discovered, expanded, and executed inside the same runtime path.
Runtime delegation gap: This is the place where many IAM programmes will discover that their review cadence, approval chain, and token strategy were built for stable software, not for actors that can negotiate scope as they move. Teams should prepare for blended user-and-agent workflows to become a normal governance case rather than an edge case.
For practitioners
- Define runtime delegation boundaries Map where the agent acts under its own identity, where it inherits user context, and where downstream services must not receive implicit trust. Make that map part of design review for every new tool integration.
- Classify MCP trust boundaries explicitly Document the authentication method, token type, and approval model for application to LLM API, MCP client to MCP server, and MCP server to service flows. Do not allow local execution paths to bypass review.
- Separate discovery from authorisation Treat tool discovery as capability exposure, not as permission grant. Limit which tools are visible to the agent, and make scope changes require a controlled governance step rather than silent runtime expansion.
- Audit blended user-and-agent actions Identify workflows where a user request can trigger agent-initiated writes, updates, or object creation. Require a policy decision on whether the user, the agent, or both own the resulting action.
Key takeaways
- Agentic AI pushes authentication and authorisation into the runtime path, where agents can choose tools and alter their scope during execution.
- MCP makes service integration more consistent, but it also turns capability discovery and delegated access into governed trust boundaries that teams must watch closely.
- The key control question is no longer whether access exists, but how to preserve accountability when a user request turns into an agent-directed action.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 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 | The article centres on agents expanding or misusing identity scope at runtime. |
| ASI02 — Tool Misuse | MCP tool discovery and invocation can be redirected into unsafe actions. | |
| Recommendation — Apply ASI03 to constrain agent identity scope and prevent privilege growth during execution. Use ASI02 to govern which tools an agent may discover and invoke in production. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article examines auth between apps, MCP servers, and services. |
| NHI-05 — Overprivileged NHI | Dynamic permissions and inherited access can exceed the original intended scope. | |
| Recommendation — Harden NHI authentication flows so agents and servers do not rely on weak or ad hoc trust. Review agent and service scopes for overprivilege whenever capabilities expand at runtime. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | API keys, OAuth tokens, and other authenticators are central to the article's control problem. |
| AC-6 — Least Privilege | The article repeatedly shows why least privilege becomes unstable under dynamic agent behaviour. | |
| Recommendation — Manage authenticators so agent sessions do not depend on long-lived or poorly governed credentials. Enforce least privilege around the actual agent workflow, not just the initial application design. | ||
| NIST Zero Trust (SP 800-207) | Continuous verification — Continuous verification | Agentic tool use crosses trust boundaries that need ongoing verification, not one-time trust. |
| Recommendation — Apply continuous verification at every agent-to-tool and agent-to-service boundary. | ||
Key terms
- Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- Runtime Delegation: The process by which an identity is allowed to choose actions, tools, or next steps while a task is in progress. In AI agent environments, runtime delegation is risky when it is broad, opaque, or disconnected from explicit policy, because the resulting behaviour may exceed the original intent.
- Dynamic Permissions: Dynamic permissions are access scopes that change as a task unfolds instead of remaining fixed from the start. In agentic environments, they reflect a moving operational need, but they also make it harder to prove that the final action stayed within approved boundaries.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org