The AI Data Readiness Audit: Part 1, Discovering What AI Can Actually Access

Part 1 of a 4-part series. This post covers the discovery phase of the AI Data Readiness Audit: mapping every data store your AI systems can reach before you can classify, govern, or remediate anything.

The series:

• Part 1: Discovering What AI Can Actually Access (this post)
• Part 2: Classifying Sensitive Data at AI Scale
• Part 3: Enforcing Least-Privilege Access for AI Systems
• Part 4: Continuous Monitoring and Automated Remediation

You cannot classify what you have not found. You cannot govern what you have not classified. And you cannot remediate what you have not governed. Discovery is the foundational step of every AI data readiness program, and it is also the step most organizations have the least confidence in.

Most security teams have a partial picture of their data estate. They know the major production databases. They have a reasonable understanding of what lives in their primary cloud storage buckets. They have some visibility into the SaaS platforms their employees use most. What they almost universally lack is a complete, current picture of everything their AI systems can actually reach, including the systems, folders, databases, and file shares that were never designed to be AI-accessible but became so the moment an agent was connected to an identity that had accumulated access to them over years.

This post covers how to build that picture. It is structured as a working guide with a checklist you can use immediately, regardless of what tools your organization currently has in place.

Why point-in-time discovery fails in an AI environment

The traditional approach to data discovery is a periodic audit. A team runs a scan, produces a report, and the organization has a snapshot of where data lives as of the date that scan completed. That model was always imperfect, but it was defensible when data estates changed slowly and access was primarily granted to human users whose onboarding and offboarding processes provided some natural governance checkpoints.

Neither of those conditions holds in an AI environment.

AI agents are being deployed continuously, and not by security teams running formal onboarding processes, but by developers, data engineers, and business units building workflows that need data access to function. Each new agent inherits the access of the service account, API key, or user identity it runs under. If that identity was provisioned months or years ago and has accumulated access across multiple systems, the agent that inherits it has access to all of those systems immediately, from the moment it is deployed.

A discovery picture that is 30 days old, or even 7 days old, is already missing every agent deployed since the last scan ran, every new data store those agents were connected to, and every change in access permissions that happened in the intervening period. The gap between the last discovery and the current reality is the window in which your AI exposure is completely invisible.

This is why discovery, for an AI data readiness program to function, has to be continuous rather than periodic.

The five categories of data stores AI can reach

Before running a discovery process, it helps to have a clear mental model of the full scope of what AI systems can potentially access. Most organizations undercount their exposure because they think about data stores in terms of what they formally registered or provisioned, rather than what AI can technically reach through inherited identity access.

1. Cloud-managed and unmanaged data stores include relational databases running on managed services such as Amazon RDS, Azure SQL Database, and Google Cloud SQL, as well as unmanaged databases running on virtual machines and cloud-provided disk snapshots. Both are accessible to AI systems through the service accounts and API keys those agents run under. Unmanaged instances are particularly prone to discovery gaps because they were often spun up for specific projects and never formally decommissioned.

2. Cloud serverless and object storage includes data lakes, S3-compatible object storage, and cloud-native analytics platforms. These tend to be large, heterogeneous, and poorly inventoried. A single S3 bucket can contain terabytes of data spanning multiple business functions, age ranges, and sensitivity levels, and AI systems connected to data pipelines that touch those buckets may be reaching all of it.

3. SaaS datastores include SharePoint, OneDrive, Google Drive, Salesforce, Confluence, Notion, and every other SaaS platform your organization uses to store business data. AI copilots and productivity agents are disproportionately likely to be connected to collaboration and productivity SaaS platforms because that is where the documents and records employees want AI to help them with actually live. SaaS platforms are also where the most sensitive unclassified data tends to accumulate, because employees have been storing sensitive documents in shared drives for years with minimal governance oversight.

4. On-premises file servers and databases are not protected by virtue of being on-premises. Many organizations deploy AI tools that connect through VPN or internal APIs to on-premises resources, and service accounts used by those AI systems often have broad access to file servers that were never designed to be machine-queryable at scale.

5. AI-specific environments include model registries, vector databases, embedding stores, RAG knowledge bases, and AI agent frameworks. These are newer categories that most discovery programs have not yet been built to cover. They are particularly important because they represent the direct input layer for AI model behavior, and sensitive data that ends up in a RAG knowledge base or vector store does not just sit there, it actively shapes AI outputs.

The discovery checklist

Work through this checklist systematically. Some items will require technical investigation. Others require conversations with teams outside security, specifically data engineering, cloud operations, and the business units deploying AI tools.

Cloud infrastructure

• 
  Enumerate all active cloud accounts across AWS, Azure, and GCP, including sub-accounts, development accounts, and accounts created for specific business units or projects
  
• 
  List all managed database instances (RDS, Cloud SQL, Azure Database) in each account
  
• 
  List all unmanaged database instances running on VMs or containers in each account
  
• 
  List all object storage buckets and data lake storage accounts, including those in non-production accounts
  
• 
  Identify which buckets and databases are accessible to service accounts used by AI systems or automation
  
• 
  Check for snapshot inventories, as database snapshots are frequently forgotten and often contain production data
  

SaaS and collaboration platforms

• 
  List every SaaS platform the organization uses that stores business data (SharePoint, OneDrive, Google Drive, Salesforce, Confluence, Notion, Slack, Jira, and any industry-specific platforms)
  
• 
  Identify which SaaS platforms have AI copilots, plugins, or integrations enabled
  
• 
  Identify which service accounts or OAuth connections have been granted access to these platforms on behalf of AI tools
  
• 
  Check for third-party SaaS integrations that relay data between platforms, as these create data access paths that neither platform's native access controls fully cover
  

Data warehouses and analytics platforms

• 
  List all data warehouse instances (Snowflake, BigQuery, Redshift, Databricks)
  
• 
  Identify which AI systems, notebooks, or pipelines have active query access to each warehouse
  
• 
  Check for shared service accounts with broad access used across multiple analytics workloads
  
• 
  Identify any external tables or data shares that expose data outside the primary warehouse environment
  

On-premises and hybrid environments

• 
  Enumerate on-premises file servers that are reachable from cloud environments via VPN, direct connect, or hybrid networking
  
• 
  List databases running on-premises that are accessible through APIs or JDBC/ODBC connections used by cloud-based AI tools
  
• 
  Identify service accounts used by hybrid workflows that have access to both cloud and on-premises resources
  

AI-specific environments

• 
  List all vector databases and embedding stores (Pinecone, Weaviate, Chroma, pgvector, and equivalents)
  
• 
  List all RAG knowledge bases and the data sources those knowledge bases were built from
  
• 
  List all model registries and the datasets used to train or fine-tune models stored there
  
• 
  Identify all AI agent frameworks deployed in your environment (LangChain, AutoGen, Semantic Kernel, and equivalents) and the data connections each framework has been configured with
  
• 
  Check for AI browser extensions and local AI tools installed on employee devices that have been granted access to corporate SaaS accounts
  

Identity and access mapping

• 
  List all service accounts, API keys, and OAuth tokens created in the last 24 months
  
• 
  For each service account used by an AI system, document which data stores it has access to
  
• 
  Identify service accounts that have not been used in the last 90 days but still have active permissions
  
• 
  Identify human identities whose OAuth tokens have been used to authorize AI integrations without a corresponding security review
  

What the discovery process usually reveals

Organizations that run this exercise for the first time consistently report the same three surprises.

The first is the scale of the SaaS exposure. Most security teams focus their data discovery efforts on databases and cloud storage. When they map the AI access paths connecting to SharePoint libraries, Confluence spaces, and Google Drive folders, they typically find sensitive documents that were never formally governed because the platforms that held them were treated as collaboration tools rather than data stores. AI copilots connected to those platforms have access to all of it.

The second is the number of forgotten resources. Development databases, test environments, analytics sandboxes, and project-specific data stores that were provisioned and never decommissioned make up a significant fraction of the total AI-accessible data surface in most organizations. These resources are often the ones that contain the most sensitive data, because they were frequently built using copies of production data that nobody ever removed.

The third is the service account sprawl. Most organizations have far more service accounts than they expected, and those service accounts have accumulated far more access than any individual person authorized them to have at any single point in time. The access that a service account holds today is often the union of every permission that was ever granted to it, with very few of those permissions ever having been revoked.

Why discovery has to run continuously, not once

Running through the checklist above gives you a point-in-time picture. That picture is accurate as of today. Tomorrow it will be slightly less accurate, because new agents will be deployed, new data stores will be created, and existing service accounts will be granted new access. By next month, a periodic discovery effort will have missed every new AI integration, every new cloud account spun up for a project, and every new SaaS tool a business unit has started using.

The discovery process has to be architected to run continuously, automatically detecting new data stores as they are created, new service accounts as they are provisioned, and new AI integrations as they are enabled, rather than as a project that gets resourced once and then relies on the team's memory to stay current.

This is the gap where manual discovery processes fail permanently. It is not that the initial discovery was done badly. It is that the environment changed faster than a human process could track it.

How Sentra approaches discovery

Sentra's discovery engine is designed for the continuous model described above. It provisions ephemeral scanners directly inside the customer's cloud environment, agentlessly and without requiring network access to scanning targets, and those scanners run automatically as the data estate changes rather than on a fixed schedule.

Coverage spans cloud-managed databases (through snapshot APIs), cloud unmanaged instances (through disk image mounting), cloud serverless and object storage (through Cloud Data APIs), SaaS datastores (through API-based scanning), and on-premises file servers and databases (through connectivity-based scanning). New accounts and data stores are discovered automatically as they appear, so the inventory stays current rather than drifting from the point at which the last manual scan ran.

Incremental scanning means that only changed data is rescanned on subsequent passes, which addresses the cost problem that makes continuous discovery impractical when done by legacy tools. Only metadata, including classification labels,, risk signals, and access relationship maps, the customer environment. Sensitive data never copies out for analysis.

The result is a continuously updated inventory of every data store accessible from the customer environment, including the AI-accessible paths that most organizations have never had a complete picture of.

Start your AI Data Readiness Audit today. Download the checklist. Then request a demo to see what Sentra finds that the checklist alone cannot.

Key takeaways

• Point-in-time discovery is structurally insufficient for AI data readiness because AI agents are deployed faster than manual audit cycles can track them.
• A complete discovery scope covers five categories: cloud-managed and unmanaged data stores, cloud serverless and object storage, SaaS platforms, data warehouses, on-premises environments, and AI-specific environments including vector databases and RAG knowledge bases.
• The three most common surprises from a first discovery exercise are the scale of SaaS exposure, the number of forgotten resources that still contain sensitive data, and the breadth of service account access that has accumulated without review.
• Discovery has to run continuously to remain useful. A monthly or quarterly audit cadence produces a picture that is already stale by the time governance decisions are made against it.
• The checklist in this post provides a starting framework. The goal of the discovery phase is a complete, continuously updated inventory of every data store an AI system can reach, which becomes the foundation for the classification work covered in Part 2