AI security best practices show why data-centric controls matter

At a glance

What this is: This is Cyera’s analysis of AI security best practices, arguing that enterprise AI risk is fundamentally a data visibility and governance problem rather than a model-only problem.

Why it matters: It matters because IAM, NHI, and AI governance teams need controls that follow AI systems as they read, move, and act on sensitive data in real time, not just periodic reviews.

By the numbers:

• 83% of enterprises already use AI, but only 13% report strong visibility into how it touches their data.

Context

AI security is the discipline of controlling how models, copilots, and AI agents access sensitive data, make decisions, and propagate risk across cloud, SaaS, and on-premise environments. The core governance gap in this article is that adoption is moving faster than visibility, so organisations often cannot answer where AI touches regulated information or which identity is using it.

For IAM and NHI programmes, the problem is not just that AI systems exist. It is that AI can behave like a high-risk identity class with broad access, while conventional review cycles and perimeter controls do not observe that behaviour quickly enough. That makes data-centric governance central to both human access policy and non-human access policy.

Cyera’s framing is consistent with a broader industry shift: security teams are being asked to govern AI through the data it consumes and the identities it uses, rather than through model trust alone. That approach becomes especially important when autonomous AI agents can retrieve information and trigger downstream processes without direct human oversight.

Key questions

Q: What breaks when AI agents are given access without identity governance?

A: What breaks is accountability. The organisation may see actions, logs, and alerts, but it cannot reliably tie them to a governed identity with clear scope and revocation. That creates uncontrolled blast radius, especially when agents can reach sensitive systems through shared tokens, delegated service accounts, or broad API access.

Q: When do autonomous systems create more governance risk than ordinary automation?

A: They create more risk when they can decide the action sequence, choose tools at runtime, and execute without human approval. At that point, the system is no longer following a fixed script. The governance challenge shifts from workflow management to controlling independent action inside a session.

Q: How can security teams tell whether AI posture management is actually working?

A: It is working when teams can answer four questions quickly and consistently: who owns the agent, what it can access, which guardrails apply, and when access changed. If those answers depend on manual log-chasing, the control is too weak. Effective posture management produces usable evidence, not just a dashboard view.

Q: What steps should security teams take to prevent Shadow AI risks?

A: Security teams should assess their governance frameworks, implement real-time monitoring tools, and ensure proper training on the risks associated with Shadow AI. These steps will help identify unauthorized agents and mitigate risks effectively.

Technical breakdown

Why AI security posture management has to be continuous

AI Security Posture Management, or AI-SPM, extends data security posture management into AI environments so teams can continuously evaluate access, configuration, and data movement. The technical reason this matters is that AI systems change faster than periodic audits can keep up with. New models, new prompts, new connectors, and new datasets can expand exposure without any single control event marking the change. AI-SPM therefore focuses on live detection of policy drift across data flows, not one-time certification of a static stack.

Practical implication: treat AI security as a continuously measured posture, not a quarterly review cycle.

How AI-specific identity and access policies constrain overexposure

The article’s core identity point is that AI systems often behave like users, but most organisations do not govern them that way. That creates an access model in which an AI agent or model can accumulate permissions beyond its original purpose as workflows expand. Proper AI-specific identity and access management ties each system to a defined scope, uses the data classification to shape permissions, and revokes access when that scope no longer applies. In practice, this is the difference between a governed AI identity and an overprivileged automation layer.

Practical implication: define explicit access scope for each AI system and remove any entitlement that outlives the use case.

Why autonomous AI agents collapse periodic review assumptions

Autonomous AI agents are different from ordinary automation because they can make decisions and access information without direct human oversight. That changes the governance model in kind. Access review processes assume a privilege exists long enough to be observed, certified, and recertified. Autonomous behaviour can compress that window so the relevant access happens, changes, and disappears faster than review controls can capture it. This is why the article emphasises continuous monitoring and data-centric control rather than relying on periodic inspection alone.

Practical implication: move control enforcement to issuance and runtime monitoring, not post hoc access review.

Threat narrative

Attacker objective: The attacker objective is to exploit AI-linked data access to expose regulated data, intellectual property, or credentials at scale before governance catches up.

1. Entry occurs when AI tools, copilots, or autonomous agents are connected to sensitive data sources across SaaS, cloud, or on-premise systems.
2. Credential and access scope expand as the AI system is granted broader permissions than its original task requires, often without a clean offboarding event.
3. The agent or model then accesses data outside intended boundaries, and the resulting misuse or leakage becomes visible only after behaviour drifts or an incident occurs.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Data visibility, not model sophistication, is now the primary AI governance failure mode: organisations are deploying AI faster than they can see where it touches sensitive information. That means the most important control is not a model blacklist or a dashboard, but a reliable data control plane that can explain access in context. Practitioners should treat visibility into AI data movement as a governance prerequisite, not a reporting feature.

AI systems are effectively a new identity class, and most programmes still govern them as if they were applications: the article correctly points to AI-specific identity and access management because AI models and agents can consume data, combine sources, and act with a scope that resembles privileged service activity. The useful concept here is AI data access blast radius: once an AI system is allowed broad retrieval and downstream action, the security problem becomes how far the impact can spread before someone notices. Practitioners need to evaluate AI identities by data reach, not by deployment count.

Autonomous access review was designed for access that persists long enough to be reviewed: that assumption fails when AI agents can retrieve, decide, and trigger actions inside a short runtime window. The implication is that governance has to shift from periodic attestation to live enforcement of data scope, because review after the fact will always lag the agent’s behaviour. This is a structural change in how identity governance works for non-human actors.

Data-centric AI security is the right architectural centre because the same control surface serves governance, compliance, and abuse prevention: if the data layer is governed, you improve regulatory evidence, reduce overexposure, and make AI abuse easier to detect. That does not remove the need for model-specific controls, but it gives security teams one place to anchor policy across tools, workloads, and users. Practitioners should align AI security design around information flow rather than isolated model controls.

Shadow AI and overprivileged agents are the same programme problem in different forms: both describe AI activity that outpaces inventory, ownership, and approval. The article’s strongest operational signal is that real-time monitoring must become the default for AI behaviour, because unknown tools and expanding entitlements produce the same governance gap: access you cannot explain, certify, or quickly revoke. Practitioners should fold AI discovery, entitlement scope, and runtime monitoring into one governance motion.

From our research library:

• 13% of organisations suffered breaches of their AI models, according to IBM's Cost of a Data Breach 2025 report.
• Read next: Agentic AI Identity Maturity Model

What this signals

AI data access blast radius: the useful governance question is no longer which model is deployed, but how far an AI identity can reach once it is connected to sensitive data. That reach should be measured continuously, because periodic review cannot keep pace with agents that expand their effective scope as workflows change.

The article’s strongest programme signal is that AI security, IAM, and data governance are converging around the same runtime control problem. Organisations that can map AI data flows, entitlements, and ownership together will have a clearer path to limiting overexposure and proving compliance.

Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. That kind of visibility gap is a warning for AI governance too, because low observability makes both privileged service accounts and AI identities hard to contain.

For practitioners

• Discover and classify AI-fed sensitive data Map the datasets that train, prompt, augment, or inform AI systems, then tag regulated records, intellectual property, and other high-risk data so access can be governed by sensitivity rather than system name.
• Create AI-specific identity policies Assign each model or agent a defined identity scope, tie permissions to business purpose and data classification, and remove access automatically when the AI use case changes.
• Deploy continuous AI security posture monitoring Track configuration drift, data movement, and policy compliance in real time so new connectors, new datasets, or new entitlements are detected before they become exposure paths.
• Treat prompts and outputs as governed interfaces Classify the prompt and response layer as a data-handling surface, then monitor which tools process sensitive content and how that content is reused downstream.
• Vet third-party and open-source AI components Review model provenance, maintainer posture, and the data each component can access before deployment, especially when the tool chain can inherit sensitive enterprise data.

Key takeaways

• AI security failures are increasingly about uncontrolled data access, not just model behaviour or adoption speed.
• Autonomous AI agents intensify governance risk because they can operate beyond human-paced review cycles.
• The control that matters most is continuous visibility into AI data flows, entitlements, and ownership.

Key terms

• AI Security Posture Management: A governance approach for discovering and tracking AI assets such as models, agents, datasets, vector stores, and related infrastructure. It becomes useful only when inventory is connected to runtime exposure and the identity that can actually reach the data.
• AI-Specific Identity: AI-specific identity is the governed access profile assigned to a model, copilot, or autonomous agent. It defines what data the AI can reach, what actions it can trigger, and when access must be removed, making the AI subject to identity control rather than a generic application.
• Data Centric Security: Data Centric Security protects information itself, rather than relying only on the security of systems that store or move it. It uses controls such as classification, encryption, tokenization, access policies, and usage restrictions so data remains protected wherever it travels, is copied, or is processed across cloud, endpoint, and application environments.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

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.