TL;DR: AI agents, MCP, ephemeral clients, and API access across trust domains are drawing growing focus, according to Curity’s recent how-to and article set, underscoring how identity controls are being stretched by dynamic, non-human execution paths. The gap is no longer theoretical: governance built for stable credentials and human-paced review cannot fully model runtime agent behaviour.
At a glance
What this is: Curity’s June 2026 identity content highlights how AI agents, ephemeral clients, and cross-domain API access are pushing identity governance beyond static credential models.
Why it matters: This matters because IAM, NHI, and human identity programmes are converging on the same problem set: who or what can act, when, and under whose accountability.
👉 Read Curity's guidance on AI agents, ephemeral clients, and API trust
Context
Curity’s 2026 content cluster is really about a governance problem: identity controls built for stable, human-paced access are being asked to govern dynamic non-human execution. AI agents, ephemeral clients, and API access across trust domains all create runtime decisions that are harder to pre-authorise, review, or attribute cleanly.
For IAM and NHI teams, the issue is not only authentication but lifecycle control, trust delegation, and revocation across machine actors. As AI agents become part of the access path, the boundary between workload identity, delegated authorization, and autonomous action becomes operationally important rather than theoretical.
Key questions
Q: How should security teams govern AI agents that use delegated API access?
A: Treat delegated API access for AI agents as a governance path, not just an authentication event. Define which tools and downstream systems the agent may reach, require explicit audience and scope limits, and log every boundary crossing. If the agent can change its action sequence at runtime, your controls must be able to explain the full delegation chain.
Q: Why do ephemeral clients change identity risk calculations?
A: Ephemeral clients reduce standing exposure, but they also make trust harder to inspect after the fact. If access is issued and consumed quickly, the programme cannot rely on periodic review alone. Teams need lifecycle rules for issuance, scope, revocation, and logging so temporary identity does not become unmanaged identity.
Q: What breaks when access across trust domains is not tightly scoped?
A: When cross-domain access is not tightly scoped, identities can carry trust farther than intended, especially through chained API calls and delegated tokens. That expands blast radius, weakens accountability, and makes revocation incomplete. The failure is usually not authentication itself, but authorisation drift across systems that were never meant to share trust.
Q: How can organisations tell whether their NHI controls are keeping up with AI agents?
A: Look for controls that can prove who requested access, which tool was used, what scope was granted, and whether the identity could be revoked cleanly. If those answers require manual reconstruction across logs, the programme is behind the behaviour it is trying to govern.
Technical breakdown
Dynamic trust for AI agents and delegated access
Dynamic trust means the access decision is assembled at runtime from identity, context, and policy rather than being fixed at provisioning time. In AI agent and MCP-style flows, the actor may request tools, tokens, or downstream access in a changing sequence, which makes static role design less reliable. The core technical problem is not simply that the credential exists, but that the system must decide whether the agent may combine capabilities in ways the original authorisation model did not anticipate.
Practical implication: map which access decisions are made once and which are made per action, then separate those control points.
Ephemeral clients and client ID metadata documents
Ephemeral clients are short-lived client identities that are created for a limited purpose and then discarded, often to reduce standing exposure. Client ID metadata documents help describe how those clients should be trusted, validated, and interpreted by downstream systems. This pattern shifts identity from a static registration model to a runtime trust exchange, which improves containment but also raises governance questions about provenance, lifecycle, and revocation certainty.
Practical implication: define how ephemeral client identity is issued, validated, and retired before you let it carry production access.
API access across trust domains
API access across trust domains is where identity and authorisation must work across organisational, application, or security boundaries without assuming a single trust perimeter. Once an AI agent or external workload can traverse those domains, the real failure mode is not just broken authentication. It is weak delegation control, unclear audience restrictions, and insufficient auditability over which identity was allowed to reach which data or tool at each step.
Practical implication: tighten audience, token scope, and delegation logging wherever API calls cross trust boundaries.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Dynamic agent access turns static NHI assumptions into governance debt. Curity’s focus on AI agents and dynamic trust reflects a broader shift: access is no longer always a stable entitlement that can be reviewed after the fact. The governance model built around fixed service accounts and predictable usage windows becomes less reliable when the actor can make runtime decisions about when and how to request access. Practitioners should treat that as a structural change in identity control, not just a tooling update.
Ephemeral clients sharpen the case for lifecycle-first identity design. Short-lived identities can reduce standing exposure, but only if their issuance, scope, and retirement are unambiguous. Without that, ephemeral access becomes a new form of governance drift because the identity may be temporary while the permissions, logs, or downstream assumptions persist. The practical lesson is that lifecycle discipline matters more, not less, when identities are designed to disappear quickly.
Dynamic trust for AI agents creates an assumption collapse in access review. Access review was designed for conditions where privilege persists long enough to be observed and certified. That assumption fails when an agent can acquire, use, and discard access within a session or across rapidly changing tool calls. The implication is not to add another review cycle, but to rethink whether review is still the right control boundary for that actor model.
API delegation across trust domains is now an identity governance problem, not only an integration problem. Once access moves through chained identities and indirect trust, the question becomes who can act on whose behalf and under what revocation path. That aligns directly with OWASP-NHI, ZT-NIST-207, and NIST-CSF concerns about scope, visibility, and accountability. Practitioners should expect more of their controls to be judged by delegation clarity than by simple credential possession.
Runtime trust boundary drift: the most useful concept in this topic is the gap between where an identity is trusted and where it actually acts. As AI agents, ephemeral clients, and federated APIs accumulate more runtime flexibility, security teams need a vocabulary for when trust changes faster than governance can track it. The control question becomes whether the boundary is still measurable at all.
From our research:
- 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 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge.
- For a governance baseline, NHI Lifecycle Management Guide helps teams connect issuance, rotation, and offboarding to operational control.
What this signals
Ephemeral trust debt: once AI agents and short-lived clients can request access dynamically, the unresolved issue is not just credential volume but governance continuity. Programmes that still depend on static approvals will struggle to keep up with runtime delegation, especially when the access path is assembled in pieces across systems and teams.
For practitioners, the next maturity step is to treat delegation boundaries as first-class identity objects. That means pairing runtime policy with lifecycle controls, and using frameworks such as NIST Cybersecurity Framework 2.0 to connect identity, detection, and response across trust domains.
For practitioners
- Inventory agent and client identity paths Map every AI agent, ephemeral client, and delegated API path that can reach production data, then identify where trust is granted at registration versus runtime. Pay special attention to any path that can select tools or downstream scopes after initial authentication.
- Separate issuance from authorisation Make sure the system that creates an ephemeral client or agent credential is not the same control that approves downstream business access. That separation helps expose where delegation is being silently expanded beyond the original trust decision.
- Define revocation for short-lived identities Document how to terminate access when an ephemeral client, agent, or delegated token is no longer needed, including downstream token propagation and cached session state. If revocation is unclear, temporary identity is becoming permanent in practice.
- Audit trust-domain crossings Require logging for every boundary crossing where an agent or workload moves from one trust domain to another, including audience, scope, and delegated subject. This is the only way to reconstruct who acted on what and under which identity.
Key takeaways
- AI agents, ephemeral clients, and cross-domain APIs expose a governance gap in identity models built for stable credentials.
- The risk is not just more identities, but faster-moving trust decisions that outpace review, revocation, and accountability.
- Practitioners need lifecycle and delegation controls that can explain who acted, what was allowed, and when trust changed.
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 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Dynamic non-human access and delegated tokens are central to this topic. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Cross-domain API access depends on least-privilege and explicit trust boundaries. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access control are required to govern non-human runtime behaviour. |
Map agent and ephemeral client identities to NHI-01 and limit standing exposure at runtime.
Key terms
- Dynamic Trust: Dynamic trust is a model where access decisions are made at runtime using current identity, context, and policy rather than a fixed approval made once at provisioning. In non-human environments, it is useful but harder to govern because the trust decision can move faster than review and audit processes.
- Ephemeral Client: An ephemeral client is a short-lived software identity created for a specific task or session and then discarded. It can reduce standing exposure, but only if issuance, scope, and revocation are tightly controlled. Without that discipline, temporary credentials can still create persistent governance risk.
- Trust Domain: A trust domain is a boundary within which identities, policies, and authorisation decisions are expected to be mutually understood and enforced. When API calls or AI agents cross that boundary, the receiving system may not fully inherit the original security assumptions, which increases delegation and accountability complexity.
- Delegated Access: Delegated access is permission exercised by one identity on behalf of another, directly or through chained tokens and API calls. In non-human identity programmes, it demands clear subject, audience, and revocation rules because the actor performing the action may not be the actor that originally received the credential.
Deepen your knowledge
AI agents, ephemeral clients, and delegated API access are central topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are adapting identity governance for dynamic non-human access, it is a useful place to start.
This post draws on content published by Curity covering AI agents, ephemeral clients, and API access across trust domains: recent how-tos, articles, and code examples on identity for non-humans. Read the original.
Published by the NHIMG editorial team on 2026-01-28.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org