The AI works. Just nobody can prove it was allowed to.

InfoQ has published its Cloud and DevOps Trends Report for 2026 [1], with the usual adoption curve: Innovators on the left, Late Majority on the right, and a small vertical word in the middle that says CHASM.

At Parakletos, I currently build an enterprise AI control plane for a living. So naturally I read the chart the way a man with a hammer reads a hardware catalogue, looking for nails!

To be fair to the hammer, most of the chart is not nails. Of the fifty-five items, about a dozen truly matter directly to the AI control problem.

Another group supplies the DevOps building blocks. The rest are simply other things happening around cloud engineering, and are doing perfectly well without the likes of me.

I checked quantum cloud computing specifically, and I am happy to report that our product does not require a dilution refrigerator! Phew!

What did catch my eye was not any single item. It's where the chasm falls.

Look where the chasm falls

On the left of InfoQ's chasm, in the Innovators and Early Adopters columns, you find:

  • enterprise AI platforms and gateways,
  • agentic mesh and autonomous orchestration,
  • AI agents for cloud engineering,
  • MCP-based ops tooling, and
  • AI governance automation.

On the right, in the Early and Late Majority columns, you find:

  • platform engineering teams,
  • GitOps,
  • service mesh,
  • SRE,
  • observability,
  • Infrastructure as Code, and
  • self-service platforms.
  • Policy as Code is sitting just to the left, close enough to see across.

Read that way, the chart makes an argument InfoQ probably did not intend. The right of the chart is where the components come from. The left of the chart is where the authority problem arrives. The chasm is the gap between them.

Mind the chasm!

Our industry doesn't lack components. It lacks the governance semantics to join them up.

A "control plane", briefly

Before going further, let's try and define the term:

An enterprise AI control plane is an organisation-controlled layer between people, models, tools and agents. For any AI action it should be able to say:

  • Who initiated it,
  • What action was attempted and which resources or data classifications were involved,
  • Which policy version decided it,
  • Which model or tool was permitted, and
  • What actually happened.

That record is written by the organisation at the point of decision, not reconstructed afterwards from a supplier's logs.

Note that this is about governing authority, not building an archive of everyone's prompts.

Short version: AI access is being solved. AI authority is not.

Left of the chasm: where authority is arriving

The AI capability trends on the left share a direction of travel: they hand systems progressively more of the organisation's authority:

  • Chat generated text.
  • Model APIs processed enterprise data.
  • Retrieval gave models access to internal knowledge.
  • MCP gives them access to internal systems.
  • Agents give them the ability to act on those systems, continuously, with delegated credentials.

OWASP already lists "excessive agency" among the top risks for LLM applications [2].

AI gateways are a nice place to start, and rightly so. They centralise provider access, keys, routing, retries and quotas. But routing traffic isn't the same as governing authority. A gateway can tell you a request went to a model and used a certain number of tokens. It usually cannot tell you who the real human or workload was, what data class applied, which policy permitted it, or what happened when the agent then called a tool on an internal system. The gateway is a component. The control plane is the boundary around it.

MCP-based ops tooling is where this gets real. The Model Context Protocol [3] has made it remarkably easy to connect a model to repositories, ticketing systems and internal services. Think of your Jira and Git repos for example. That is the point of it, yet also the problem.

AI agents for cloud engineering turn that into delegated authority. An agent that can read your Terraform is a convenience. An agent that can apply it is a decision someone should be able to account for afterwards.

Agentic mesh multiplies it. An agent run may last hours, call dozens of tools, start sub-agents and stop halfway. Nobody sensible should start there, but the chart suggests plenty of people will arrive there anyway.

AI governance automation is the column's tacit admission that policy documents and steering committees don't scale to any of the above. A committee can decide what should happen. It cannot be in the path when it does.

Two other items on the left are less about capability and more about the questions that follow it:

Sovereign cloud strategies become very concrete the first time someone asks whether confidential source code reached a provider region outside the UK or EU during a particular three-week window [4].

FinOps for AI becomes concrete the first time finance asks which team spent what, and the only answer is a shared API key. Both are answerable at the point of decision. Both are miserable to reconstruct.

Right of the chasm: what already exists to govern it

The encouraging part is that nearly everything needed to answer those questions already exists, and most of it is now boringly mature.

Platform engineering teams are the natural owners of a governed AI path.

Policy as Code, using systems such as Open Policy Agent [5] or Cedar-based authorisation [6], already decides deterministic questions in application authorisation.

GitOps already gives you versioned configuration, review workflows and history, and can enforce signing where required.

Egress controls, whether Cilium network policies [7] or a service-mesh egress gateway such as Istio [8], can already make sure model providers and public MCP endpoints are reachable only from an approved path.

Identity providers such as Entra ID or Okta, and workload identity via SPIFFE [9] or your cloud provider, already know who and what is calling.

Infrastructure as Code already lets you declare routes, aliases and server registrations as reviewed state. Having co-written a book on Puppet [10], I have pretty firm views here: "The rest is just YAML" you will recall.

Observability and SRE already give you traces, logs and availability objectives.

And self-service platforms already know how to give teams a paved path instead of a ticket queue.

None of this is new. Which is rather the point.

What is missing is the bit in the middle

If the components exist, why does the problem persist? Because nobody has joined them up.

In a typical estate, identity lives in the IdP, routing in the gateway, authorisation in the policy engine, telemetry in the SIEM, and tool access in whatever MCP servers people happened to run on their laptops. Each logs its own system. None records the decision that connected them.

The problem is not missing telemetry; it's missing causality. Plenty is being logged; just nothing joins identity, authority, decision and execution into a single record.

So when a security review, an incident or a data subject request arrives three months later, the organisation reconstructs the event from provider dashboards, gateway logs, GitHub logs, SIEM events and people's memories [4]. The answer is usually given with a polite qualification about confidence.

The SIEM recorded the activity. It did not participate in the decision that allowed it.

A control plane does not replace any of those components. It holds consistent semantics across them, so that "confidential", "this agent", "permitted model" and "policy v14" mean the same thing on every route, and the decision is written down once, at the moment it is made.

MCP, one action at a time

MCP is the clearest example of why all this matters.

MCP is the plumbing that lets an AI assistant use other systems: read some code, search the ticket queue, open a document. Each of those is a separate action, or “tool call”.

The catch is that permission is usually granted once, at the start of a session, and everything after that rides on the same approval. It is rather like signing a visitor in at reception and then letting them wander the building unaccompanied. An AI assistant approved to read some code is still one tool call away from submitting a change to the payments system.

A control plane fixes this by checking every individual action, not just the session. Before each tool call goes through, it asks four questions.

  • Who is this on behalf of?
  • Which tool?
  • What exactly is it trying to touch?
  • How sensitive is that?

It then allows the action, blocks it, or allows it with conditions, and writes down what it decided either way. The AI is only ever handed the access it needs for that one action.

Two details matter more than they look:

  1. The specifics count, not just the name of the tool. “Read a file” is harmless in the staff handbook, yet rather less so in the payroll folder!
  2. Tools describe themselves, and those descriptions can change. A tool that quietly gains new abilities should be checked again before anyone relies on it, especially if it can change things rather than just read them.

For agents, which can work on their own for hours, the same idea becomes a set of limits agreed up front:

  • Who the agent is working for,
  • What it may do,
  • How much it may spend, and
  • When its permission runs out.

Any helper agents it starts get less authority, never more. Permission is checked again at every step, so if you withdraw it halfway through, it actually stops.

And when something goes wrong, the record should be honest about it. Every action ends as one of four things: done, failed, refused, or “nobody is sure”. That last one (say, a request that timed out before anything confirmed it) is the one most systems never record, and the one your incident review will care about most.

The adoption constraint

Here is where control planes usually fail, and it is not technical.

If the governed path is harder to adopt than a personal API key, it will lose, and it will deserve to.

Every check adds friction, and friction is how shadow AI gets its budget. So the governed path has to be the easiest one available: self-service onboarding in hours, SDKs and IDE configuration that point at the governed endpoint by default, broader model and tool access inside the path than outside it, and denials that explain themselves and say how to request access.

A useful test is "time to first governed call": how long a new team takes to make its first request through the approved route. If that is measured in weeks, you have built a toll booth, not a platform.

The same principle applies to bypass. A control plane that can be routed around is just a logging system with opinions. Egress controls, credentials held only by the control plane, provider tenancy restrictions and centrally distributed client configuration each close a route the others leave open. But the most effective bypass control is still a governed path that people would rather use.

The practical test

InfoQ's chart includes DORA metrics [11][12] in the Early Majority. For anyone working across UK and EU financial services, that is now a mildly awkward acronym collision: the other DORA is an EU regulation that can get you fined! [13].

Both share a sensible instinct, though: measure outcomes rather than activity.

For AI governance, the single most useful outcome measure is "time to evidence": the median time from a question being asked about an AI action to an exported, defensible record of what happened. Reconstructed from scattered logs, that can mean days or even weeks. Read from a record written at the point of decision, the target should be minutes or hours [4]. The exact numbers will vary. What matters is that the second number falls sharply once the decision record already exists.

If time to evidence is not falling, the control plane is producing logs, not answers.

Useful companions are governed coverage (the share of AI calls going through the governed path), bypass rate, and the share of tool operations with an explicit, recorded decision. Watch the trends rather than chasing thresholds borrowed from someone else's slide.

Not everyone needs one

In the interests of not being the man with the hammer for the entire article: plenty of organisations don't in fact need a dedicated control plane.

One provider on an enterprise tier, with SSO, sensible retention, no tool access and no regulated data in scope, can be governed perfectly well with lighter controls. A mature organisation with a good IdP, a policy engine and a gateway may only need to extend what it already runs with AI-specific inputs and a shared evidence schema.

The case for a dedicated boundary starts where the left of the chart is heading: several providers, MCP tools with write access, agents acting with delegated credentials, regulated data, and many teams building independently. Which, if InfoQ is right, describes a growing number of real-world estates.

Where to start

Don't kick off an enterprise-wide AI transformation programme. Dear Lord, haven't we all had a belly full of those?

Take one real AI path where the authority is easy to understand. A coding assistant against internal repositories is usually the right one.

Put it under control end to end:

  • one organisation-owned endpoint,
  • one real identity path,
  • one approved model route,
  • one policy decision service,
  • one read-only MCP integration,
  • one deny path, and
  • one evidence record you can export.

Then measure whether time to evidence falls.

Capability has the rather uncomfortable habit of crossing first. The real question is whether governance crosses close enough behind to actually matter.

In case you hadn't already figured out the case for this new innovation, the danger isn't unusable AI; the real danger is useful AI activity that nobody can later demonstrate was authorised.

Disclosure: Parakletos AI builds enterprise AI control planes, so I have a commercial interest in this argument. The full framework, including when not to build one, is in our white paper [4].

References

[1] InfoQ, "Cloud and DevOps InfoQ Trends Report 2026". https://www.infoq.com/articles/cloud-devops-trends-2026

[2] OWASP, "Top 10 for LLM Applications 2025", LLM06: Excessive Agency. https://genai.owasp.org/llm-top-10/

[3] Model Context Protocol, Specification. https://modelcontextprotocol.io/specification

[4] Parakletos AI, "The Governance Gap in Enterprise AI" (white paper). Composite cases and indicative effort ranges, offered as illustration rather than measurement. https://www.parakletos.co.uk/#white-paper

[5] Open Policy Agent. https://www.openpolicyagent.org/

[6] Cedar policy language. https://www.cedarpolicy.com/ ; Amazon Verified Permissions. https://aws.amazon.com/verified-permissions/

[7] Cilium, network policy documentation. https://docs.cilium.io/en/stable/security/policy/

[8] Istio, egress gateways. https://istio.io/latest/docs/tasks/traffic-management/egress/egress-gateway/

[9] SPIFFE: Secure Production Identity Framework for Everyone. https://spiffe.io/

[10] R. Russell-Yates and J. Southgate, Mastering Puppet 5, Packt Publishing, 2018. https://packtpub.com/product/mastering-puppet-5

[11] DORA (DevOps Research and Assessment). https://dora.dev/

[12] N. Forsgren, J. Humble and G. Kim, Accelerate: The Science of Lean Software and DevOps, IT Revolution, 2018. https://itrevolution.com/product/accelerate

[13] Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). https://eur-lex.europa.eu/eli/reg/2022/2554/oj