Running it in your own cloud keeps the runtime, policies, and operational control inside your account, so your existing security guardrails apply directly. Letting the vendor manage deployment shifts more operational responsibility outward and may simplify setup, but it can also reduce direct customer control over configuration, oversight, and account-level isolation.
What changes when you self-host an AI agent platform?
Self-hosting keeps the agent runtime, policy enforcement, and deployment boundaries inside your own cloud account. That matters because the platform is then governed by your network segmentation, logging, secrets handling, change control, and approval processes rather than by a provider’s default operating model. The trade-off is higher internal responsibility for patching, scaling, and secure operations.
When the platform runs in your cloud, you usually get more direct control over where data flows, which identities can reach the service, and how tightly the agent is isolated from adjacent systems. That can be the right choice when the agents will touch sensitive data, production systems, or regulated workloads, because you can align the platform with your own guardrails instead of adapting to a vendor-managed tenancy.
In practice, self-hosting only improves control if you actually govern it well. If the deployment is left broadly permissive, or if service credentials and network access are over-scoped, the security benefit of “our cloud” can disappear quickly. The control advantage comes from how you configure and operate the environment, not simply from where the software is installed.
What changes when the vendor manages deployment?
Vendor-managed deployment shifts more of the operational burden outward. The vendor may handle upgrades, availability, scaling, and some baseline hardening, which can reduce time to value and lower the amount of infrastructure your team has to maintain. That is attractive when you want the platform working quickly and do not need deep tenancy-level customization.
The cost of that convenience is less direct customer control over runtime settings, release timing, and the exact shape of isolation. You may still own the business use case and the data approvals, but the vendor increasingly decides how the service is hosted, how changes are rolled out, and which administrative levers are exposed to you. For some teams, that is an acceptable simplification; for others, it is a material governance shift.
This model is usually best when the platform is not tightly coupled to your most sensitive assets, or when you are comfortable relying on the vendor’s controls and attestations. If the platform needs broad operational autonomy, external connectivity, or frequent vendor-side changes, you should treat the vendor relationship as part of your security boundary and validate it accordingly.
How should you choose between control, convenience, and exposure?
The deciding question is not which model is “more secure” in the abstract. It is which party should own the operational risk for the agent runtime, the credentials it uses, and the systems it can reach. If your security model depends on direct policy enforcement, custom segmentation, or strict account-level isolation, self-hosting usually fits better. If you value faster deployment and reduced maintenance more than fine-grained control, vendor-managed deployment may be the practical choice.
For agent platforms, the distinction matters because agents can act, call tools, and interact with data in ways that create real blast-radius differences. A vendor-hosted model can be perfectly reasonable, but you should understand exactly which controls remain yours and which ones are inherited from the provider. That is especially important when the platform can invoke APIs, store tokens, or operate near production systems.
Good decision-making here is less about trust in the brand and more about trust in the operating model. The more autonomy the agent platform has, the more you need clarity on ownership, isolation, auditability, and revocation. If those are vague, the deployment model is already part of the risk.
Risk and Threat Considerations
AI agent platforms concentrate privilege, execution, and connectivity, so deployment model directly affects blast radius. Self-hosting can reduce dependency on a vendor boundary, but it also means your team must prevent overprivileged agents, weak isolation, and misconfigured secrets; vendor-managed hosting can simplify operations but may hide control gaps until a change or compromise exposes them.
Failure mechanism: The common failure mode is misplaced trust in the hosting model, followed by broad agent permissions, weak tenant separation, or insufficient visibility into what the platform can do and which identities it uses.
Impact: A compromised or misused platform can reach production systems, leak tokens or data, or perform destructive actions with the authority you intended to delegate only narrowly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent hosting choice affects runtime privilege and control over agent actions. |
| Recommendation — Enforce least privilege and per-action authorization for the agent runtime. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Deployment model changes how much privilege the platform and its credentials accumulate. |
| Recommendation — Reduce standing access and scope platform credentials to the minimum needed. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The question turns on who can reach and operate the agent platform and its tools. |
| CM-6 — Configuration Settings | Self-hosted versus vendor-managed deployment changes who controls secure configuration. | |
| Recommendation — Restrict platform and service access to the minimum privileges required. Document and enforce secure baseline settings for the chosen deployment model. | ||
| ISO/IEC 27001:2022 | A.5.23 — Information security for use of cloud services | The question compares cloud operating responsibility and control boundaries. |
| Recommendation — Define shared-responsibility controls for the cloud-hosted agent platform. | ||
Practitioner Guidance
What to verify: Confirm who controls the runtime, who can change policies, where secrets live, and whether the provider can access your data or deployment metadata. If you cannot clearly answer those questions, the deployment boundary is not well understood enough for risk acceptance.
Decision rule: If the agent platform must touch sensitive workloads, require explicit isolation, least-privilege access, and auditable change control before approving vendor-managed operation. If those requirements cannot be enforced contractually and technically, keep the deployment in your own cloud.
What good looks like: You can explain the ownership split for patching, logging, incident response, credential rotation, and emergency disablement in one paragraph, and you can revoke the platform’s access without waiting for a vendor support cycle.
Practitioner takeaway: The right model is the one that preserves the level of control your risk posture actually needs, not the one that feels simplest to launch.
Related resources from NHI Mgmt Group
- What is the difference between letting an agent inherit a user's permissions and running it on its own service account?
- How should security teams evaluate running AI agent platforms inside their own cloud environment instead of a separate hosted deployment?
- What is the difference between an AI agent platform and an AI agent framework?
- What is the difference between a managed AI service and a control plane over your own cloud?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
