AI is being deployed everywhere, fast. Copilots summarize meetings. Code assistants write production software. Sales agents prospect and qualify leads. Customer service bots resolve tickets. And increasingly, fully autonomous agents read, write, and act on enterprise data without a human in the loop.
The speed of adoption has outpaced security’s ability to keep up. Only about 3% of the average organization’s data estate is connected to AI today, and analysis of enterprise environments consistently shows that 99% of organizations have sensitive data exposed to AI tools.
As AI gets connected to more data, every dormant data risk in the enterprise becomes an active AI risk. This is the 3% paradox: organizations that move too fast expose sensitive data at machine speed. Organizations that move too slowly starve AI of the fuel it needs to deliver value. Either way, you lose.
AI doesn’t create new data risks. It amplifies existing ones. Excessive permissions that sat dormant for years become critical when an agent inherits them. Sensitive data that was theoretically accessible becomes practically exposed when an AI can find it, reason over it, and act on it in seconds.
The security industry’s initial response has been to bolt AI-specific controls onto existing stacks: prompt filters, model scanners, standalone inventories. These address the AI layer. They miss the data layer. And the data layer is where the real damage happens.
This paper lays out what a comprehensive AI security approach looks like — what each capability requires to work well, why each one is stronger when connected to the others, and where the whole thing falls apart if you ignore the data underneath.
Inventory: You can’t secure what you can't see
AI enters organizations from every direction. IT deploys Copilot. Developers spin up LLM endpoints and wire together MCP servers in code repositories. Marketing signs up for AI writing tools. Sales adopts AI prospecting platforms. SaaS vendors quietly embed AI features into products already in use. The result is a sprawling, largely invisible AI ecosystem that grows faster than any inventory process designed for traditional IT assets.
Shadow AI is more dangerous than shadow SaaS. A rogue SaaS app stores some documents. A rogue AI system queries, reasons over, and acts on sensitive data. And a modern AI deployment isn’t just a model — it’s agents, tools, MCP servers, prompt templates, RAG pipelines, vector databases, training datasets, and dependencies, each with its own risk profile.
What effective AI discovery requires
Static scanning is an obvious starting point for AI discovery. Scanning cloud accounts, code repositories, AI platforms, and SaaS usage, paired with edge monitoring, catches new AI systems as they appear. But static discovery has a blind spot: it can only find what it knows to look for: systems that are declared in configuration, registered with known services, or explicitly represented in metadata.
Runtime discovery closes that gap. It treats the prompt as a discovery surface, revealing tools, data connections, and capabilities as they’re actually used. For example, when a developer’s custom agent fires up, issues a prompt, and invokes an MCP server that connects to an internal PostgreSQL database, that entire chain is assembled dynamically at runtime and declared nowhere in advance. Static scanning would never find it, but runtime analysis of the prompt exposes these interactions as they occur. Discovery alone isn’t enough, however.
What matters is dependency mapping: how does each AI system connect back to data? Trace the full chain — endpoint → model → tools → pipelines → training data → data stores. Without this map, you’re inventorying labels, not understanding risk.
Why it’s better connected
Inventory feeds everything downstream. Posture can’t assess what isn’t discovered. Monitoring can’t watch what isn’t known. Compliance can’t govern what isn’t documented. And runtime monitoring constantly enriches the inventory — new tools, new data connections, new agent behaviors observed in production inform a living map that static scanning alone can’t maintain.
With a comprehensive inventory in hand, the next question becomes: which of these AI systems are vulnerable?
Posture and red teaming: Finding risks before attackers do
Knowing AI systems exist isn’t enough. You need to know where they’re vulnerable — and whether those vulnerabilities are exploitable. Posture assessment and red teaming are two sides of the same coin: passive analysis and active testing. One without the other gives a false sense of security.
What posture assessment needs to cover
AI systems have a uniquely broad attack surface. Effective posture assessment must span all of it:
-
Code and dependency vulnerabilities — the same rigor applied to traditional software, now extended to AI components, agent frameworks, and MCP server implementations.
-
Configuration and deployment issues — are guardrails enabled? Are tool permissions scoped correctly? Are MCP servers exposing capabilities beyond their intended scope? Are API keys rotated? Are logging and audit trails active? Configuration drift in AI systems tends to happen faster than in traditional infrastructure because the components change so frequently.
-
Agentic risk — what actions can agents take? What happens when an agent chains tools in unintended ways? What’s the privilege escalation path? Look for excessive agency — agents with more autonomy or capability than their task requires — and tool poisoning, where a compromised or malicious tool in an agent’s toolkit manipulates the agent’s behavior.
-
Sensitive data exposure — which AI systems have access to regulated, confidential, or high-value data? This includes structured databases, but also notebooks, source code repositories, and unstructured file stores. A posture scan that says “this agent can access SharePoint” is very different from one that says “this agent can access 2.3 million customer records including PII and payment card data.” Source code deserves particular attention — it’s a common blind spot for data loss, and AI coding assistants now make it trivially easy to exfiltrate or leak proprietary code through prompts.
-
Model vulnerabilities — is the model susceptible to known attack techniques? Are safety alignments robust? Are there known bypasses in the model version deployed?
What red teaming requires
Posture tells you what could go wrong; Red teaming tells you what does. That means adversarial testing against live LLM endpoints: prompt injection, jailbreaks, policy bypass, data exfiltration attempts, and indirect prompt injection through documents and emails.
These aren’t theoretical risks. The Reprompt attack chains parameter injection, double-request bypass, and chain-request escalation to silently exfiltrate data through a single click on a legitimate Microsoft Copilot link.
The EchoLeak vulnerability is worse: a zero-click attack that exfiltrates entire Copilot chat histories and referenced files through indirect prompt injection embedded in an email. No user interaction required.
Testing must be continuous. Integrating adversarial testing into the CI/CD pipeline means every model update, prompt change, or new tool connection triggers a security evaluation before it reaches production — the same way code changes trigger unit tests. AI systems change constantly — new models, new prompts, new tools, new data connections. A pen test from last quarter doesn’t reflect today’s risk.
Why they’re better connected
Posture findings should prioritize red team targets — test the highest-risk configurations first. Red team results should flow back into posture scoring — a vulnerability confirmed by testing carries different severity than one that’s unproven. Runtime activity data provides realistic test scenarios: captured prompt/response datasets make far better inputs for adversarial testing than synthetic ones.
Red teaming should also be used to validate runtime guardrails — run the same attack battery with guardrails on, then off. If the results are the same, the guardrails aren’t doing their job. Which brings us to runtime.
Runtime: guardrails, monitoring, and why they should be the same system
Pre-deployment controls will never catch everything. An agent that passed testing might behave very differently with real-world inputs, adversarial users, or unexpected data combinations. The real security challenge starts when AI operates on live data — and that requires both enforcement and visibility, working together.
Guardrails
Guardrails enforce policies in the live request path — inspecting prompts, responses, and agent actions and blocking violations before they execute. Effective guardrails go beyond keyword filters. They need to understand execution flow, agent tool chains, and indirect leakage paths.
A guardrail that blocks “send me the SSN” but misses an agent quietly writing PII to an external API through a tool call isn’t a guardrail — it’s theater.
Monitoring
A complete audit trail of AI activity: every prompt, every response, every agent action, every tool call, every data access event, every guardrail decision. Real-time behavioral analytics to detect anomalous patterns and unexpected interactions. SIEM and SOAR integration so AI alerts fit into existing security operations workflows rather than creating yet another console to watch.
Why they should be the same system
If guardrails and monitoring are separate stacks, every request gets inspected twice — once to enforce, once to log. That’s double the latency, double the integration surface, and double the gaps. A unified runtime layer enforces and observes in a single inspection pass, producing two outputs: enforcement decisions and audit data.
That audit data should serve multiple consumers. Security teams use it for threat detection. AI teams use it for performance and usage analytics. Compliance teams use it as evidence. Red teams use it to build realistic test datasets.
This is where LLM-as-a-judge becomes a force multiplier. Beyond evaluating guardrail effectiveness — running production traffic with guardrails on versus off to measure what’s being caught — LLM-based evaluation can score response quality, detect policy drift over time, flag hallucinations, assess whether agent actions align with their stated intent, and benchmark performance across model versions. Point it at any LLM endpoint. Use production data instead of synthetic test cases. The runtime layer generates the corpus; the evaluator makes it useful.
Deployment optionality
Not every architecture needs a gateway. Sometimes an SDK or sidecar approach is better — less latency, tighter integration, no extra network hop. Organizations that already have an API gateway shouldn’t be forced to replace it. Runtime enforcement should integrate with what’s already in the request path. For enterprises with diverse AI deployments — cloud-hosted, on-prem, embedded in SaaS — optionality is a requirement, not a feature.
The question runtime alone can’t answer
A runtime layer sees a tool call. It sees the prompt and the response. But what did that tool call do to the data behind the MCP server? What else can that identity access? What sensitive data was touched?
Without visibility into the data layer, runtime monitoring captures actions but not consequences. The log says the agent made a Salesforce API call. It doesn’t say the call accessed 50,000 customer records including payment card data — or that the service account behind it has admin access to three other data stores nobody is watching.
Runtime tells you what AI is doing. It can’t tell you what it means. For that, you need context that lives outside the AI stack entirely — in the data, in the permissions, and in the identities. But first, two more capabilities that round out the AI security lifecycle: compliance and third-party risk.
Compliance: proving you’re not just hoping for the best
The regulatory landscape for AI is accelerating. The EU AI Act imposes obligations for high-risk AI systems: transparency, human oversight, data governance, and risk management. The NIST AI Risk Management Framework provides lifecycle risk management guidance. ISO 42001 establishes management system requirements. Sector-specific rules in financial services, healthcare, and government add further layers.
The manual reality
Without automation, AI compliance looks like this: manually inventorying every AI system. Classify each by risk tier. Document data inputs, outputs, and dependencies. Assess controls against each regulatory framework. Compile evidence for auditors. Repeat when anything changes, which in AI environments is constantly. Most organizations don’t have the underlying data to even begin: they can’t enumerate their AI systems, don’t know what data each one touches, and have no audit trail of AI activity.
What’s possible with automation
Now imagine a system that already knows the regulatory requirements, already knows the organization’s AI security policy, already has access to the full AI inventory, the posture assessments, and the runtime activity data. An LLM-powered compliance engine maps AI systems to risk tiers, identifies applicable requirements, cross-references existing controls, flags gaps — and then asks only for what it needs. Human judgment where it matters. Automation everywhere else.
The output: audit-ready reports with evidence attached. Not assertions — discovery inventories, posture findings, pen test results, runtime logs, guardrail enforcement records, data lineage. Documentation that would take a compliance team weeks to compile manually is generated continuously as a byproduct of the security controls already running.
Why it’s better connected
Compliance without inventory is guesswork. Compliance without posture data is assertion without proof. Compliance without runtime monitoring is a snapshot that’s stale before the auditor reads it. The stronger each upstream capability, the richer and more defensible the compliance output.
The same logic applies to third-party risk — where the compliance challenge extends beyond the organization’s own boundaries.
TPRM: your vendors’ AI is your problem
Every SaaS vendor is embedding AI into their products. Your CRM, your HRIS, your collaboration platform, your code repository — all processing your data through models you didn’t choose, with configurations you don’t control.
The manual reality
Today, onboarding a vendor that uses AI looks something like this: send a questionnaire that vendors hate answering and answer generically. Receive an AI Bill of Materials that nobody knows how to evaluate. Read through EULAs, privacy policies, and data processing agreements. Cross-reference all of it against the organization’s AI security policy and third-party risk requirements. Repeat for every vendor, every renewal, every new AI feature they ship.
Most organizations either skip this entirely or do it superficially — a checkbox exercise that provides false confidence.
What’s possible with automation
There’s a better approach. The organization has a security policy for third-party AI. Vendors have questionnaires, EULAs, BOMs, data processing documentation. Automation that leverages LLMs can do the legwork — ingesting every document, cross-referencing against policy requirements, identifying gaps, flagging risks, and surfacing only the questions that need human judgment. TPRM teams and compliance teams get dramatically more efficient. Instead of weeks of analyst time per vendor, the result is a structured risk assessment with gaps highlighted and follow-up questions generated — in hours.
Assessment shouldn’t be point-in-time, either. When a vendor ships a new AI feature or changes data processing practices, the assessment should update.
Why it’s better connected
TPRM informed by runtime data knows which vendors are processing your data through AI — not just which ones say they might. TPRM informed by data sensitivity knows the risk impact: a vendor processing public marketing content through AI is a different conversation than one processing customer PII.
All of these capabilities — inventory, posture, red teaming, runtime, compliance, TPRM — secure the AI stack. But they share a common assumption: that the data underneath is also secure. What happens when it isn’t?
The missing layer: when AI is secure but data isn’t
An organization deploys a comprehensive AI security platform. Inventory is complete. Posture is assessed. Guardrails are running. Monitoring is active. Compliance reports are generated. Vendors are assessed.
And then an AI agent — fully authorized, passing all guardrails — quietly accesses four million customer records. The access is legitimate. The agent has permission. The guardrails let it through because the request wasn’t malicious. The data was just… there. Exposed. Accessible to anything with a broad permission set. The AI system worked perfectly. The data security system didn’t.
This pattern repeats in every architecture:
-
Microsoft Copilot surfaces board meeting notes to a junior employee — not because Copilot is misconfigured, but because SharePoint permissions are too broad. The AI didn’t create the exposure. It surfaced it.
-
A Salesforce Agentforce agent inherits a sales user’s permissions — including access to the full customer database, not just their accounts. The agent wasn’t designed to access other reps’ customers. It just can. And unlike most humans, it will.
-
A RAG pipeline indexes a shared file system for retrieval. The file share contains sensitive HR documents that were never meant to be searchable. The AI didn’t put them there. It made them findable.
-
A homegrown agent in AWS uses a service account to query a PostgreSQL database for customer analytics. The service account was provisioned years ago with broad read access for a reporting tool that’s since been decommissioned. Nobody revoked it. The agent now has access to every table in the database, including ones with payment data and health records that have nothing to do with analytics.
-
A third-party vendor’s AI assistant processes support tickets and is granted API access to the organization’s Jira instance. Jira contains not just support tickets but internal security findings, vulnerability reports, and incident response notes. The vendor’s AI Bill of Materials showed model details and data retention policies — but nobody connected the dots between the API scope granted and the sensitive data in Jira. Buried in the vendor’s EULA: a clause stating that data ingested for model improvement cannot be deleted upon contract termination. The AI security platform flagged the vendor as low-risk. The full picture — data exposure, irrevocable retention, and sensitive content — told a very different story.
The identity problem
AI makes the identity layer harder, not easier. In the traditional world, a human authenticates with a known identity and takes actions that can be attributed to them. In the agentic world, agents operate through service accounts, local database credentials, and shared API keys that don’t map cleanly to any individual.
Many databases still use local service accounts and aren’t SCIM-enabled. There’s no federated identity model for agent-to-database connections. Agentic identity attenuation — the ability to scope an agent’s effective permissions below its technical access — is still an emerging concept with nascent standards.
In the meantime, organizations need to know which identities AI systems are using, what those identities can access, and whether that access is appropriate. That means monitoring the data layer directly — watching what happens at the database, the file system, and the API, not just what the AI layer reports. This is the role that database activity monitoring has always played, but it now needs to extend to every data store an agent can reach and tie every action to a resolved identity, even when the agent operates through a shared service account.
The pattern
In every one of these scenarios, the AI system is working as designed. The security failure is in the data layer: excessive permissions, sensitive data in the wrong locations, stale access that was never cleaned up, identities that can’t be traced. AI doesn’t create data risk. It finds it, surfaces it, and acts on it — faster and more thoroughly than any human ever could.
Adding more AI security controls doesn’t solve this. Securing the data does: classifying what’s sensitive, remediating excessive permissions, monitoring access continuously, tying every action to an identity, and doing all of it across every data store an AI system can reach.
Does your AI security approach extend to the data layer — or does it stop at the prompt?
Complete AI security requires complete data security
AI security is not a single capability. It’s an interconnected set of challenges spanning the full lifecycle — from the moment an AI system appears in the environment to every action it takes in production and every third-party AI service in the supply chain.
Complete AI security means:
- Inventory — continuous discovery of every AI system, agent, model, and dependency, enriched by runtime observation.
- Posture and Red Teaming — assessing vulnerabilities and excessive access with full data context, and continuously testing whether those risks are exploitable.
- Runtime — guardrails and monitoring as a single system, with deployment optionality and activity data that feeds back into testing and compliance.
- Compliance — LLM-automated mapping to EU AI Act, NIST AI RMF, and ISO 42001 with audit-ready evidence.
- TPRM — automated third-party AI risk assessment that replaces manual document review with intelligent gap analysis.
Complete data security means:
- Continuous classification of sensitive data — not sampling, not periodic scans, but real-time understanding of what’s sensitive and where it lives.
- Full permission mapping tied to identities — human and machine — with automated remediation of excessive exposure.
- Automations that lock data down — permissions, sharing links, configurations, entitlements, group memberships, data masking, and labeling. Automation that moves or quarantines data when it’s in the wrong place. Monitoring of OAuth apps and third-party integrations in SaaS. Not just visibility — enforcement.
- Continuous activity monitoring across every structured, unstructured and semi-structured data store — SaaS, IaaS, on-prem, and databases — with identity-enriched detection and response.
- Behavior-based detective controls that detect insiders, ransomware, external attackers, and AI abuse — using behavioral baselines, not just signatures.
Neither alone is sufficient. AI security without data security leaves the biggest risk vector unaddressed. Data security without AI security misses the fastest-growing threat vector.
How Varonis helps
Varonis Atlas delivers the full AI security lifecycle in a single platform: inventory, posture, red teaming, runtime guardrails and monitoring, compliance automation, and TPRM.
The Varonis Data Security Platform delivers the data security foundation: continuous classification, full permission mapping with automated remediation, preventive controls that lock down exposure automatically, continuous activity monitoring across SaaS, IaaS, on-prem, and databases, and behavior-based detection and response for insiders, ransomware, external attackers, and AI abuse.
The integration between Atlas and the Data Security Platform is what makes every AI security capability deeper: posture assessment with real data context. Guardrails informed by classification. Monitoring enriched with identity and sensitivity. Compliance evidence that includes data lineage, not just AI system metadata.
This is not a DSPM bolted onto an AI scanner. DSPMs sample — they don’t see every file, every permission, or every access event. DLP reacts at the point of egress — it doesn’t remediate exposure before it can be exploited. Database activity monitors watch a single data store — they don’t correlate activity across SaaS, cloud, and on-prem or tie it to a unified identity model. The Varonis Data Security Platform does all of this, continuously, across the full data estate. Atlas extends that foundation to AI.
The gap between AI adoption and AI security has never been wider. Closing it requires more than AI-layer controls. It requires an approach that secures AI and the data that powers it — together, continuously, and in context. Want to see how it fits into your organization? Sign up for a demo.
