TL;DR: Oak describes how ConnectAny extends identity coverage into legacy apps, files, on-prem systems and AI agents, including out-of-band access and runtime activity, so identity data can be governed in one graph instead of scattered across exports and backlogs. The real shift is that visibility becomes operational only when access, ownership and activity are tied together across every identity type.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Oak's blog post: ConnectAny is aimed at bringing legacy apps, on-prem systems, files and AI agents into one identity graph so teams can govern access that sits outside standard onboarding paths.
Why it matters: IAM, IGA and PAM teams need coverage across the systems that never made the roadmap, because the weakest governance usually sits in the most awkward source system, not the best integrated one.
👉 Read Oak's analysis of identity coverage across legacy apps and AI agents
Context
Identity visibility breaks down when a programme only knows how to govern the systems it has already onboarded. The harder problem is not policy design but source coverage, especially where access lives inside homegrown applications, file exports, database tables and agent identities with their own credentials.
This is a governance gap, not a connector problem. When ownership, entitlements and runtime usage are separated across different systems, reviewers lose the evidence needed to decide whether access is still legitimate, even if the source system is technically reachable.
Key questions
Q: How should teams govern legacy applications that cannot be modified?
A: Use a gateway or reverse proxy to enforce externalized authorization before the application receives the request. That lets teams centralize policy, add identity context, and create a consistent audit trail without rewriting the legacy system. The key decision is to govern the traffic path when source code control is not available.
Q: What breaks when access is granted outside the normal IAM workflow?
A: When access is granted outside the normal IAM workflow, the governance model loses visibility and the entitlement may remain live long enough to be abused or audited as a finding. The practical failure is not just bad provisioning. It is the gap between discovery and action, which lets unmanaged grants become standing exposure.
Q: When should organisations prioritise runtime activity over entitlement inventories?
A: Use runtime activity whenever you need to decide whether access is still justified. Inventories show potential privilege, but activity shows operational necessity. The two views together reveal dormant access, overbroad grants and identities that keep permissions long after their original purpose has ended.
Q: How should organisations govern human, machine, and AI agent access in one programme?
A: Organisations should govern all three through one identity model, but with actor-specific controls for provisioning, review, and revocation. Human access still relies on authentication and lifecycle processes, machine identities need secret and credential governance, and AI agents need runtime authority boundaries. The goal is consistent ownership and auditability across different actors.
How it works in practice
Why identity graphs fail without source coverage
An identity graph only works when it can ingest the systems where access is actually created and used. In practice, that means pulling from SaaS, cloud, on-prem databases, file feeds and custom apps, then normalising identities, entitlements and activity into one model. If a source only exposes names without usage, or usage without ownership, the graph becomes descriptive rather than governable. The control failure is not lack of data volume, but lack of governance depth across heterogeneous systems.
Practical implication: Treat connector strategy as governance architecture, not integration plumbing.
Why out-of-band access is invisible to workflow-centric IAM
Workflow-based governance assumes access originates in request and approval flows. Many enterprise systems do not work that way. They hold privileges granted directly in the application, in database tables or through legacy batch processes, outside any central request path. That means an access review can certify what the workflow knows while missing what the system actually enforces. The technical issue is not just hidden accounts, but hidden entitlement provenance and hidden revocation paths.
Practical implication: Map every source of entitlement creation, not just the approval system.
How runtime activity changes least privilege decisions
A static entitlement model tells you what an identity can do; runtime activity tells you what it actually does. When a graph joins grants with last use, peer comparison and usage evidence, least privilege becomes measurable instead of rhetorical. That matters for service accounts, contractors and AI agents because some permissions exist only to support rare tasks, while others are never used at all. Without usage data, teams cannot separate legitimate dormant access from unnecessary privilege. See the AI Agent Authorisation Guide.
Practical implication: Use activity evidence to distinguish required access from inherited access.
NHI Mgmt Group analysis
Coverage is the real control plane: Identity governance fails first at the point where source systems sit outside the programme's field of view. If a claims app, database table or file feed never enters the graph, reviewers are not making access decisions, they are only confirming partial records. The practitioner implication is that onboarding depth matters as much as onboarding count.
Out-of-band access creates governance debt: Access granted directly inside an application behaves like untracked privilege until it is captured, contextualised and reviewed. That is why spreadsheet-led recertification keeps missing the same classes of risk: the entitlement exists, but the lifecycle event does not. The implication is that lifecycle process design has to start with source-of-truth completeness, not review cadence.
Runtime usage is the missing qualifier for least privilege: A privilege that is granted is not necessarily a privilege that is needed. By pairing entitlement data with observed activity, Oak's model highlights a more useful governance question: what can be removed without affecting real work? Practitioners should treat usage evidence as the difference between policy and actual operational necessity.
AI agent governance is collapsing into the same visibility problem as service accounts: Whether the subject is a batch account, a contractor login or an agent with credentials of its own, the governance issue is the same when access is invisible in the source. The implication is that identity programmes cannot keep separate control models for human, machine and agentic identities if the underlying source coverage is inconsistent.
Named concept: identity blind spots become identity blast radius. When access exists outside the graph, the issue is not just ignorance, but uncontrolled reach. The wider the blind spot, the larger the set of identities that can accumulate permissions, keep stale access, or retain rights after the business need has shifted. Practitioners should measure blind spots as a blast-radius problem, not a reporting gap.
From our research library:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Identity Maturity Model
What this signals
Identity blind spots are now the governance boundary: programmes that only see onboarded systems will keep missing the most consequential access paths. The next maturity step is not broader review language, but the ability to connect every source where entitlements are created and used.
Usage evidence will replace static privilege assumptions: once teams can compare granted access with what identities actually used, review cycles become more defensible and less performative. That shift matters for service accounts, contractors and AI agents because each can accumulate access that survives longer than its business need.
If the source system cannot expose ownership, entitlement and activity together, the governance model will continue to guess at least privilege instead of proving it. That is the point where identity programmes move from administration to evidence.
For practitioners
- Inventory the systems your IGA never onboarded List legacy applications, homegrown databases, file feeds and local tools where access is still granted outside standard workflows.
- Trace entitlement creation at the source Document where each identity type receives access, especially when permissions are assigned directly in the application or database rather than through a central request path.
- Pair entitlement reviews with usage evidence Require last-use and activity context in every review so reviewers can separate needed dormant access from stale privilege.
- Include service accounts and AI agents in the same governance model Apply the same ownership, approval and revocation logic to non-human identities that you already use for human access, but validate it against the source system's actual controls.
Key takeaways
- Identity governance weakens fastest in systems that were never fully integrated, because access hidden at the source is hard to review or revoke.
- Coverage and activity evidence are the two controls that turn a static identity list into something practitioners can govern with confidence.
- The practical test is whether teams can trace who has access, where it was granted and whether it is still being used.
Related NHI Mgmt Group resources: Agentic AI Identity Guide · AI Agent Identity Security Buyer's Guide · Agentic AI Identity Maturity Model · Ultimate Guide to NHIs: Why NHI Security Matters Now
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 CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Legacy and externally managed sources create governance blind spots similar to third-party NHI exposure. |
| NHI-05 — Overprivileged NHI | The article focuses on stale and excessive access that remains hidden outside the governance graph. | |
| Recommendation — Map unonboarded sources to NHI-03 and inventory every identity-bearing integration point. Use NHI-05 to identify identities whose access exceeds what their observed activity requires. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core topic is governing permissions, entitlements and authorisations across disparate identity sources. |
| ID.AM-01 — Physical devices and systems within the organisation are inventoried | Coverage depends on inventorying the systems where identity data lives, including legacy and on-prem sources. | |
| Recommendation — Apply PR.AA-05 to centralise entitlement governance and evidence access decisions across all sources. Inventory every identity-bearing system before you attempt recertification or least-privilege cleanup. | ||
| MITRE ATT&CK | TA0007;TA0008 — Discovery; Lateral Movement | Hidden accounts and stale privileges are the enabling conditions for discovery and later movement. |
| Recommendation — Track hidden entitlement sources as discovery and lateral-movement risk in your detection programme. | ||
Key terms
- Identity Graph: An identity graph is a relationship map that connects identities, assets, data, and permissions so teams can see how access actually flows. In NHI programmes, it helps explain which agent is related to which owner, which system, and which policy boundary.
- Out-of-Band Security: Out-of-band security uses a separate channel to verify or approve a sensitive action. It reduces reliance on the primary session by moving confirmation, authentication, or alerting to another path, such as a phone call, push notification, or alternate device. This helps detect interception, session hijacking, and unauthorized changes.
- Runtime Usage Evidence: Observed data showing how an identity is actually being used in production rather than how it was originally granted. For machine and autonomous identities, runtime evidence helps distinguish active, justified access from stale or excessive entitlements.
- Coverage debt: Coverage debt is the gap between the assets a security platform should see and the assets it actually covers at a point in time. It grows when deployment, maintenance, or configuration work cannot keep pace with cloud churn, leaving risk visible only after the gap has already formed.
What's in the full announcement
Oak's full blog post covers the operational detail this post intentionally leaves for the source:
- How ConnectAny reaches SaaS, cloud, on-prem and file-based systems with specific connector patterns
- The practical differences between native connectors, Build with Oak, file ingestion and on-prem runner deployments
- How Oak models ownership, entitlements and runtime activity across human, machine and AI agent identities
- What the claims-system example looks like in the graph after the connector and collector layers are in place
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 building or maturing an IAM programme, 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