When identities and data are reviewed separately, teams often get thousands of findings without knowing which ones are truly dangerous. That fragmented view hides how much harm a specific non-human identity can do to specific data. The result is weaker prioritization, slower remediation, and a higher chance that excessive access remains in place.
Why separate identity and data review breaks down in agentic environments
Agentic systems do not just store data and authenticate users. They act, chain tools, and make decisions across multiple data sets, so the risk is defined by the relationship between an identity’s permissions and the sensitivity of the data it can reach. Reviewing those elements separately weakens the picture of actual blast radius, especially when a non-human identity can invoke actions that reshape, disclose, or export information. OWASP’s OWASP Agentic AI Top 10 is useful here because it highlights how agentic trust boundaries fail when access and action are assessed in isolation. In practice, many security teams discover the mismatch only after an agent has already been granted broad tool access and data reach, rather than during initial review.
That separation also encourages false confidence. An identity review may show that credentials are rotated and authenticated, while a data review may show that datasets are classified and encrypted, yet neither view reveals whether the same agent can combine those permissions to move from low-risk retrieval into high-impact manipulation. The result is not just more findings, but findings that are harder to prioritise because they are missing the joint context that makes them dangerous.
How the combined view changes prioritisation and containment
The practical issue is that agentic risk is not additive in a simple list of controls. It is relational. Teams need to understand which identity can touch which data, through which tool, under what conditions, and whether the action is read-only, write-enabled, or externally exposed. That is why a combined review produces a better answer than separate identity and data workstreams: it shows the consequence of access, not only the existence of access.
When these views are joined, several things become clearer:
- Excessive privilege stops looking abstract and becomes tied to specific sensitive workflows.
- Data classification becomes operational, because the team can see which agents can reach the highest-value records.
- Tool permissions can be judged against the data they can alter, exfiltrate, or trigger.
- Remediation can be ordered by real blast radius instead of by whichever scanner produced the noisiest report.
That combined analysis is especially important when an agent can take sequential actions. A low-risk read from one source may be harmless on its own, but the same identity may be able to enrich that data with another source, then send it somewhere outside the original trust boundary. NIST’s NIST AI Risk Management Framework is relevant because it pushes teams to evaluate AI system behaviour, context, and downstream impact rather than treating controls as isolated checkboxes.
The model breaks down when teams cannot map identity, tool, and data relationships at the same time, because then they cannot reliably distinguish harmless access from access that can be chained into material harm.
Where the split view still appears useful, and where it fails
Tighter review processes often increase analyst effort, so organisations have to balance review speed against the need to understand cross-domain exposure. Separate identity and data assessments can still work for narrow, static systems, but that is a weaker fit once an agent can chain actions across repositories, APIs, and downstream services.
The split view is most likely to fail in three common cases. First, when data teams classify information without knowing which autonomous identity can reach it. Second, when identity teams approve access without knowing whether the agent can transform or export the data it touches. Third, when both teams rely on point-in-time findings while the agent’s effective access changes as tools, prompts, or connectors change. The governance consensus is clear that these must be reviewed together in agentic settings, even if some organisations still run them as separate operational queues.
That is where common review models become misleading: they record ownership of controls, but not the combined reach of the system. The practical consequence is a prioritisation gap, because the most dangerous access is often the access that looks ordinary until it is joined to a sensitive data path and an execution-capable agent.
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 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 — Data and Tool Exposure | Covers agentic trust boundaries and exposed tool-data combinations. |
| Recommendation — Review agent permissions against reachable data and limit cross-tool blast radius. | ||
| NIST AI RMF | GOV-2 — Map Context and Use | Requires understanding AI system context and downstream impact. |
| Recommendation — Assess agent capability in context of the data and actions it can influence. | ||
| MITRE ATLAS | AML.TA0004 — Evasion | Agentic systems fail when adversaries abuse trust paths and hidden access chains. |
| Recommendation — Trace how an attacker could abuse agent access to reach or manipulate data. | ||
| CIS Controls v8 | 6 — Access Control Management | Addresses excessive or poorly scoped access across identities and resources. |
| Recommendation — Tighten access scopes so each identity only reaches the data it truly needs. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorization | Aligns with controlling authorisation across identities and protected data. |
| Recommendation — Apply permission controls that bind identity access to specific data sensitivity. | ||
Practitioner Guidance
What to prioritise: Build a single review view for agent identities, tool permissions, and the data those tools can reach. If the same review cannot show all three together, the team is not yet seeing the true blast radius.
What to verify: Confirm whether each non-human identity is read-only, write-capable, or able to trigger downstream actions that change data quality, exposure, or routing. That distinction matters more than credential hygiene alone.
Decision rule: Treat any agent that can combine sensitive data access with execution authority as a higher-risk case, even if each permission looks acceptable in isolation.
What practitioners underestimate: The most serious gap is often not a single excessive permission, but the chain created when ordinary permissions are composed across multiple systems.
Practitioner takeaway: Separate review processes are efficient for reporting, but they are too weak for judging agentic blast radius; the operating question is always whether one identity can do meaningful harm to one data set through one tool chain.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
