In the past twelve months, 76% of organisations had to stop, restrict, or roll back something an AI system did, according to Aikido's 2026 State of AI in Pentesting report. Most of those companies already had an AI policy.

That gap, between what a policy says and what an AI actually does, is the core problem in AI security today. A policy is a PDF. It states intent. It cannot tell you which AI client touched which system, which credential it used, or whether anyone approved the action. It cannot stop a risky tool call before it runs.

AI security climbs through four levels: no controls, policy, traceability, and gatekeeping. The destination is a system of record for AI activity, with gates strong enough to stop the wrong action before it becomes an incident.

The four levels of AI security

Level 0: No controls

Work gets done. Nobody can reconstruct it. AI use exists, but it is informal. ChatGPT in sales, Claude in marketing, Copilot in engineering, Cursor on developer laptops, a few custom agents wired to internal tools. No shared inventory, no common policy, no reliable trail. Security hears about it late, if at all. This is shadow AI, and it is not your employees' fault.

This is the highest-risk level, and the most common. It rarely looks chaotic from the inside: work gets done, teams move faster. The problem only surfaces when a customer asks about AI use, a regulator asks for evidence, or an incident needs reconstruction. The question no one can answer: who used which AI, for what, with which data, last quarter?

Level 1: Policy

The map exists. It is not the road. The company writes down approved tools, data tiers, prohibited uses, and who signs off on high-risk use. This is the first serious level, and it matters. It gives employees clarity, managers a consistent line, and compliance a document to maintain.

But policies do not enforce themselves. A policy is the map. It is not the road, the speed limit sign, the camera, or the barrier. It should exist and be short enough that people actually read it. If you do not have one yet, our free generator drafts a one-page, seven-clause policy in five minutes. Once it is written, the next question arrives fast: can you prove it was followed?

Level 2: Traceability

A system of record for AI activity. Not "who has access to ChatGPT Enterprise", but which agent called which tool, what it requested, which policy applied, whether it was approved, and what came back.

Traceability is not a switch you flip once. It is graded, and this is where most companies quietly overestimate themselves. Most AI tools ship out-of-the-box logs: ChatGPT Enterprise has a compliance log, Copilot writes to Purview, Claude has team logs. So if you have a policy and you lean on those native logs, you are at the start of level 2, not the finish. You have fragments, not a record.

The gap runs on two axes: breadth (one vendor at a time, versus one record across all of them) and depth (conversation-level, versus action-level: which tool, which credential, approved or not).

That record has to be consistent across vendors. If Claude has one log, ChatGPT another, Cursor a third, and local MCP servers none, you do not have traceability. You have fragments. Fragments help in a demo and fail in an audit. A mature level 2 is one cross-vendor record with the same fields for every client. That is where governance becomes defensible: security can investigate, compliance can export evidence, engineering can debug, procurement can answer customer questions. But it is still reactive. It tells you what happened, which is necessary and not enough.

Level 3: Gatekeeping

Stop the wrong action before it runs. The next level is enforcement in the path of the AI action, not just written and logged policy.

The policy decision happens before the action, not after the audit. Enforcement can reach back to the policy itself: no signature, no connector. This is the level that turns AI security from documentation into control.

What Aikido's data shows

Aikido surveyed 400 security and engineering leaders at cloud-native organisations. The report is about pentesting, but the signal travels straight to AI governance:

That last number is the one to sit with. When something goes wrong, "we have an AI policy" is weaker than "here is the record of every AI tool call, approval, denial, credential, and policy decision." The PDF says intent. The record shows behaviour.

Why the record has to sit across AI clients

Most companies will not standardise on one AI client. Engineering reaches for Cursor, Claude Code, Copilot, or Gemini CLI. Sales lives in ChatGPT. Marketing uses Claude. That diversity is how the market is moving, not a bug to fix.

The governance mistake is solving it one vendor at a time. Per-vendor policies, approvals, logs and credentials give security a dashboard problem instead of a governance program. It also caps you at early level 2 by design: five native logs are still five fragments. The same action should carry the same policy wherever it starts. Deleting a Notion page should require approval whether the request comes from Claude, ChatGPT, Cursor, or Copilot. Calling a customer system should leave one audit trail, not five.

MCP, the emerging standard for connecting AI clients to tools, makes this urgent. An MCP server is not a passive document store: it can read files, query databases, update pages, and call APIs. Once AI clients can call MCP tools, the security question shifts from "which model did we approve?" to "which tools can this AI reach, under which policy, using which credential, with which audit trail?" The model is one part. The tool layer is where business impact happens. More on that in MCP governance: what it is and how to do it right.

Where airlock fits

airlock exists for the top of the climb: the back half of level 2 and all of level 3. It gives teams one connector across Claude, ChatGPT, Cursor, Copilot, Gemini, and Claude Code. The goal is not to force everyone onto one AI tool. It is to make governance consistent across the tools they already use.

With airlock, the scattered native logs become one cross-vendor record. Policy sits server-side, credentials stay in the vault, and tool calls are logged with the same fields everywhere. Human approval can gate sensitive actions. Teams can set rate limits, use a kill switch, redact secrets and personal data, and export audit trails when procurement, security, or regulators ask. One tool. Many clients. One record.

You can start without us: write the policy first, and you can reach the start of level 2 on your vendors' native logs. But consolidating those fragments into one record, and enforcing policy before the action, is the gap airlock closes.

The takeaway

The first wave of AI security was policy. Necessary, and static. The second is traceability, a system of record for AI activity, and most companies are only at the start of it. The third is proactive gatekeeping: controls that sit in the path of the action and enforce policy before the damage is done.

Fast-moving teams do not want security theatre. They want evidence they can defend and controls that keep pace with the software. The future of AI security is more than another PDF. It is a system of record for AI activity, with gates strong enough to stop the wrong action before it becomes an incident.

References

Aikido, State of AI in Pentesting. airlock, Shadow AI is not your employees' fault. airlock, MCP governance: what it is and how to do it right.