Self-hosted AI control planes define the governance boundary

At a glance

What this is: This is an analysis of when enterprises need a self-hosted AI control plane and the key finding is that governance boundary, not feature set, should drive the choice.

Why it matters: It matters because IAM and NHI teams must decide whether agent identity, policy enforcement, and logs can safely traverse a vendor-operated boundary or must remain inside the enterprise trust zone.

👉 Read Stacklok's analysis of self-hosted AI control planes for regulated enterprises

Context

An AI control plane is the governance layer that decides which models, tools, identities, and actions an AI agent can use. The central problem is not whether a control plane exists, but where its policy, session state, credentials, and logs are allowed to run when AI agents touch production systems, regulated data, or sensitive workflows.

For identity teams, this is a boundary question as much as an access question. If the control plane sits outside the enterprise perimeter, the organisation is no longer only governing agent permissions, it is also accepting a vendor-operated trust zone for the records that prove what the agent did. That changes how IAM, PAM, and NHI governance are assessed together.

Key questions

Q: How should teams decide whether an AI control plane needs to stay self-hosted?

A: Use the sensitivity of the data, the residency obligations, and the strength of your existing boundary as the deciding factors. If the control plane will carry credentials, session state, and audit logs for regulated or crown-jewel workloads, self-hosting usually preserves more defensible control than a vendor-operated service.

Q: When does a SaaS AI control plane create unacceptable governance risk?

A: It becomes hard to justify when external operation of the plane would move credentials, logs, or session state outside the boundary you are required to defend. That risk is highest in regulated sectors, sovereign environments, and any programme that must provide direct evidence rather than rely on attestations.

Q: What do security teams get wrong about AI control planes?

A: They often treat the control plane as a product choice rather than a trust-boundary decision. The real issue is where identity enforcement, evidence, and secret handling live when agents act on sensitive systems, because that is what determines auditability and containment.

Q: Who should own the decision to self-host agent governance infrastructure?

A: Identity, security architecture, and platform teams should decide it together, because the answer affects IAM policy, network egress, secrets handling, and audit design. If one team owns only the tool and another owns the boundary, accountability will break during review or incident response.

Technical breakdown

What an AI control plane governs in agent traffic

An AI control plane mediates the agent runtime path between models, tools, and enterprise resources. In practice it assigns identity to the agent session, enforces which tools are reachable through MCP, logs actions, and records what data was accessed. Without that layer, agent sprawl emerges quickly: teams create their own connectors, secrets accumulate, and auditability becomes fragmented across projects. The technical issue is not just authorisation, but the coupling of identity, policy, and telemetry at runtime.

Practical implication: treat the control plane as an identity governance layer, not a convenience feature, and map every agent action to a logged enforcement point.

SaaS versus self-hosted control plane architecture

A SaaS control plane places the governance layer in the vendor’s cloud, so traffic, credentials, and audit records traverse an external infrastructure boundary. A self-hosted control plane keeps policy enforcement, session state, and logs inside infrastructure the enterprise operates. The difference is architectural, not cosmetic. One model optimises speed and lower operational lift, while the other preserves direct control over egress, evidence, and trust boundaries. The same control objective is achieved through very different operating assumptions.

Practical implication: decide first whether the enterprise can tolerate external handling of agent telemetry and credentials, then choose the deployment model.

Why MCP and agent identity make boundary placement harder

AI agents often act through MCP tool calls, which means the control plane is governing a chain of identity, tool selection, and downstream action. That chain is only as trustworthy as the place where credentials, session state, and logs are held. If those artefacts leave the enterprise boundary, investigations, residency checks, and regulator-facing evidence all become more dependent on vendor attestations. In regulated environments, that creates a governance gap even when the underlying access controls are technically sound.

Practical implication: align MCP-enabled agent governance with the same residency and evidence standards used for other high-value identity paths.

NHI Mgmt Group analysis

AI control-plane placement is an identity boundary decision before it is a tooling decision. When agents call models, tools, and data sources through MCP, the location of policy enforcement determines who truly controls the runtime trust zone. That makes the control plane part of the identity architecture, not an add-on to application security. Practitioners should judge the deployment model by boundary ownership, not by feature convenience.

Self-hosted control planes matter most where evidentiary control is part of the security requirement. If audit logs, session state, and credentials must remain inspectable inside the enterprise, a vendor-operated plane changes the chain of custody for identity evidence. This is especially relevant for regulated sectors and for workloads carrying crown-jewel data. The practical conclusion is that auditability is not only about logging volume, but about who operates the log path.

Trust assumptions shift when agent governance leaves the cluster. SaaS governance assumes the vendor’s controls are an acceptable extension of the enterprise boundary, which is reasonable for some use cases and unacceptable for others. That assumption becomes fragile when the same plane also carries credential material and decision logs for sensitive agent actions. The field should stop treating control-plane placement as a deployment preference and start treating it as a risk allocation decision.

The named concept here is boundary-resident governance: policy, session state, credentials, and evidence remain in the operator’s environment rather than crossing into a vendor cloud. That concept is useful because it ties agent identity to the place where accountability can actually be enforced. For practitioners, it sharpens the question from "can we use SaaS?" to "which parts of agent governance can we afford to externalise?"

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That gap points directly to the need for better agent governance references such as OWASP Agentic AI Top 10 and a tighter operational model for where identity evidence lives.

What this signals

Boundary-resident governance: the part of agent security that matters most is no longer the policy rule alone, but whether the enforcement point, session state, and evidence remain inside the operator’s trust zone. As AI agents become embedded in regulated workflows, architecture reviews will need to ask where auditability lives before asking which model or tool the agent uses.

With 80% of organisations already reporting AI agents acting beyond intended scope, the governance problem is no longer theoretical, and boundary placement becomes a control decision rather than an implementation preference. That is why practitioners should evaluate the control plane through the lens of NIST AI Risk Management Framework and map identity evidence paths as carefully as data paths.

For practitioners

• Classify the agent governance boundary Map which agent policies, session records, credentials, and audit logs can leave the enterprise environment and which must remain resident. Use that map to determine whether SaaS is acceptable or whether self-hosting is required for the workload.
• Tie control-plane placement to data sensitivity Create a decision rule for when the control plane must stay in-cluster. Trigger it for regulated data, source code, customer records, trading logic, and any workflow where external egress would violate sovereignty or residency expectations.
• Verify the runtime path, not the brochure Confirm where agent state persists, where credentials are stored, and which egress paths exist. The operative test is whether you can inspect those facts directly in your own cluster and network controls.
• Align IAM and platform teams on ownership Assign one team to own the enterprise trust boundary for agent workloads, including the enforcement layer, logging path, and secret storage model. Avoid split ownership that makes the control plane ambiguous during incident review.

Key takeaways

• Where an AI control plane runs determines who owns the trust boundary for agent identity, policy enforcement, and audit evidence.
• Self-hosted governance becomes the stronger option when credentials, logs, or session state must remain inside regulated or sovereign environments.
• Enterprise teams should evaluate AI control planes as identity architecture, not as a feature comparison between deployment models.

Key terms

• AI Trust Control Plane: An AI trust control plane is the enforcement layer that converts governance intent into runtime decisions for identity, data, and model access. It sits between policy and execution, using context such as task, entitlement, and environment to approve, constrain, or revoke access as the system operates.
• Boundary-resident governance: A deployment model in which policy, session state, credentials, and audit evidence remain inside the operator’s environment. It matters when regulated, sovereign, or highly sensitive workflows cannot safely depend on a vendor-operated trust boundary.
• MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.

What's in the full article

Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:

• How the control plane is deployed inside the customer cluster, including where policy, session state, and logs persist.
• The specific network and default-deny assumptions that keep agent traffic inside the enterprise boundary.
• What auditors can verify directly in the runtime environment, rather than relying on vendor attestations.
• The practical setup details for teams deciding between SaaS onboarding speed and self-hosted boundary control.

👉 Stacklok's full post covers the runtime boundary model, cluster-resident state, and the operational trade-offs behind self-hosted control planes.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.