Who actually needs a self-hosted AI control plane?

Every enterprise rolling out AI agents eventually asks the same question: where does the control plane run? The answer depends on your data, your regulators, and how much of your security boundary you’re willing to hand to a vendor.

Here’s what you’ll learn in this post:

• What an AI control plane does, and why the SaaS vs. self-hosted decision is an architectural one, not a feature comparison
• Why a SaaS control plane is a reasonable choice for many enterprises
• Exactly which organizations should insist on self-hosted, and how Stacklok keeps your agent traffic inside your cluster

What an AI control plane does

Agents don’t act alone. They call models, invoke tools through the Model Context Protocol (MCP), read your data, and take actions on your systems. An AI control plane is the layer that governs all of that: which models and tools an agent can reach, what identity it acts under, what it’s allowed to do, and what gets logged when it does it.

Without one, you get agent sprawl. Every team wires up its own connectors, API keys accumulate in config files, and nobody can answer “what did that agent touch last Tuesday?” The control plane is how you answer that question before an auditor or an incident forces it.

The architectural fork in the road

Control planes come in two shapes.

A SaaS control plane runs in the vendor’s cloud. Your agents’ traffic, credentials, and audit records flow through infrastructure the vendor operates. You get fast onboarding and zero operational lift, and in exchange, your governance layer lives on the other side of someone else’s fence.

A self-hosted control plane runs on infrastructure you operate. The policies, credentials, session state, and audit logs never leave your environment. You take on the operational work, and in exchange, your trust boundary stays exactly where it was before agents showed up.

Neither shape is wrong. They serve different enterprises.

When a SaaS control plane is perfectly good

Plenty of organizations should pick SaaS and move on. You’re a good fit if:

• Your agents work with data you’d already trust to a third-party cloud, such as marketing content, public documentation, or anonymized datasets
• You have no regulatory mandates around data residency or processing location
• You don’t run a platform team, and standing up new infrastructure would delay adoption by months
• Speed of rollout matters more than boundary control, and a vendor’s SOC 2 report satisfies your risk review

For this profile, a SaaS control plane delivers real governance at low cost. Choosing it is a sound engineering decision, not a compromise.

When you need self-hosted and total control

The calculus flips when the data your agents touch is the data your company runs on. You should insist on a self-hosted control plane if any of these describe you:

1. You operate under regulatory or sovereignty requirements. Banks, insurers, healthcare systems, defense contractors, and public sector agencies often can’t route sensitive data through a vendor’s cloud, no matter how good the vendor’s controls are. Some can’t allow external egress at all.
2. Your agents handle crown-jewel data such as customer records, trading logic, patient data, or source code. When agents run in someone else’s cloud, that data commutes to work every day, and every trip is a risk you have to account for.
3. Your auditors need verifiable claims rather than attestations. A vendor’s compliance report describes their controls, but it doesn’t let you inspect them. You can’t audit a black box across someone else’s fence.
4. You’ve already invested in a security boundary. If you run network policies, a service mesh, and a SIEM pipeline, a SaaS control plane asks you to trust a second perimeter you don’t control. A self-hosted one slots into the perimeter you already defend.

If two or more of those apply, renting governance is the wrong trade. The most consequential infrastructure decision you’ll make in the next three years is where your agents run.

How Stacklok keeps you in complete control

Stacklok built its AI control plane for exactly this profile: complex and regulated enterprises that need the highest degree of control. Self-hosted is the architecture, and everything else follows from it.

• The entire platform runs in your cluster, not merely an enforcement point in front of a SaaS backend. Chat history, project files, session state, audit logs, and identity records all persist to Postgres and volumes you operate.
• Credentials never leave your environment. Your users’ OAuth credentials live as Kubernetes Secrets in your cluster, and they never transit or rest on Stacklok’s infrastructure because there is no Stacklok infrastructure in the data path.
• Your existing boundary enforces the rules. Stacklok sits behind your network policies and mesh rules, workloads run default-deny, and the only egress paths are the two gateways you configure for model and tool traffic. Agents live inside the perimeter you already defend.
• The trust claim is checkable. You can verify where everything runs and what can egress with kubectl, with no attestation required.

That last point matters most for regulated teams. When your CISO asks where agent data lives, “in our cluster, and here’s the manifest” is a better answer than a link to a vendor’s trust portal.

Get started

Want to see what a self-hosted AI control plane looks like in your environment? Book a demo or join the conversation and engage directly with our team on Discord.