TL;DR: The Model Context Protocol’s URL Elicitation closes a gap where agents calling outside APIs fell back on shared service accounts, leaving no clear user context and broad credentials in logs, according to Arcade. The real shift is that authorization now has to preserve per-user accountability as agents move from connection setup into business-system action.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Arcade's announcement: MCP URL Elicitation shifts agent authorization from shared credentials to per-user browser login, so business-system actions retain user context and keep tokens out of the client and model.
Why it matters: IAM and security teams need a clean authorization model for agents because shared service accounts erase accountability, expand credential exposure, and make production use harder to govern.
Context
The security gap here is straightforward: an agent can be authenticated to a protocol and still lack a trustworthy way to act on behalf of a specific user when it reaches a downstream business system. In MCP security terms, that is the point where connection-level authorization stops being enough.
Before URL Elicitation, builders often bridged that gap with shared service accounts and broad credentials, which blurred user context and made auditability weak. For agentic systems, the identity question is not whether the model can reach a tool, but whether the action can still be tied back to the right human principal.
Key questions
Q: How should teams authorize AI agents without using shared service accounts?
A: Use a per-user authorization flow where the service, not the agent client, establishes the effective permissions for each action. That preserves accountability, reduces credential sharing, and keeps the access model aligned to the person who approved the task rather than a generic machine identity.
Q: Why do MCP-connected agents create governance risk even when network controls are in place?
A: MCP-connected agents can operate locally on the same device as the user or developer, so their activity may never cross the perimeter traditional tools watch. That means network-based discovery can miss both the server itself and the actions it performs. The core risk is not just data leaving the environment, but unsanctioned tool use inside trusted workflows.
Q: What breaks when agent tokens pass through the client or model?
A: Credential exposure becomes much easier, especially through prompts, logs, and debugging paths that were never designed to hold secrets. Once tokens are visible in those layers, the organisation has widened the attack surface and weakened the separation between authorization logic and model execution.
Q: What should security teams do first when introducing MCP-connected agents?
A: Security teams should first map every MCP-connected tool and data path to a named policy owner and an explicit access boundary. Without that inventory, agents inherit hidden trust relationships that are hard to audit or revoke. Start with the highest-value data sources and the most powerful tools.
Technical breakdown
Why connection-level authorization is not enough for MCP
MCP authorization originally covered the link between client and server, but not the downstream API call a server might make on a user’s behalf. That left builders to improvise with service accounts, delegated tokens, or manual handoffs when the server needed to operate beyond the protocol boundary. In practice, that is a delegation problem, not a transport problem: the identity context has to survive the hop from protocol session to business action. See the MCP Authorisation Specification Guide.
Practical implication: Treat downstream API calls as a separate authorization boundary, not as an extension of the initial MCP login.
How URL Elicitation preserves user context without exposing tokens
URL Elicitation sends the user directly to the target service in a browser, where the user authenticates with that service and the resulting tokens stay out of the MCP client and the language model. The important control outcome is not just login, but containment of credential material and preservation of per-user permissions. That means the agent can operate with the user’s own entitlements without turning the client into a token broker.
Practical implication: Design agent flows so the model never sees reusable tokens or shared credentials.
Why refresh-token handling becomes a governance issue
Once users stay signed in across sessions, refresh-token handling becomes part of the agent identity model rather than a background implementation detail. Long-lived sessions are useful operationally, but they also extend the time window over which delegated access can remain active. The governance question is whether refresh behavior is still tied to the intended user, the intended service, and the intended scope after the first interaction ends. See the NHI Authentication Guide.
Practical implication: Review refresh-token lifetime, re-authentication triggers, and revocation paths as part of agent governance.
Threat narrative
Attacker objective: The attacker objective is to exploit delegated agent access in a way that obscures which user authorized the action while expanding what the agent can reach.
- Legitimate access is established when the user authorizes the agent through a browser login and the protocol session begins with a valid user context.
- Scope drift begins when the server needs to call an outside API and the implementation falls back to shared service accounts or broad delegated credentials.
- Impact follows when requests execute under credentials that no longer preserve clear user attribution, weakening auditability and widening the blast radius of abuse.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
URL Elicitation is really a user-context control, not just an OAuth detail: the value lies in preserving who authorized the action once an agent leaves the MCP connection and touches a real business system. If the user identity does not survive that handoff, the environment falls back to shared privileges and weak attribution. The practitioner takeaway is that agent authorization has to be judged by downstream accountability, not protocol completion.
Hardcoded service accounts were a symptom of missing delegation design: before this pattern, builders used broad credentials because the protocol did not give them a clean way to rebind action to a specific user. That meant the identity of the actor and the identity of the permission grant diverged, which is exactly where governance breaks down. The implication is that the access model, not the model output, is the real control surface.
Credentials staying out of the client and model is the real security gain: keeping tokens out of prompts and logs reduces accidental exposure, but it also changes where teams should look for abuse. The risk shifts from prompt leakage to authorization design, session handling, and revocation discipline. Agent identity and access becomes the right lens when agents are allowed into production workflows.
MCP authorization now exposes the broader agent governance gap: a protocol can authenticate an agent and still fail to govern the human principal behind it. That is why the security problem is not “can the agent connect?” but “can the organisation prove which human granted which action under which scope?” The answer has to be yes before agents are allowed into regulated or high-impact systems.
The named concept here is delegated user-context preservation: this is the control pattern that keeps an agent from becoming a generic credential proxy. It matters because production adoption depends on being able to trace action back to a person without routing tokens through the model or the client. Practitioners should treat that traceability as a requirement, not a convenience.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Delegated user-context preservation: the next governance problem is not whether agents can authenticate, but whether the organisation can keep user context intact across every downstream system they touch. When the access path depends on shared credentials or invisible token handoffs, accountability becomes a design property rather than an audit afterthought.
MCP adoption is now moving the identity discussion from protocol access to action attribution, which is where IAM, PAM, and agent governance converge. Teams that still treat agent authorization as a front-door login problem will miss the more important question of who can act, where, and under which preserved principal.
For practitioners
- Validate downstream user attribution Confirm that every agent action against a business system can still be tied to a specific human principal after the MCP handoff.
- Remove shared service accounts from agent paths Replace broad credentials with per-user authorization flows where the service, not the client, issues the effective access context.
- Keep tokens out of prompts and logs Ensure the agent architecture never exposes reusable credentials to the client, the model, or logging layers during the authorization flow.
- Review refresh-token and revocation behavior Test how long delegated access persists, how re-authentication is triggered, and how quickly access can be withdrawn after role or risk changes.
Key takeaways
- The core problem is not agent connectivity, but the loss of human context when an MCP server needs to reach outside systems on behalf of a user.
- This pattern reduces dependence on shared service accounts and keeps credentials out of the client and model path, which improves accountability and containment.
- Teams should judge agent authorization by downstream traceability, token exposure, and revocation behavior before allowing production use.
Related NHI Mgmt Group resources: MCP Security Guide · Agent Identity and Access Guide · AI Agent Authorisation Guide · MCP Authorisation Specification Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | URL Elicitation changes how agents authenticate on behalf of users and avoids shared login paths. |
| NHI-05 — Overprivileged NHI | The article contrasts per-user permissions with the broad credentials used before URL Elicitation. | |
| NHI-10 — Human Use of NHI | The protocol pattern is about humans authorizing machine actions through a safe handoff. | |
| Recommendation — Adopt per-user authentication flows so MCP agents never rely on shared or opaque delegated login paths. Replace broad delegated access with task-scoped permissions for each agent session. Keep the human principal visible in the authorization flow and prevent credential passthrough to the model. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Refresh-token handling and credential containment make authenticator lifecycle central to this topic. |
| Recommendation — Manage delegated authenticators so refresh, rotation, and revocation are tied to the intended user and service. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Token leakage into prompts or logs maps directly to credential theft and potential exfiltration paths. |
| Recommendation — Reduce credential exposure paths that enable token theft and downstream exfiltration. | ||
Key terms
- URL Elicitation: URL Elicitation is a protocol capability that lets a server return a link to a browser-based action, such as authentication or another guided workflow. It helps bridge agentic automation and human interaction by moving sensitive steps into a user-controlled browser experience.
- Delegated User Context: The human or upstream identity context carried into an automated or agentic workflow when the agent acts on someone else's behalf. It matters because audit and authorization decisions may depend on whether the action was taken under direct agent authority or borrowed authority.
- Token Passthrough: Token passthrough is the practice of forwarding an authentication token through intermediaries instead of validating it at each trust boundary. In MCP this is prohibited because it prevents the server from proving who is actually authorised to act. The result is weaker accountability and a larger attack surface for stolen or replayed credentials.
- Refresh Token Governance: The policies and controls that determine how long an authenticated session can persist and how it can be renewed or revoked. For agent access, refresh handling is a lifecycle control because it governs how long delegated permissions remain usable after the initial sign-in.
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 October 27, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org