TL;DR: AI agents and machine identities are exposing a structural gap in IAM, because two decades of identity tooling were built around login events and declared accounts rather than continuous runtime behaviour, according to Orchid Security. The real break point is authority, not another integration layer: existing fabric models can correlate what is already visible, but they cannot govern identities that were never declared.
At a glance
What this is: This is an analysis of why traditional IAM models struggle with AI agents, and its key finding is that identity fabric cannot govern activity that was never declared or observed.
Why it matters: It matters because IAM, IGA, and PAM teams will need to govern runtime authority for AI agents and machine identities, not just improve visibility into existing accounts and connectors.
By the numbers:
- 46% of identity activity already occurs outside centralized IAM visibility entirely, according to Orchid Security.
Context
Identity management was designed around authentication events, but AI agents do not follow that pattern. The article's central claim is that the old model can connect declared identities, yet it cannot govern identity behaviour that happens continuously inside applications.
That creates a governance gap for machine identities, service accounts, and AI agents that act without a human login moment. For IAM leaders, the issue is not more tooling around the same model, but whether the model still matches how identity now behaves.
Orchid Security frames this as a foundation problem rather than a visibility tweak. The architecture that once centered on logins, reviews, and declared accounts is now being asked to govern runtime authority that may never pass through those control points.
Key questions
Q: What breaks when identity governance focuses only on account counts?
A: When governance focuses only on account counts, teams miss the identities that can actually reach sensitive data or production systems. A small set of highly privileged service accounts can create far more risk than a large inventory of low-impact identities. Exposure analysis must replace raw inventory as the primary risk signal.
Q: Why do AI agents expose gaps in existing IAM models?
A: AI agents expose gaps because they do not fit the assumption that access can be assigned once and then managed through periodic reviews. Their permissions are often delegated, contextual, and session-specific, which means the access decision must happen at execution time. That forces IAM teams to move beyond provisioning logic and into runtime policy enforcement.
Q: How can security teams tell whether identity fabric is working?
A: Security teams can tell identity fabric is working when policy intent is enforced consistently, access changes propagate cleanly, and audit evidence can be reconciled across environments. If teams still need manual translation between clouds to understand entitlements or revocation, the fabric is not yet doing its job.
Q: What should organisations do before expanding AI agent deployments?
A: They should define agent-specific identity controls before scaling. That means narrowing tool access, documenting delegated permissions, assigning ownership, and deciding how agent activity will be reviewed or terminated. If those controls are built after rollout, the organisation will inherit a much larger identity surface than it can govern confidently.
Technical breakdown
Why identity fabric stops at declared accounts
Identity fabric works by correlating signals from tools that already know about an identity, such as an IdP, IGA, PAM, or cloud entitlement platform. That makes it useful for unifying declarations, but it also means the fabric inherits the blind spots of every upstream system. If an account, token, or service principal was created outside the governed inventory, the fabric cannot discover it from first principles because it has no independent observation layer inside the workload or application runtime. The result is a coherent view of incomplete data, which is not the same as governance.
Practical implication: treat fabric output as a view of declared identity, not proof of complete coverage.
Why AI agents break the login-centric IAM model
AI agents change identity behaviour because they can act continuously, call APIs across multiple systems, and complete work without a discrete login event. Traditional IAM controls were designed around authentication, role assignment, and review cycles that assume an identity appears, stays stable long enough to be certified, and then leaves. Agents compress that timeline. They can acquire access, use it, and release it inside a single task or session, which leaves little for periodic governance to inspect after the fact. That is why login-era controls do not map cleanly onto agentic execution.
Practical implication: move control points closer to issuance and runtime authorization instead of relying on periodic review alone.
Authority is more important than integration
The article's architectural distinction is that integration connects what already exists, while authority determines what an identity is allowed to do at runtime. A platform can aggregate access data and still fail to answer the key question: who or what had the standing to perform an action inside the application itself? For AI agents and machine identities, the governance problem is not whether the account can be seen somewhere in the stack. It is whether the system can assign, constrain, and attribute runtime authority at the point where the action occurs.
Practical implication: design governance around runtime authority and attribution, not just connector coverage.
NHI Mgmt Group analysis
Identity fabric is a correlation layer, not a control plane for unseen identity. The article is right to separate connection from governance. A fabric can unify declared accounts, but it cannot create visibility into identities that were never onboarded, never inventoried, or never made observable at runtime. That distinction matters because modern risk increasingly lives in the gap between declaration and behaviour. Practitioners should stop treating unified dashboards as proof of control coverage.
Login-centric IAM assumptions are collapsing under agentic execution. The model that assumes a user arrives, authenticates, and remains stable long enough for review was designed for human-paced access. AI agents do not behave that way, and the assumption breaks when identity can acquire and use authority continuously across systems without a discrete login boundary. That is an assumption collapse, not just a visibility issue. Practitioners need to rethink whether periodic certification can govern entities whose useful access may exist only during execution.
Runtime authority is now the governance boundary that matters. The article’s strongest point is that access visibility without runtime authority is an incomplete security posture. If an agent can act through a credential the governance stack never explicitly modelled, the control failure is not just missing integration. The failure is a broken premise that governance only needs to understand declared identities. Security leaders should reframe identity programmes around the point of action, not the point of registration.
Discovery and attribution must be separated in next-generation identity design. The article implicitly shows why discovering an identity and attributing its actions are different governance tasks. One answers whether the identity is known; the other answers who is responsible when an AI agent uses authority at machine speed. That split becomes essential as agent counts grow and human ownership becomes less obvious. Practitioners should design for attribution as a first-class control, not an afterthought.
Machine identity now sets the baseline for IAM architecture. The piece reinforces a broader field reality: humans are no longer the only, or even the primary, identity pattern driving risk. Service accounts, tokens, and agentic actors already behave outside the assumptions embedded in older IAM stacks. That means IAM strategy has to be rebuilt around non-human runtime behaviour first, with human identity controls fitting into the same governance logic. Practitioners should plan for a machine-first identity baseline.
From our research library:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Authorisation Guide
What this signals
Runtime authority becomes the new governance boundary: When identity acts continuously rather than at login time, the useful control point moves from review to issuance and execution. Programme owners should expect access certification to lose value for identities whose privileges may appear and disappear inside a single task.
Discovery and accountability now need separate control paths: A stack can know an identity exists without knowing who is responsible for its action history. That means identity governance, PAM, and AI agent oversight have to converge on attribution, not just access aggregation.
Orchid Security's article points to a broader market signal: identity programmes built for declared accounts will keep missing machine-driven behaviour unless they move closer to runtime observation. In 2026, 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, which is a strong indicator that the operating model is already under pressure.
For practitioners
- Map identities that never enter the governed inventory Inventory service accounts, hardcoded credentials, tokens, and application-local identities that sit outside IdP and IGA coverage. The article shows these are the exact blind spots that fabric-based governance cannot see.
- Define runtime authority checkpoints for AI agents Place control at the moment an agent requests or uses access, rather than relying on later certification or review. This matters where an agent can complete work without a discrete login event.
- Separate declaration from attribution in your governance model Track whether an identity is known to the stack and who is accountable for the actions it performs. The article's core warning is that visibility alone does not solve responsibility when software acts continuously.
- Treat static credentials as live operational risk Assume long-lived service accounts and API tokens are already part of your attack surface, even when they have not been formally onboarded. Agentic systems will reach for existing access rather than wait for new approval.
Key takeaways
- Traditional IAM still assumes a login event, but AI agents and machine identities often operate outside that pattern.
- The article reports that 46% of identity activity already occurs outside centralized IAM visibility, which shows the scale of the blind spot.
- Identity programmes need runtime authority, attribution, and discovery of undeclared identities, not just more connectors.
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, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on non-human identities acting through excess or poorly scoped authority. |
| NHI-09 — NHI Reuse | Service accounts and tokens reused across systems are part of the article's visibility gap. | |
| NHI-01 — Improper Offboarding | Undeclared service accounts and forgotten credentials persist because lifecycle control is weak. | |
| Recommendation — Reduce standing access and scope NHI authority to the smallest runtime need. Identify reused NHI credentials and replace them with purpose-bound identities. Remove stale machine identities from inventory and revoke them when ownership changes. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI agents using broad credentials and hidden authority map directly to agent privilege abuse. |
| Recommendation — Constrain agent privilege at runtime and monitor for scope expansion during execution. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about authorisation at runtime, not just access visibility. |
| ID.AM-01 — Physical devices and systems are inventoried | The governance gap begins with identities and credentials that are not inventoried. | |
| Recommendation — Review entitlements against actual runtime authority and remove unused standing access. Extend inventory practices to service accounts, tokens, and agent identities. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes how hidden credentials can be used to move across systems unnoticed. |
| Recommendation — Map hidden machine identities to credential access and lateral movement detection logic. | ||
Key terms
- Identity Fabric: An identity fabric is a connected control model that shares context across governance, privileged access, and access management. It is not a product category. The aim is to make identity decisions coherent across the full lifecycle so ownership, privilege, and enforcement reinforce each other.
- Runtime authority: Runtime authority is the permission an AI system has while it is actively deciding and acting, not just when it is approved. In governance terms, it is the point where access, tool use, and action scope become operational, which is why build-time review alone cannot prove safety.
- Declared Identity: The identity an automated system claims when it requests access, such as a crawler label, partner tag, or agent descriptor. Declared identity helps with attribution, but it is not a reliable control on its own because behaviour can diverge from the stated purpose after access is granted.
- Identity Dark Matter: Identity dark matter is the hidden mass of old grants, unused credentials, and inherited access that exists in an environment but is not actively understood. In NHI programmes it becomes dangerous because autonomous systems can discover and reuse it at machine speed.
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 July 28, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org