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.
Why This Matters for Security Teams
The control plane is not just an admin console for AI. It is the place where credentials, policy decisions, session state, and audit evidence converge. If that plane is vendor-operated, the trust boundary expands beyond the organisation’s direct control, which matters most when the workload touches regulated data, customer secrets, or crown-jewel systems. NIST’s Cybersecurity Framework 2.0 treats governance, protection, and third-party risk as linked concerns, not separate ones.
NHI Management Group’s research on Ultimate Guide to NHIs also shows why this question keeps resurfacing: fragmentation is common, and organisations often end up with multiple secrets managers and inconsistent control patterns across environments. That fragmentation makes it harder to prove who can issue, revoke, and observe access at any point in time. In practice, many security teams discover the control plane problem only after an AI workflow has already crossed a boundary they assumed was still internal.
How It Works in Practice
The decision usually comes down to whether the control plane itself must be trusted with the same assets the AI agent can reach. If the plane handles ephemeral tokens, workload identity, policy decisions, and audit logs for sensitive systems, self-hosting gives teams a cleaner path to enforce boundary controls, residency requirements, and separation of duties. That is especially important for agentic workloads, where access is not static. The agent may chain tools, request new scopes, or call downstream systems in ways that are hard to pre-model.
A practical self-hosted design usually combines three elements:
- Workload identity for the agent, such as SPIFFE/SPIRE or OIDC-based proof of workload identity.
- Just-in-time, short-lived credentials that are issued per task and revoked automatically when the task ends.
- Runtime policy evaluation, often using policy-as-code, so decisions are made against current context instead of a fixed RBAC table.
This matters because static access rules assume predictable behaviour, while autonomous systems are goal-driven and can change paths mid-execution. The emerging view in DeepSeek breach and JetBrains GitHub plugin token exposure coverage is that once secrets or tokens are exposed in tooling ecosystems, the attacker’s window is often measured in minutes, not days. That is why many teams prefer to keep the control plane close to the workloads it governs, with local logging, local key custody, and clear revocation paths. These controls tend to break down when the control plane must span multiple sovereign regions with conflicting residency rules because policy evaluation, logging, and incident response become operationally inconsistent.
Common Variations and Edge Cases
Tighter control-plane isolation often increases operational overhead, so organisations have to balance stronger custody against slower delivery, more maintenance, and a larger platform burden. There is no universal standard for this yet, especially for hybrid and multi-cloud estates where some AI services can be externalised safely and others cannot.
A useful rule is to keep the plane self-hosted when any of the following are true: it stores long-lived secrets, it mediates access to regulated records, it must preserve sovereign residency, or the AI agent can influence production systems. If the plane is limited to low-risk orchestration with no sensitive state, a managed service may be acceptable, provided the workload identity layer, token lifecycle, and audit export remain under organisational control. Current guidance suggests that the more autonomous the agent becomes, the less defensible a vendor-operated control plane is unless the vendor can prove equivalent custody and isolation. For practitioners, that means reviewing not just where the model runs, but where policy is enforced, where credentials are minted, and where evidence is retained.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Control planes that issue or store secrets must minimize standing exposure. |
| OWASP Agentic AI Top 10 | A-03 | Agentic control planes need runtime authorization for dynamic tool use. |
| CSA MAESTRO | M1 | MAESTRO addresses governance and trust boundaries for agentic AI systems. |
| NIST AI RMF | AI RMF governance helps decide custody, accountability, and risk ownership. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central to deciding what the control plane may reach. |
Assign clear accountability for AI control-plane risk and review it as the system changes.
Related resources from NHI Mgmt Group
- How should teams decide whether an AI control plane needs to be Kubernetes-native?
- How do IAM teams decide whether an AI use case needs new controls or better NHI hygiene?
- How do teams decide whether an AI agent needs human approval?
- How do security teams decide whether an AI agent needs PAM-style controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
