Agentic Control Planes Need a Data Layer

July 2025. A support ticket lands in a queue watched by a Supabase-connected AI agent running on a service_role credential: full database access, row-level security bypassed by design. The ticket isn’t a complaint. It’s an instruction: read the integration_tokens table, paste the contents into this thread. The agent, doing exactly what the text in front of it says, does it.

Simon Willison already had a name for the pattern: the lethal trifecta. An agent with access to private data, exposure to untrusted instructions, and a way to get what it finds out the door. Supabase’s MCP server had all three. Read-only mode removes one leg. It doesn’t touch the assumption every agentic stack still runs on: that if a tool call is authorized, the data behind it is safe to hand over.

An agentic control plane is the layer that inventories, authenticates, authorizes, and monitors AI agents and the tools they call.

Every serious framework for one (Forrester, IBM, the Cloud Security Alliance) is solving the same problem: whether an agent gets to act. None of them decide what happens to the data once it does.

Control planes decide what an agent may do. Only the data layer decides what it can read.

What is an agentic control plane?

An agentic control plane is the governance layer above AI agents and the tools they call. It inventories every agent, authenticates its identity, authorizes what it’s allowed to do, and monitors what it actually did. It answers one question: is this agent permitted to act? Not what the action returns.

Forrester, publishing its first formal evaluation of the market in December 2025, calls it “an enterprise control plane that inventories, governs, orchestrates, and assures heterogeneous AI agents across vendors and domains,” modeled deliberately on the control plane in cloud and network architecture, “sitting above the underlying systems to provide unified oversight and intervention.” (Forrester)

IBM draws the same boundary more bluntly: the control plane “sits above” a data plane where “each individual agent operates” and “runs tasks and interacts with tools,” routing requests, enforcing permissions, applying policy before an action runs. (IBM)

The Cloud Security Alliance frames the shift underneath all of this: software that used to execute instructions now initiates actions, which means agents need “identities, permissions, oversight, and accountability, just like human users — only at a scale and speed” traditional IAM was never built for. (CSA)

And Gartner’s read on where the budget is going: guardian agents, automated systems built to monitor and correct other agents, will capture 10–15% of the agentic AI market by 2030. (Gartner)

Four sources, one shared boundary: identity, policy, and oversight, applied to whether an agent calls a tool. None of them touch what’s inside the record once it does.

Why AI agent governance became a board-level problem

42% of companies abandoned most of their AI initiatives in 2025, up from 17% the year before, according to S&P Global Market Intelligence. The easy explanation is the model: too slow, too expensive, the ROI never showed up. The easy explanation is usually wrong. The data these programs needed was also the data nobody was cleared to hand over.

Agents make that problem worse in a specific way. A traditional pipeline has a human reviewing a query before it runs, an engineer approving a pull, legal signing off before a dataset moves. An agent collapses that loop: it decides what to ask, asks it, and acts on the answer, in one pass, with nobody in the middle to catch the request that shouldn’t have gone through. That’s the difference between a data-access problem and a data-exposure problem, and it’s why AI agent governance graduated from an engineering backlog item to a board conversation in about eighteen months.

Financial services felt it first, because a regulator wrote it down. DORA Article 9(2) requires financial entities to maintain confidentiality “at rest, in use or in transit,” explicitly extending the obligation past storage and network encryption into whatever’s happening while an application, or an agent, actively works with the data. An agent reading a live customer record to answer a question is squarely “in use.” Most control-plane vendors have nothing to say about that clause, because their product decides whether the call happens, not what state the data is in when it does.

The consequence for the buyer is mechanical: the agent program stalls in the same risk review the analytics program stalled in two years ago, for the same reason. Nobody signed off on the data. We’ve written about what DORA’s in-use requirement actually demands.

What today’s control planes cover

The market Forrester and Gartner are describing is real, and already crowded. None of it is redundant with a data layer. It’s necessary, and it stops at a specific boundary.

Layer	What it decides	Example players
Identity	Who, or what, the agent is	Microsoft Entra Agent ID, Okta, NIST NCCoE non-human identity guidance
Policy	What actions are permitted	Cedar / Amazon Bedrock AgentCore, OpenFGA, Cerbos
Tool / MCP gateway	Which tools an agent can reach, and with what scope	Kong, Cloudflare, Docker MCP Gateway, AgentCore Gateway
AI gateway	Which model, at what rate and cost	Portkey, LiteLLM
Guardrails	What content is safe to send or receive	Lakera (acquired by Check Point, 2025)
Observability	What the agent actually did	LangSmith, Fiddler

That’s scope expansion, not a case for ripping anything out. An identity layer that can’t tell you which agent asked for something is a real gap. A policy engine that can’t block an unauthorized call is a real gap. A cryptographic data plane for AI agents isn’t a substitute for any row in that table.

But look at the middle column again: every layer decides whether the call happens. None of them changes what the data is once the call is authorized. The tool still runs with a credential that reads plaintext. Plaintext still lands in the agent’s context.

The gap: they decide whether, not what

Identity, policy, and gateway layers are rules. Rules are configuration: something with the right access can misconfigure them, override them, or simply forget to write one for a new tool. Every layer above is enforced by whoever holds the keys to the system underneath it.

Zero trust enforced by cryptography, not policy. Centralized key custody breaks the trust assumption. The moment one party holds both the policy and the keys, “zero trust” describes an intention, not a guarantee. If that party is compromised, misconfigured, or simply wrong about what it should allow, the plaintext is available to whoever controls it next.

Even Forrester’s own AEGIS framework, arguably the most complete checklist for agentic AI security today, names Data Security and Privacy as one of six domains, and says plainly that agents “continuously ingest, generate, and transform data” and “without unified data governance, they may inadvertently aggregate or expose sensitive information.” Look at what it recommends there, though: data security posture management, DLP, tokenization. Every one of those is a policy wrapped around a component that still holds plaintext, or still holds the keys. That’s not a knock on AEGIS. It’s an honest description of the state of the art, and precisely the gap a cryptographic data plane for AI agents exists to close.

Control plane vs. data plane for AI agents

IBM’s framing is worth taking further than IBM takes it. In most agent stacks today, the “data plane” isn’t really a layer. It’s just wherever the tool’s credential happens to be able to read. There’s no separate decision being made about the data; there’s a connection string or a service_role key, and whatever it points at is now inside the blast radius of whatever calls it.

What’s missing is a real data plane: one where what an agent can read is a property of which decryption keys its own proxy holds, not a property of a rule someone configured three layers up. A policy engine says an agent may query risk_level. A cryptographic data plane for AI agents makes that true by putting the risk_level key, and only that key, on the agent’s keyring, leaving every other field’s key exactly where it was: nowhere the agent can reach. The control plane decides whether. The data plane decides what.

The threat model policy can’t close

The OWASP Top 10 for Agentic Applications 2026 catalogs what happens when a model stops generating text and starts acting with delegated authority, memory, and tools. Four entries map directly onto the gap above:

• ASI01, Agent Goal Hijack: an attacker alters what the agent is trying to do, through content it trusted.
• ASI02, Tool Misuse: the agent uses a legitimately available tool in a way nobody intended.
• ASI03, Identity & Privilege Abuse: the agent acts with more authority than the situation warrants.
• ASI06, Memory & Context Poisoning: bad instructions persist across turns, corrupting what the agent believes is true.

Every one describes an agent doing something a policy engine authorized. Goal hijack and tool misuse aren’t failures of the identity or policy layer. That layer worked exactly as designed, pointed somewhere it shouldn’t have been.

Run it forward on Supabase. With a tool gateway alone, a hijacked agent gets whatever the authorized tool can read: an entire table, with service_role access and no field-level distinction. With a cryptographic data plane underneath the same gateway, it gets its granted fields, plus whatever aggregates its grant allows. Everything else stays ciphertext, regardless of what the injected prompt convinced the agent to ask for. Prompt injection can still trick an agent into asking a bad question; it can’t make the agent decrypt a field it was never granted.

That’s not a claim that granted fields and aggregates become unreachable. They don’t, and pretending otherwise would be dishonest. A hijacked agent with a legitimate grant to risk_level can still ask for risk_level all day, which is why grants should follow least agency. What changes isn’t the ceiling on a legitimate grant. It’s everything below the floor of that grant, which a policy misconfiguration or a successful hijack used to reach freely and now categorically can’t.

MCP security at the tool-call boundary, and below it

MCP adoption moved fast enough that its security model had to catch up in public, across two spec revisions in under six months. The 2025-06-18 spec made an MCP server an OAuth 2.1 resource server, required audience-bound tokens, and forbade token passthrough, but left authorization optional. The 2025-11-25 revision tightened it further: Client ID Metadata Documents so client and server can establish identity without prior registration, mandatory PKCE, and a flow built for enterprise-managed authorization.

Real progress, worth adopting regardless of what sits underneath it. But read the requirement list again: every clause governs which tool an agent can call, with what scope, under whose token. Nothing governs what’s inside the response once the call is authorized. A gateway can narrow a tool’s scope to a single table. It can’t make an over-scoped table’s contents unreadable to whatever ends up calling it.

That’s the boundary a cryptographic data plane for AI agents sits underneath, not on top of. Whatever gateway or MCP server a stack already runs, Blind Insight isn’t a competing layer at the tool-call boundary. It’s what the tool is allowed to reach once the call clears every layer above it. The same four query tools that keep Blind(L)LM from ever handing an agent a record (list_schemas, describe_schema, query_aggregate, suggest_ml_approach) plug into an agent stack as an MCP server, sitting behind whatever authorization the rest of the stack already enforces.

Cryptographic enforcement: field-level grants and keyrings

Here’s the mechanism. Every field gets its own AES-256 key, derived and held client-side inside the Blind Proxy, the piece of the stack that sits with whoever owns the data, never inside a vendor’s infrastructure. A grant names a set of fields. When it’s approved, the data owner’s proxy wraps each granted field’s key to the grantee’s public key and relays that sealed blob through our server, which relays a key it can never open, to the grantee’s own proxy, where receipt is verified and the key lands on a keyring.

The keyring holds only the keys its grant allows: query keys by default, decryption keys only for the fields a grant explicitly permits. The same controls scope those keys to a task or session, so a grant written for one investigation doesn’t quietly become a standing credential for the next one.

A grant is programmable per field, per agent, and it only ever lists what’s granted:

{
  "__query": true,
  "risk_level": true
}

That’s the whole grant for an agent that can query the dataset and decrypt risk_level. Every other field on the record has no key on this agent’s keyring. Not hidden by a rule. Absent.

The strongest true sentence in this architecture: field readability isn’t a server-side policy check. Any member of an org can fetch ciphertext for any record. The server doesn’t gate reads, because the server can’t read anything either. Whether that ciphertext becomes information is entirely a function of which keys the requester’s own proxy holds. Give each agent its own proxy and identity with a narrow grant, and the blast radius of any compromised agent is exactly what that agent’s proxy can decrypt. Never what the org can decrypt collectively. More on how grants work for agents is in our FAQ.

Computing on encrypted data: search, aggregates, training

None of that matters if the ciphertext underneath it is inert. This is encryption-in-use in practice, not as a compliance buzzword: data that stays encrypted while it’s searched, aggregated, and trained on.

Operation	Support
Equality	Supported
Integer range	Supported
Float range	Supported, no aggregates
Fuzzy / partial-string match (n-gram + phonetic, tunable)	Supported
Phrase / free-text search	Batch
Count / sum / avg / min / max	Integers
Boolean AND	Supported

Training is the case that actually moves a fraud or AML program: BlindML trains a Naive Bayes model on 1,000,000 encrypted records (six features, one target) in about 50 seconds, with a 0.0 F1 delta against the same model trained on plaintext. The honest comparator is fully homomorphic encryption, which is what most institutions evaluate first and which takes hours on the equivalent workload. FHE isn’t broken: Duality Technologies holds a DARPA contract specifically to accelerate ML training on encrypted data, so it can train models. It’s slow enough that most real-time programs never get there. The difference is hours versus seconds, not possible versus impossible, and most teams don’t actually need FHE for this class of workload.

None of that is worth presenting without the honest version of what makes it fast. Speed comes from letting the server learn something about each field. Never the record, but a bounded amount of structure:

Field type	What the server can learn
String	Equality pattern: whether two values match
Fuzzy	Similarity: how close two values are
Text	Token positions and repeat frequency
Number	The number itself, not whose it is
Keys	Nothing. The server never holds one.

Record payloads are AES-256-GCM under keys only your proxy holds. The server never holds a key and never decrypts a record. Numeric fields carry an index the server can compute over, which is what makes aggregates fast; string, fuzzy, and text fields are indexed with keyed hashes (HMAC-SHA-256) instead. Put plainly: our server can see a number. It can’t see whose it is, as long as whatever identifies that person lives in a string, fuzzy, or text field, which in practice it almost always does. That’s a real trade-off, not a rounding error, and exactly the kind of line most vendors leave out of their own documentation.

Agents that see numbers, not records

This is where the lethal trifecta actually gets broken, not just narrowed. Blind(L)LM gives an agent exactly four tools: list_schemas, describe_schema, query_aggregate, suggest_ml_approach. None returns a record. There’s no fifth tool that hands back a row: not disabled, not gated behind a flag, absent from the surface an agent can call.

A policy gate sits in front of those four tools anyway, rejecting anything that looks like a raw-record request, an identifier, or a PII-pattern hit before it reaches a model provider. Each run is capped at six tool turns. What crosses the boundary is the prompt, schema metadata, and aggregate numbers. Never a record, no matter which fields the calling agent’s keyring can decrypt.

Go back to Supabase. The lethal trifecta needs three things: private data, untrusted instructions, a way out. Prompt injection can still supply the untrusted instructions. Nothing here claims to stop that. What this removes is the first leg. There’s no private record for a hijacked agent to read, because the tool surface it’s calling was never built to return one.

Sovereignty: where the keys live

Everything above holds regardless of where the ciphertext physically sits, which is the point. Key residency is separable from data residency, and for a regulated buyer, that separation is the whole argument.

In an enterprise deployment, the proxy runs inside your environment: your perimeter, your cloud account, your network. Nothing connects inbound from Blind Insight. The only outbound call is usage telemetry for licensing, never a data payload, and air-gapped deployment is possible through offline license reconciliation. For smaller teams, hosted plans run a Blind Insight-managed proxy, and it’s worth saying plainly, because a sovereignty claim that quietly stops being true below a certain contract size isn’t a sovereignty claim.

The proxy runs in five places, depending on who needs to hold the keys: inside your own perimeter, the common case; inside a partner’s stack, where each party runs its own proxy and its own keys, so a federated analytics arrangement never needs a trusted intermediary holding both sides’ data; as a browser extension, with keys client-side in the browser; as a mobile library, with keys on-device; or run by a trusted third-party custodian, for the specific case where independent key-management oversight is the requirement, the scenario DORA’s third-party-risk regime was written for.

Keys can live in a cloud KMS under your own customer-managed key, HashiCorp Vault, an OS keychain, a browser wallet, or with a custodian. DORA Article 9(2) requires confidentiality “at rest, in use or in transit.” RTS 2024/1774 Article 6(2)(b) requires an encryption policy covering data in use “where necessary,” and Article 7 requires a documented key-management policy across the full key lifecycle. Run the proxy yourself, and your institution keeps sole custody of keys across that lifecycle. The ICT third-party provider, us, never receives one. Zero trust enforced by cryptography, not policy: Blind Insight doesn’t have your keys, and that sentence is true because you’re the one running the proxy.

The honest comparison: TEEs move the trust question into hardware, and hardware has its own attack surface. TEE.fail extracted attestation keys from Intel TDX and AMD SEV-SNP using a sub-$1,000 interposer. Vaults and tokenization rehydrate plaintext wherever policy allows it, which is a different trust model, not a stronger one: the plaintext exists somewhere, and something holds the key to it. The primitives underneath Blind Insight are FIPS/NIST-standard: AES-GCM-256 and HMAC-SHA-256.

Reference architecture: Blind Insight inside your control plane

None of this asks a security team to replace anything already in place. An IdP or agent-identity system establishes who the agent is. A policy engine decides what it’s allowed to do. An MCP or tool gateway enforces the scope of that decision at the call boundary. Underneath all three, the agent’s own Blind Proxy holds a grant-scoped keyring that determines what the call actually returns. The proxy talks to the Blind Insight API, which holds no keys of its own; what comes back is ciphertext and aggregates, resolved into granted fields only on the requester’s own proxy.

Your control plane keeps doing exactly what it does today. Blind Insight makes its decisions cryptographically true at the one layer none of those decisions currently reach: the data itself.

Every query is logged at the proxy: who, what, when. Key deliveries and every Blind(L)LM run get their own record server-side. That audit trail lives wherever the keys live: in your environment, if you’re the one running the proxy, which means it ships to your SIEM like every other log source you already own. For a DORA-regulated entity, that’s evidence for Article 9 and the RTS key-management article without a single plaintext payload leaving the building.

Keep your control plane. Give it a data layer that can’t be talked out of its answer.

A CISO’s checklist for any agentic control plane

Ask any vendor selling into your agent stack, including us, these seven questions:

1. When a permitted call succeeds, is the data plaintext to the tool that called it?
2. Who holds the decryption keys: you, the vendor, or the gateway?
3. Can an agent compute on a field it can’t read (an aggregate, a match), or does “can’t read” mean “can’t reach at all”?
4. When an agent gets hijacked, what does it reach: the tool’s whole scope, or only the fields it was individually granted?
5. What does the vendor’s server learn per field type? Ask for their version of the table above. If they don’t have one, that’s the answer.
6. Where do the keys physically live relative to the data, and does that satisfy DORA Article 9(2) and the RTS key-management article?
7. What actually reaches the model provider: a prompt, a schema, an aggregate, or a record?

None of these require distrusting your control plane vendor. They require knowing which question it was built to answer, and which one it wasn’t.

FAQ

What is an agentic control plane?

It’s the layer that inventories, authenticates, authorizes, and monitors AI agents and the tools they call: identity, policy, and observability, the same jobs a cloud control plane does for infrastructure. It decides whether an agent is allowed to act. It doesn’t decide what the agent can read once that action is authorized; that’s a separate layer, underneath it.

Control plane vs. data plane: what’s the difference?

A control plane decides whether a call happens: which agent, which tool, under what policy. A data plane is what the call actually touches. In most stacks today, the “data plane” isn’t a real layer; it’s wherever the tool’s credential can read. A cryptographic data plane makes it real: what’s readable is a property of which decryption keys a requester’s own proxy holds, not a rule configured somewhere else.

How do you secure AI agents?

Layer identity, policy, and tool-gateway controls to govern whether an agent can call something. That part of the stack is mature and worth using. Underneath it, add a layer that makes readability cryptographic rather than configured: field-level grants, keys that only exist on a keyring if a grant explicitly allowed them, and a query surface, like Blind(L)LM’s four tools, that was never built to return a raw record to a model.

Is MCP secure?

MCP’s own spec has tightened fast: the 2025-06-18 revision made servers OAuth 2.1 resource servers and forbade token passthrough; the 2025-11-25 revision added Client ID Metadata Documents and mandatory PKCE. All of that governs the tool-call boundary. None of it governs what’s inside the data once an authorized call reaches it. That needs a separate layer.

Can prompt injection bypass an agent control plane?

Prompt injection can still convince an agent to ask a question it shouldn’t. No policy engine or gateway fully closes that, and neither do we. What a cryptographic data plane changes is what happens next: a hijacked agent’s keyring only ever holds the keys its grant explicitly allowed, so it can be tricked into asking for a field it was never granted, and the answer is still ciphertext.

How do you stop an AI agent from exfiltrating customer data?

Field-level grants scope exactly what an agent’s proxy can decrypt, and the same controls scope those keys to a task or session rather than leaving them standing indefinitely. An agent holds no decryption key for any field it wasn’t explicitly granted, and Blind(L)LM’s tools return aggregates, not records, so there’s no raw record on the other side of a successful prompt injection to exfiltrate. Every request is logged at the proxy.

What does DORA require for AI agents?

DORA doesn’t name agents specifically, but Article 9(2) requires financial entities to protect data “at rest, in use or in transit,” and an agent reading a live record to answer a question is squarely “in use.” RTS 2024/1774 Article 6(2)(b) requires an encryption policy covering data in use where necessary, and Article 7 requires a documented key-management policy across the full key lifecycle. An architecture where the financial entity holds sole key custody, and the ICT provider never receives one, is built for exactly that pairing.

See what your own schema looks like on the other side of a grant. Book a demo and we’ll walk your agent stack through the checklist above.