How to Audit AI Compliance from Both Sides of the Table

The tricky thing about AI compliance is that most organizations are going to experience it from both sides. You need to be able to explain how AI is being used inside your own organization, what it can access, and how you're managing the risk. At the same time, you need to understand how your vendors are using AI and whether that introduces new risk into your environment. 

This may sound simple, but it's actually a bit convoluted. AI is increasingly appearing in approved enterprise tools, existing SaaS products, developer workflows, agents, and tools employees adopt on their own. Model Context Protocol (MCP), a tool that makes it possible for AI models to connect with outside tools and data, is making it easier to connect AI applications to external data and systems. And behind any one AI-enabled product there may be several other providers, models, APIs, or subprocessors involved.

There also isn't one universal "AI compliance audit." Requirements will vary depending on the laws, frameworks, contracts, and use cases that apply to an organization. NIST's AI Risk Management Framework and its Generative AI Profile, for example, are voluntary guidance, but they provide a useful model for thinking about AI inventory, third-party risk, information security, data, and ongoing monitoring. So rather than trying to create another generic AI compliance checklist, I think it's more useful to start with what organizations need to understand and be able to demonstrate.

Start with auditing your AI inventory 

Like most security obstacles, visibility is the first step. Most organizations probably have a reasonably good idea of the AI they've formally approved: enterprise copilots, internal AI projects, sanctioned SaaS applications, and approved model providers.

The harder part is everything that happens outside that process. Employees can sign up for an AI tool in minutes. Developers can experiment with new models, APIs, agents, and integrations. Maybe your existing software vendors add AI capabilities to products that were originally purchased for something completely different and forget to tell you. Suddenly, ShadowAI is a much bigger problem, and now, a governance problem. Every new tool can introduce another provider and another risk your security team may not be aware of. This is an expansion of both the attack surface and the third-party ecosystem.

An AI inventory is therefore a good starting point, but it can't be the end of the audit. Knowing an application exists doesn't tell you enough about the risk it creates.

Access matters as much as the model

The next layer is understanding what the AI can actually reach, i.e. how much data can it access and what level of permissions does it have? There is a substantial difference between an AI tool generating a paragraph of marketing copy and an agent that can access source code, email, customer records, cloud resources, or financial data. Once AI becomes connected to other systems, identity and permissions become part of the AI risk story. 

It is more important than ever to look at who can use the system, what credentials and permissions it relies on, what information it can read, whether it can modify anything, what actions it can take, and whether those actions are logged and reviewable. 

Questions to consider when performing an AI audit:

• What data is your vendor’s AI platform using to make your life easier? 
• What happens if that data ends up in the wrong hands? 
• What happens if an attacker gets into that AI system? 

MCP adds to your audit surface

This brings me to MCP. MCP is an open protocol for connecting LLM applications with external tools and data sources. MCP servers can expose resources and tools to AI applications, allowing the model or application to retrieve context or perform actions. The current MCP specification includes authorization mechanisms for HTTP-based implementations, but authorization is optional at the protocol level, and the specification makes clear that implementers still need appropriate consent, authorization, access controls, and data protections. In other words, MCP doesn't magically create or govern permissions for you. The real risk depends on how the MCP server is configured, what it connects to, what credentials are involved, and what capabilities have been exposed. That expands the audit surface. An organization may know which AI application it approved without having a complete picture of every tool, API, data source, or MCP server that application can reach.

Your AI audit should follow the data

Then there is the data itself. AI is great at helping to sort through data, and it can also create new paths for information to move. Have you considered which other AI platforms your vendor relies on? The NIST Generative AI Profile specifically calls attention to risks created by third-party components, data, models, and services in generative AI systems, which is one reason AI governance can't stop at the model itself.

For AI audit purposes, the practical goal is to understand the data path: what information can reach an AI system, where it is processed, what third parties may receive it, what retention or training terms apply, and what controls exist around sensitive information. Policies are helpful but can be weak if not backed up with evidence. It is important to be able to show how an organization identifies AI use, governs access, and detects exposure.

Then flip the audit back towards vendors

Now take those same concerns and apply them to a vendor. This is where I think the AI compliance audit conversation gets especially interesting. Organizations aren't only responsible for governing the AI they deploy themselves. They also need a way to evaluate the risk created when their suppliers, technology providers, and other third parties introduce AI into the services they depend on. A questionnaire that simply asks "Do you use AI?" isn't going to get you very far. A useful vendor assessment needs to get underneath that answer. You want to understand what AI capabilities are involved, what customer data can reach them, whether another model provider or subprocessor is involved, how access is governed, what the system is allowed to do, and how the vendor monitors and tests its AI use.

AI systems can bring models, cloud infrastructure, APIs, plugins, and other external services into a single workflow. That can quietly expand the number of organizations involved in processing data or delivering a service. Bitsight's recent research on shadow AI makes the same point: AI adoption can expand an organization's third-party ecosystem without going through the normal vendor-management process. That makes AI risk a third-party risk problem, not just an internal governance problem.

The audit needs more than attestation

Policies, questionnaires, documentation, and internal controls all have a role here. But they share one limitation: much of the information is based on what the organization or vendor says is happening.

I find it useful to think about AI audit evidence in three layers:

• What you know: the approved models, AI-enabled applications, agents, MCP servers, owners, vendors, and intended use cases in your inventory.
• What it can reach: identities, permissions, connected systems, data, APIs, MCP tools, and actions the AI is authorized to perform.
• What is actually exposed: the external assets, AI integrations, MCP infrastructure, vulnerabilities, and third-party exposures that are observable in the environment.

Those layers aren't interchangeable. IAM and access-management systems are better positioned to tell you what an identity is authorized to do. Data Loss Prevention (DLP) and other data-security controls can help govern sensitive information. Procurement and GRC processes help manage approvals and policy.

Where Bitsight fits

Bitsight can contribute to the external evidence layer of this problem.

Bitsight Security Posture Management is designed to continuously identify and prioritize externally observable exposure, measure security posture over time, and provide defensible evidence that security leaders can use to communicate risk and improvement.

This type of outside-in discovery becomes increasingly important as AI expands the external attack surface. Public-facing AI services, connected infrastructure, and exposed MCP servers can create risks that may not be represented in an internal inventory.

But there are limits to that visibility. External observation will not identify every internally deployed AI application, local MCP server, prompt, permission, or internal data flow. Bitsight’s own TRACE research into MCP focused on remotely accessible HTTP-based servers rather than local or internal deployments. That is why external intelligence should complement, not replace, internal identity, data security, procurement, and governance controls.

On the supply chain side, Bitsight Third-Party Risk Management combines vendor assessments and documentation with continuous, objective monitoring. Its current capabilities include automated vendor assessments, continuous third- and fourth-party visibility, vulnerability detection and response, and AI-powered analysis of vendor evidence. This gives risk teams another source of evidence rather than forcing them to depend exclusively on point-in-time questionnaires and attestations.

AI compliance has an evidence problem

A lot of the fundamentals of AI governance will sound familiar. Organizations still need inventory, access control, data governance, third-party risk management, monitoring, and evidence that controls are working. AI complicates this. Shadow AI makes the inventory less reliable, as it's often easy for employees to introduce new AI to their environment. Agents and MCP are creating more connections between systems. Permissions are crucial as AI handles more and more data.

The use of AI throughout the vendor ecosystem means the risk doesn't stop at your own environment. So an AI compliance audit shouldn't become another exercise in producing a policy and checking a box. This underscores the importance of having insight into what AI exists, what it can access, where your data can go, and what evidence you have that those risks are being managed, this goes for both first and third party. Whether you're preparing to be audited or evaluating someone else, that's ultimately what you're trying to establish: not simply that an AI governance program exists on paper, but that you have enough visibility to know whether it's working.