Ask an organisation to describe its AI and you'll usually be given a list of tools: Copilot, ChatGPT, perhaps a chatbot on the website. That list is only the visible part of something much larger.
AI in a modern business runs across a number of layers. It is used on people's devices, through platforms bought from different vendors, and inside business applications that have switched it on as part of a routine release. It reaches into internal systems through connectors and agents, it sits on top of your identity and data, and it is governed commercially by contracts and spend that often commit you to more than is obvious. Each layer is typically supplied by different vendors and owned by a different team, and each vendor will quite reasonably focus on securing its own part. In most organisations, nobody is looking at the estate as a whole.
Getting real value from AI, safely, depends on seeing all of it. This article sets out those six layers, what sits in each, who usually owns it and the main security challenges. It is intended as a reference, so each section ends with the question we'd suggest asking.
The map
| Layer | What sits there | Usually owned by | Typical risk |
|---|---|---|---|
| 1. People and devices | Chat tools, desktop apps, extensions, coding agents, local models | End-user computing, if anyone | Shadow AI on personal accounts |
| 2. AI platforms | Copilot, ChatGPT, Claude, Gemini, model APIs | IT, a digital team, or whoever signed up first | Default settings; unmanaged API keys |
| 3. AI inside business apps | AI features in SaaS such as CRM, ITSM and HR systems | Application owners | Switched on by a release, not a decision |
| 4. Connectors and agents | MCP servers, plug-ins, skills, workflow agents | Developers and power users | Unvetted components with broad access |
| 5. Identity and data | Identity platform, SharePoint, file shares, CRM, finance, code | Identity teams and data owners | Loose permissions surfaced by AI |
| 6. Contracts and spend | Seats, tenant-wide features, metered consumption, renewals | Procurement and finance | Commitments nobody has matched to use |
Read from top to bottom, it runs from where people use AI, through what it runs on and can reach, to what it commits the business to commercially.
Layer 1: People and devices
This is where people use AI day to day: browser chat tools, desktop applications, personal AI accounts, browser extensions, coding agents and, increasingly, models running locally on laptops. Ownership usually sits with end-user computing or the service desk, where it sits anywhere at all.
The main challenge is shadow AI, meaning tools in use that nobody approved, frequently on personal accounts outside any corporate contract. Browser extensions can have permission to read every page a user visits, including internal systems, and coding agents and local models can have access to files, credentials and source code on the device. Personal and unmanaged devices sit outside your controls entirely, and firewall and proxy controls lose visibility as soon as a device leaves the office.
The question to ask: do we know what AI is running on our devices today, including what hasn't been approved?
Layer 2: AI platforms
These are the platforms that have been bought or trialled, such as Copilot, ChatGPT, Claude and Gemini, along with the model APIs used by developers and products. Ownership might sit with IT, a digital team, or simply whichever department signed up first.
Tenant and workspace settings are often left at their defaults, covering data retention, sharing, connectors and admin controls. Training and retention terms can differ significantly between the consumer, business and enterprise tiers of the same product, and API keys are regularly found embedded in code, scripts and configuration files with broad access and no expiry. It is also common to find overlapping platforms bought by different teams, each with its own policies and none with a single view.
The question to ask: for each AI platform in use, who owns it, which tier are we on, and what happens to our data?
Layer 3: AI inside business apps
Salesforce, ServiceNow, Adobe, Atlassian, Workday and most other SaaS platforms now include AI features, and many are enabled by default. Ownership usually sits with the business application owner, who may well not regard it as an AI decision at all.
Because these features tend to arrive through a routine release rather than a decision, they are easy to miss. They can send your data to model providers and sub-processors that weren't part of the original agreement, and the terms governing how your data may be used, and what the AI features cost, can change at renewal. In our experience, few organisations can list which of their SaaS applications now contain AI, let alone what it can access.
The question to ask: which of our business applications have AI switched on, and did anyone decide that?
Layer 4: Connectors and agents
This layer determines what AI can reach and what it can do: MCP servers, plug-ins, skills and workflow agents that connect AI to your systems and allow it to take action. Ownership sits with developers, power users and automation teams, often individually.
MCP servers and plug-ins are frequently installed from public sources with direct access to internal systems. A malicious or compromised component can instruct an agent to leak data or misuse its access, and the picture is moving fast: ESET's H1 2026 Threat Report found more than 3,000 malicious AI skills among the nearly 900,000 it scanned between March and May 2026. Content an agent reads, such as an email, web page or document, can also carry hidden instructions that it then follows. Agents inherit the access of whatever credentials they hold, which is usually far more than the task requires, and some will send, change or delete things with no human in the loop and no record of why.
The question to ask: what can our AI agents reach, whose credentials are they using, and who approved them?
Layer 5: Identity and data
Underneath everything sits your identity platform, such as Entra ID or Okta, and the data AI can reach: SharePoint, file shares, CRM, finance systems and source code. Identity and infrastructure teams generally own access, while data owners across the business own the content.
AI assistants search everything a user can access, so years of loose permissions become very easy to find, and access granted long ago through groups and sharing links that nobody reviews now flows straight into AI answers. Agents, service accounts and app registrations are multiplying quickly, often with standing privileges and no clear owner. Without classification, no tool can tell a public brochure from a board paper, so no policy can protect one and not the other. For a law firm, that can mean privileged material from one client surfacing in an answer for someone working on another matter. For an insurer or broker, it can mean customer data reaching a tool that was never assessed for it.
The question to ask: if an AI assistant could see everything each of our users can see, would we be comfortable?
Layer 6: Contracts and spend
The final layer is what AI commits you to commercially: subscription seats, tenant-wide features, metered consumption (tokens, credits and API usage) and renewal dates. This usually sits with procurement and finance, often separately from IT and security.
A common issue is AI switched on for everyone while security and compliance controls are licensed only for some users. Agent and API consumption grows with usage and frequently has no budget holder. Premium features reaching unlicensed users create licensing liabilities, and the contract terms covering data use, retention and model training aren't always read as carefully as they should be.
In my experience, this is the layer most often overlooked. Licensing gaps rarely stay hidden. They come to light at a renewal or an audit, usually after the commercial leverage has already gone. Metered AI consumption also looks very much like cloud spend did in its early days, and it needs the same FinOps discipline around ownership, forecasting and optimisation that cloud spend eventually required.
The question to ask: do our contracts and AI spend reflect how AI is being used across the business?
How one task crosses the layers
In practice the layers don't fail one at a time; the risk runs across them. Take a fairly routine example of a developer using AI to automate a task involving customer data.
- People and devices: the developer runs a coding agent on their laptop, signed in with a personal account.
- Connectors and agents: to reach the CRM, they install an MCP server from a public repository.
- AI platforms: the agent calls a model API using a key saved in a script, with broad access and no expiry.
- Identity and data: the key and the developer's access let the agent read customer records.
- Contracts and spend: the API usage is billed to a card or a cloud account with no budget holder.
Each step is reasonable on its own, and each team could fairly say its part is under control. Taken together, customer data is flowing through an unvetted connector, on an API key nobody is rotating, billed to a budget nobody owns, and nobody has sight of the whole path.
Why fragmented ownership matters
Looking across the six layers, ownership is spread between end-user computing, IT, application owners, developers, identity teams, data owners, procurement and finance. Each can reasonably say its layer is being managed, and each vendor will say the same about its own product. The gaps between them are where the commercial, operational and technical risk accumulates. An agent's access is an identity question, its connector is a developer's decision, its spend is a finance issue and its data exposure is a compliance one, and no single team has the full view.
That is why AI governance needs to work towards a single view of the whole estate, independent of any platform vendor, starting where people use AI and widening from there. It is also increasingly what boards, auditors, insurers and customers are asking for: evidence of how AI is controlled, mapped against frameworks such as the EU AI Act, NIST AI RMF and ISO/IEC 42001. That evidence is very difficult to produce for an estate that hasn't been mapped.
Six questions to test your estate
- People and devices: do we know what AI is running on our devices, including what hasn't been approved?
- AI platforms: for each platform, who owns it, which tier are we on, and what happens to our data?
- AI inside business apps: which applications have AI switched on, and did anyone decide that?
- Connectors and agents: what can our agents reach, whose credentials are they using, and who approved them?
- Identity and data: if AI could see everything each user can see, would we be comfortable?
- Contracts and spend: do our contracts and AI spend reflect how AI is really being used?
If you can answer all six with confidence, you are ahead of most organisations. If not, the first step is the same for everyone: establish what is actually running.
The rest of this series looks at several of these layers in more detail, and at how to control and manage them.