Notifications
Clear all
Topic starter
18/08/2026 2:22 pm
TL;DR: Enterprise AI control-plane design is an architectural decision about where agent identity, policy, and audit data live, according to Stacklok. For regulated or crown-jewel use cases, the governing boundary may need to stay inside the customer cluster because SaaS control planes shift trust, egress, and evidentiary control outside the enterprise perimeter.
NHIMG editorial — based on content published by Stacklok: Who actually needs a self-hosted AI control plane?
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Tie control-plane placement to data sensitivity Create a decision rule for when the control plane must stay in-cluster.
- Verify the runtime path, not the brochure Confirm where agent state persists, where credentials are stored, and which egress paths exist.
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.
👉 Read Stacklok's analysis of self-hosted AI control planes for regulated enterprises →
Self-hosted AI control planes: when does governance need to stay in-cluster?
Explore further
18/08/2026 3:13 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Self-hosted AI control planes define the governance boundary
