TL;DR: Tool inventory can show which AI applications are in use, but it cannot explain which identities access them, what data they touch, or how sensitive that data is, according to Cyera. Without identity context, AI security remains a list, not a control model, and NHI risk stays hidden in machine-speed workflows.
At a glance
What this is: This is an analysis of why AI visibility without identity context is incomplete, and the key finding is that tool inventories do not reveal the identities, data, and sensitivity needed to assess real risk.
Why it matters: IAM and NHI teams need identity-aware visibility because AI agents, service accounts, and machine identities now access sensitive data without human oversight, creating governance gaps that tool lists alone cannot close.
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
👉 Read Cyera's analysis of AI visibility without identity context
Context
AI visibility becomes a governance problem the moment organisations can see tools but not the identities behind them. In practice, that means security teams may know an AI application exists while remaining blind to which service accounts, machine identities, or AI agents are using it, what data they can reach, and whether the exposure is acceptable under IAM policy.
That gap is especially relevant for NHI governance because AI workloads often inherit access from existing automation patterns rather than formal identity design. Cyera's framing reflects a common enterprise starting point: teams have discovered AI usage, but they have not yet connected identity, data sensitivity, and access context into a defensible control model.
Key questions
Q: How should security teams govern AI applications that are used by service accounts and agents?
A: Start by tying each AI workflow to a named identity, an accountable owner, and a data classification. Then review that identity under the same access rules you use for other NHI subjects. If the workflow cannot be attributed, restricted, and revoked, it should not be treated as governed access.
Q: Why do AI tools create NHI governance blind spots?
A: Because tool visibility does not show who or what is using the tool, what data is being touched, or whether the access is persistent. AI agents and service accounts can inherit privileges that look harmless in inventory but are dangerous in practice. Governance fails when discovery stops at the application layer.
Q: What do security teams get wrong about Shadow AI?
A: They often treat Shadow AI as an approval problem for software, when it is usually also an identity problem. The hidden risk can be an undocumented token, an over-permissioned service account, or an autonomous agent with unreviewed reach. Inventory the identity layer before you decide the tool is the issue.
Q: How do you know if AI access controls are actually working?
A: They are working only if you can answer three questions consistently: which identity accessed the system, which data it touched, and whether that access matched the intended business use. If audit logs cannot produce that chain, the control is partial and the exposure is still active.
Technical breakdown
Why tool inventory is not identity-aware AI visibility
A tool inventory answers a narrow discovery question: what AI applications are present. Identity-aware visibility answers a governance question: who or what is using them, under which entitlement, and against which data sets. The difference matters because AI agents and service accounts do not behave like human users. They can execute continuously, chain actions, and inherit broad permissions from upstream automation. Without identity context, security teams miss the actual control plane and only see the surface layer of usage.
Practical implication: Treat AI discovery as the start of NHI governance, not the end, and require identity binding for every AI workload.
How data sensitivity changes the risk of AI access
AI access is not equally risky across all data. A testing agent touching synthetic data creates a different exposure profile than a production agent pulling customer records, source code, or regulated health data. Data context turns access from an abstract permission into a measurable business risk. This is why data classification, lineage, and access telemetry belong in the same workflow as identity review. If those signals remain separate, teams cannot distinguish acceptable experimentation from high-risk production use.
Practical implication: Classify the data behind each AI workflow before granting or reviewing access, and tie approval to sensitivity tiers.
Shadow AI discovery and the hidden NHI layer
Shadow AI is not only an application-discovery problem. It often hides an NHI problem underneath, where unauthorized tools are used by undocumented service accounts, tokens, or embedded agents. That means the real exposure may sit in the identity layer even when the application looks benign. Effective detection has to map app presence to the identities making requests and the resources those identities can reach. Without that mapping, shadow AI discovery produces noise instead of risk prioritisation.
Practical implication: Correlate AI tool discovery with service account and agent inventory so hidden access paths can be removed or constrained.
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
Identity-aware AI visibility is now a prerequisite for NHI governance. Security teams can no longer treat AI tooling, machine identities, and data exposure as separate concerns. When those signals are disconnected, organisations overestimate their control because they can name the tool but not explain the entitlement. The discipline now is to govern AI the way mature IAM programmes govern sensitive access, with identity, data, and context evaluated together. Practitioners should assume the lack of this linkage is already a control gap.
Shadow AI is best understood as undisclosed NHI behaviour, not just unsanctioned software. The risk is not limited to an unapproved application in a browser or a sanctioned model used the wrong way. The hidden issue is often the identity layer that gives that workflow persistence and reach. That means discovery programmes must inventory service accounts, tokens, and AI agents alongside software assets. The practical conclusion is simple: if you cannot attribute access, you do not control it.
Deep data context is the difference between visibility and governance. Seeing that AI exists is useful; seeing whether it touches PII, source code, or regulated records is what turns visibility into risk management. This creates a named gap we should call the identity-data blind spot. It describes the common failure mode where access is visible in logs but not interpretable in business terms. Practitioners should close that blind spot before they expand AI use cases further.
AI agent governance will keep failing if teams rely on human-centric access models. Human IAM assumptions break when the actor is autonomous, fast, and able to persist through automation. That does not mean discarding IAM controls. It means extending them so NHI identities are first-class subjects of policy, review, and revocation. Organisations that keep AI governance at the application layer will miss the access pathways that matter most.
From our research:
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
- From our research: 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- For a wider NHI context: Read the Ultimate Guide to NHIs for governance, visibility, rotation, and offboarding patterns that also apply to AI agents.
What this signals
Identity context is becoming the operating requirement for AI governance, not an optional enhancement. As organisations expand AI adoption, the control question shifts from whether a tool exists to whether its identity, data access, and business owner are all known. That shift matters because tool-level discovery cannot satisfy audit or incident response needs when autonomous systems are involved. Teams that build identity binding now will have a far better chance of containing AI-driven exposure later.
Identity-data blind spots will accumulate faster than remediation teams can respond. With 96% of organisations storing secrets outside secrets managers in vulnerable locations, according to the Ultimate Guide to NHIs, AI workflows will continue to inherit weak upstream controls unless identity and data governance are integrated. The programme implication is clear: discovery, classification, and entitlement review need to operate as one control path, not three disconnected reviews.
For practitioners
- Bind every AI workflow to an identity record Map each AI application to the service account, token, or agent that executes it, then document the business owner and the data sets it can reach. This gives review teams a control point instead of an application name with no accountable identity.
- Classify data before approving AI access Require sensitivity tagging for the data behind each AI use case, including customer PII, source code, and regulated records. Then align access decisions to that classification so approval reflects actual exposure rather than generic model usage.
- Correlate discovery with NHI inventory Join AI discovery output to service account inventories, API key usage, and agent telemetry so hidden access paths can be identified and removed. A tool list by itself is incomplete if it cannot explain who or what is invoking it.
- Review Shadow AI as an identity problem Treat unauthorized AI usage as a signal to inspect the identity layer first. Look for embedded credentials, forgotten automations, and agents with broader access than their operators understand, then remove standing reach that is not clearly justified.
Key takeaways
- AI visibility without identity context is incomplete because it cannot show who is acting, what data is being touched, or how risky the access really is.
- AI agents and service accounts create NHI governance gaps when discovery stops at the tool layer and never reaches the identity layer.
- Practitioners should connect identity inventories, data classification, and access review before they scale AI use cases further.
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 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | NHI-01 | Identity-aware AI discovery maps to agent identity and tool-access risks. |
| NIST AI RMF | AI governance requires accountability, measurement, and traceability across use cases. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege review is central when AI agents inherit access through service accounts. |
Use AI RMF GOVERN and MAP functions to assign owners and document data-access boundaries for AI workflows.
Key terms
- Identity-Aware Visibility: Identity-aware visibility is the ability to see not just that an AI tool exists, but which identity is using it, what it can reach, and which data it touches. In NHI governance, this turns discovery into actionable control because access can be attributed, reviewed, and revoked.
- Shadow AI: Shadow AI is AI usage that is not formally governed or fully known to the organisation. It often involves undisclosed tools, embedded automation, or autonomous agents operating with credentials and access that have not been reviewed through normal IAM or NHI processes.
- Identity-Data Blind Spot: An identity-data blind spot exists when security teams can see access events or AI tools, but cannot connect those events to data sensitivity or accountable identities. It is a practical governance failure because logs exist, yet the organisation still cannot explain exposure in business terms.
- AI Agent: An AI agent is autonomous software that can execute actions and use tools without direct human oversight for each step. In security terms, it behaves like a non-human identity, which means it should be governed with identity, entitlement, logging, and revocation controls.
Deepen your knowledge
AI identity binding, data sensitivity, and access review are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for AI agents and service accounts from the same starting point, it is worth exploring.
This post draws on content published by Cyera: AI Visibility Without Identity Context Is Just a List. Read the original.
Published by the NHIMG editorial team on 2026-04-09.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org