Zero trust data security now has to govern AI systems and NHIs

At a glance

What this is: This is an overview of Zero Trust data security, which applies explicit verification, least privilege, and continuous monitoring to sensitive data across human and non-human identities.

Why it matters: It matters because IAM teams now have to govern access decisions for users, service accounts, workloads, and AI systems using data sensitivity and runtime context, not just authentication.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read BigID's analysis of zero trust data security for identities and sensitive data

Context

Zero Trust data security is the application of explicit verification, least privilege, and continuous monitoring to sensitive data rather than to a network perimeter. That matters for identity security because access now comes from users, service accounts, workloads, APIs, and AI systems, often against the same data estate.

The governance gap is not whether an identity can authenticate. The gap is whether that identity should reach a specific dataset, under the current device, workload, behavioural, and business context, and whether that access should be retained once conditions change. NIST SP 800-207 frames this shift as moving away from static trust boundaries toward resource-level decision making.

For organisations governing NHIs and AI systems, the practical issue is that data-aware access cannot be bolted onto identity after the fact. If data sensitivity, effective permissions, and runtime activity are not connected, least privilege becomes a paper policy rather than an enforced control.

Key questions

Q: How should security teams implement Zero Trust for NHIs and AI systems?

A: Start by mapping effective access to sensitive data, not just configured permissions. Then classify the data, reduce standing privilege, and require runtime context such as workload posture, request type, and current risk before granting access. The goal is to keep machine identities inside a narrow, reviewable blast radius.

Q: Why do NHIs complicate zero trust and least privilege efforts?

A: NHIs complicate zero trust because they are numerous, persistent, and often tightly integrated into applications and pipelines. If teams cannot see every identity or keep permissions aligned to actual usage, they cannot consistently prove least privilege. Continuous review and revocation are essential, not optional.

Q: What breaks when data classification is missing from access governance?

A: Least privilege becomes too coarse to be useful. Without classification, teams cannot tell which datasets are public, regulated, or highly sensitive, so they tend to overprotect low-risk resources and underprotect the ones that matter most. That creates avoidable exposure and weakens policy enforcement.

Q: Who is accountable when a third-party identity causes data exposure?

A: Accountability sits with the organisation that trusted the identity without sufficient boundaries, not just with the vendor that used it. If a third-party account was over-scoped, persistently trusted, or insufficiently monitored, the governance failure is internal. Frameworks such as NIST CSF and zero trust both expect explicit control over external access.

Technical breakdown

How data-aware Zero Trust evaluates access decisions

Zero Trust data security shifts the decision point from network location to resource-specific authorisation. In practice, that means an access request is judged using identity state, device or workload posture, requested data sensitivity, behaviour, and current risk. This is materially different from perimeter-era trust, where a successful login or internal connection often became a broad access grant. Data-aware Zero Trust is therefore a policy system, not just a network model: it combines identity, entitlement, classification, and telemetry to decide whether an identity can reach a given dataset at a given moment.

Practical implication: Practitioners should map access decisions to data classification and runtime context, not just authenticated sessions.

Least privilege for users, workloads, service accounts, and AI systems

Least privilege is the control that limits what an identity can do once it is allowed in. For NHIs and AI systems, this means scope must be defined by task, resource, and duration, because over-privilege usually comes from inherited entitlements, broad roles, and stale permissions. The article correctly places service accounts and AI agents in the same governance frame as users because all of them can become high-risk data pathways when their effective access exceeds operational need. Zero Trust only works when privilege is continuously revisited as roles, workflows, and data exposure change.

Practical implication: Security teams should inventory effective access for NHIs and AI systems, then trim broad grants before focusing on new controls.

Continuous monitoring and remediation for sensitive data activity

Zero Trust becomes operational when activity monitoring closes the loop between access approval and actual usage. That means tracking downloads, query patterns, sharing behaviour, permission changes, and unusual access paths across cloud, SaaS, on-premises, and AI environments. Without that visibility, organisations can detect who authenticated but not whether the data was overexposed, copied, or moved in an abnormal way. The control objective is not only to spot compromise, but also to create a fast remediation path that reduces exposure while the system is still in use.

Practical implication: Teams should connect detection to remediation workflows so excessive access can be removed while exposure is still active.

Threat narrative

Attacker objective: The attacker aims to turn legitimate identity access into broad, data-level exposure without triggering effective context-aware controls.

1. Entry begins when a valid user, service account, workload, or AI system reaches sensitive data through broad trust assumptions instead of resource-level verification.
2. Escalation occurs when inherited permissions, excessive roles, or stale access allow that identity to move from one dataset to a wider pool of regulated or high-value data.
3. Impact follows when the identity uses legitimate access to download, share, query, or expose sensitive data before monitoring or remediation interrupts the activity.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Zero Trust data security is now an identity governance problem, not only a network design problem. The article is right to move the discussion from perimeter trust to resource-level decisions, but the deeper point is that identity teams now own the data exposure boundary. If users, service accounts, workloads, and AI systems are all reaching the same data stores, then access governance has to treat them as one control plane. Practitioners should stop separating network trust from identity trust when sensitive data is the asset being protected.

Effective access matters more than configured access for NHI governance. A role on paper does not describe the real blast radius if inherited groups, indirect permissions, and service account chaining are left unreviewed. That is the governance gap this model exposes: organisations often know who should have access, but not which NHI paths can actually reach high-value data. Practitioners should prioritise effective access mapping before tuning policy logic.

Data classification creates the missing risk signal for least privilege. Least privilege cannot be enforced intelligently if the organisation cannot distinguish public content from regulated, customer, or AI-training data. The named concept here is identity blast radius: the amount of sensitive data an identity can reach once access is granted. The practical conclusion is that identity controls and data classification must be managed as a single governance problem.

AI systems and NHIs belong in the same Zero Trust conversation because both can overreach without human-like accountability loops. The article’s inclusion of AI systems and agents is directionally correct, but the control challenge is broader than AI. Any non-human identity that can access and move data at machine speed can outpace periodic review cycles, especially when privilege is inherited or persistent. Practitioners should align access governance, monitoring, and remediation across the full non-human estate.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap makes data-aware identity governance a priority, and Ultimate Guide to NHIs , Standards is the natural next reference point.

What this signals

Identity blast radius: the next governance metric is not how many identities exist, but how much sensitive data each one can actually reach. As more access is mediated by service accounts, workloads, and AI systems, teams need a control model that measures exposure by data class, not by directory count.

A data-aware Zero Trust programme should be judged by whether it can collapse standing access, inherited permissions, and noisy entitlements into a small set of reviewable paths. That is where NHI governance, human IAM, and workload identity security converge into one operational model.

As organisations move toward machine-speed access decisions, continuous monitoring becomes the control that separates useful automation from unmanaged exposure. The practical signal is whether access changes trigger remediation quickly enough to matter before data leaves the authorised boundary.

For practitioners

• Map effective access to sensitive datasets Identify who and what can actually reach high-value data through direct, inherited, and indirect entitlements. Include users, contractors, service accounts, workloads, APIs, and AI systems so the review reflects real exposure rather than configured roles.
• Classify data before tuning access policy Use sensitivity, regulatory status, and business impact to decide which datasets deserve tighter verification and shorter access lifetimes. Apply stronger controls to customer, payment, health, and AI-training data first.
• Reduce standing privilege for NHIs Remove broad group memberships, stale service account rights, and inherited permissions that let machine identities browse beyond their task scope. Recheck access after workflow changes, vendor changes, and application updates.
• Tie monitoring to remediation workflows Alert on unusual downloads, unexpected sharing, and permission changes, then route those findings into rapid revocation or quarantine actions. Monitoring without a removal path only improves visibility, not exposure.

Key takeaways

• Zero Trust for sensitive data only works when identity, context, and data classification are evaluated together.
• NHIs and AI systems widen the exposure problem because their effective access is often broader and less visible than teams assume.
• The decisive control is not authentication alone, but continuous reduction of identity blast radius through monitoring and remediation.

Key terms

• Zero Trust: A security model that assumes no identity — human or non-human — should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
• Effective Access: The actual permissions an identity can exercise after inheritance, nested groups, delegation, and object-level controls are evaluated. In Active Directory, effective access is more useful than direct membership because it reveals the true operational reach of a service account.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Data classification: Data classification is the process of labelling information according to sensitivity, regulatory impact, or business value so controls can be applied consistently. For AI governance, it allows policy to follow the data into prompts, sessions, and destinations rather than relying on brittle text matching.

What's in the full article

BigID's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step breakdown of how BigID connects sensitive data to identities, permissions, and activity.
• Practical implementation examples for classifying data and mapping effective access across cloud, SaaS, and on-premises systems.
• Operational workflow detail for prioritising excessive access and triggering remediation actions.
• Use-case guidance for applying data-aware controls to AI systems and non-human identities.

👉 BigID's full article covers the data-aware control model, access evaluation logic, and remediation detail.

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.