The Permission Plane Model: Data Plane vs Control Plane Permissions

Ashish KunalFounder — Pyroniq·
The Permission Plane Model separates application permissions into two classes. Data plane permissions grant access to your company's actual content — Mail.Read reads every email in a mailbox, Files.ReadWrite reads and deletes documents, Calendars.Read exposes your full meeting history. Control plane permissions grant only visibility into structure — Application.Read.All shows which apps exist, DelegatedPermissionGrant.Read shows who authorised what. A governance platform should operate entirely in the control plane. A tool requiring data plane permissions to do a governance job is not a governance tool; it is a data access tool with governance marketing.

The question that prompted this

Someone asked me a sharp question: "If AI tool permissions are the problem, doesn't a governance tool need permissions too? Aren't you doing the same thing?"

It is a fair question, and it deserves a precise answer — because the distinction at its heart is one of the most important and most overlooked concepts in enterprise AI security.

Borrowed from network architecture

In network engineering, the data plane carries actual traffic — packets moving between systems. The control plane handles routing decisions — the map determining where traffic should go. Same infrastructure, fundamentally different functions. Compromising the data plane exposes your traffic; compromising the control plane corrupts your routing logic. The risks differ in kind, not merely in degree.

The same distinction applies to enterprise application permissions.

Data plane permissions carry your content

When an employee connects a writing assistant, a meeting transcription tool, or a document AI to their work account, this is typically what the tool requests:

PermissionWhat it actually grants
Mail.ReadEvery email in that mailbox — sent, received, attachments, full thread history, contact metadata. Not just new mail. Everything.
Files.ReadWriteRead, create, modify, and delete documents across cloud storage and shared drives — including shared project folders and team repositories.
Calendars.ReadThe full meeting history — who attended, how often, and titles that routinely contain project names, client names, and deal stages.

These scopes are written in developer shorthand. A non-technical employee looking at a consent popup is not reading permission scopes — they are reading the top-line description the vendor chose to display. They click Allow, and the application gets exactly what it asked for.

Control plane permissions carry only the map

Control plane permissions grant visibility into the structure of your environment — which applications exist, which grants are active, which users are in your directory. They give no access to the content those applications or users can reach.

PermissionWhat it actually grants
Application.Read.AllWhich applications are registered. Not what they contain — what they are.
DelegatedPermissionGrant.ReadWhich grants exist: which app was authorised by which user, with which scopes. The permission map — not the mail, files, or calendar entries that map describes.
Directory.Read.AllUser and organisational structure.

Why this shaped our architecture

This is the plane a governance platform should operate in. Full stop. The distinction drove every architectural decision we made: zero data plane permissions, control plane only. Understanding who granted what to whom is entirely sufficient to govern an AI tool landscape without ever touching the underlying data.

The next time a vendor pitches you an AI governance or CASB solution, ask one question: are you operating in the data plane or the control plane? Their answer tells you more than their entire sales deck. Which plane are the tools in your environment operating in right now?

Governance without touching your data.

Pyroniq operates on control plane permissions only — it reads the permission map, never your mail, files, or calendar.

Run Free Scan →

This article is for awareness only and does not constitute legal advice. DPDPA obligations depend on your organisation's specific circumstances — confirm them with qualified counsel.