Bring your own cloud changes enterprise AI deployment controls

At a glance

What this is: This is a conference recap on Bring Your Own Cloud deployment models, showing that customer-hosted software is shifting from niche architecture to enterprise requirement.

Why it matters: It matters because BYOC changes who controls runtime access, update paths, and support visibility, which affects NHI, autonomous, and human governance models across regulated environments.

By the numbers:

• The same survey found that only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read WorkOS's recap of Nuon's BYOC demo for enterprise AI deployment

Context

Bring Your Own Cloud changes the default trust model for enterprise software. Instead of the vendor operating everything in a shared environment, the customer runs the application in its own cloud account, which shifts control over data residency, access, and outage exposure. For identity teams, that means the question is not just where the software runs, but who can change it, inspect it, and recover it.

This model is gaining traction because regulated industries want tighter control over runtime conditions and stronger boundaries around vendor access. In practice, BYOC turns deployment into an identity and governance problem as much as an infrastructure one, since support, remediation, and update workflows now cross customer-owned cloud estates and must be authorized explicitly.

The shift is especially relevant for teams already managing NHI sprawl, cloud workload identities, and delegated admin access. Once a vendor needs operational visibility into customer-owned environments, the control design has to account for scoped access, auditability, and change approval without assuming persistent vendor privilege.

Key questions

Q: How should security teams govern vendor access in Bring Your Own Cloud deployments?

A: Treat vendor access as delegated privilege that must be scoped, logged, and revocable. Separate read-only observability from remediation authority, require customer approval for production changes, and tie every access path to a named support case or change record. The control objective is to preserve operability without creating permanent cross-account reach.

Q: What breaks when a BYOC model still relies on standing vendor access?

A: Standing access collapses the trust boundary BYOC is supposed to create. If the vendor can reach customer cloud resources continuously, the model turns into remote administration with weaker accountability, higher blast radius, and more difficulty proving who changed what. That undermines the security and residency case for customer-hosted deployment.

Q: When should organisations choose approval workflows for customer-hosted changes?

A: Use approval workflows whenever a vendor-initiated action can affect production configuration, data pathing, or recovery operations in a customer-owned environment. The more regulated the workload, the more important it becomes to separate change intent from change execution, because the customer needs evidence that the action was authorized before it landed.

Q: What is the difference between BYOC and ordinary cloud support access?

A: Ordinary support access usually assumes the vendor operates inside its own environment or a shared service boundary. BYOC puts the runtime in the customer’s account, so support access becomes delegated administration across someone else’s cloud. That changes the governance model from simple troubleshooting to controlled cross-boundary privilege.

Technical breakdown

Bring your own cloud architecture and control boundaries

Bring Your Own Cloud, or BYOC, places the software runtime inside the customer’s cloud account while the vendor retains some operational tooling for deployment and support. Architecturally, that creates a split control plane. The customer owns the environment, but the vendor still needs a way to observe drift, push updates, and troubleshoot without broad standing access. The hard part is not packaging software. It is preserving tenant-specific isolation, supportability, and change integrity while neither side fully controls the whole stack.

Practical implication: define exactly which identities can touch customer environments and make those boundaries explicit in cloud and IAM policy.

Drift detection in customer-hosted deployments

Drift detection compares the intended application state with what is actually running in the customer’s environment. In BYOC, drift matters because customers can change configuration, but vendors still need to know when those changes break supportability or create security exposure. A clean drift signal is more than a Kubernetes concern. It becomes an access and governance signal, because it tells you whether changes were authorized, who made them, and whether the vendor still has the right to remediate.

Practical implication: tie configuration drift alerts to change approval records and identity logs before remediation is allowed.

Approval workflows for vendor-managed updates

Approval workflows are the governance layer that keeps vendor-initiated changes from becoming silent privilege use. In customer-hosted software, they let the customer review updates before they land in the environment, which reduces the chance that a vendor support action becomes an uncontrolled modification. This is especially important when the support path spans cloud accounts, Kubernetes resources, and delegated credentials. Without approvals, BYOC can drift into opaque remote administration instead of accountable shared operations.

Practical implication: require approval gates for all vendor-initiated production changes that affect customer-owned cloud resources.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• McKinsey AI platform breach — McKinsey AI platform hack exposed 46M chats and sensitive data.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

BYOC turns SaaS support into an identity governance problem, not just a deployment pattern. When software runs inside a customer’s cloud, the vendor no longer has the broad operating assumptions that multi-tenant SaaS relied on. Access has to be scoped, time-bound, and auditable across customer-owned environments. That means cloud permissions, support access, and change workflows now behave like non-human identities that must be governed explicitly. Practitioners should treat BYOC as a control-boundary redesign, not a packaging choice.

Customer-hosted deployment exposes the runtime gap between ownership and operability. The customer owns the cloud account, but the vendor still needs enough access to diagnose, update, and recover the application. That tension creates a governance layer where legitimate support can become standing privilege if the workflow is not disciplined. The field should stop assuming that support access is inherently safe just because it is granted for operations. Practitioners need to distinguish emergency access from persistent operational reach.

Approval workflows are now part of the security model for enterprise software delivery. In BYOC, a deployment is not complete when code is packaged. It is complete when the customer has accepted the change path and the vendor’s operational path is constrained. This is a named control pattern worth calling out: delegated change authority: the vendor can propose or remediate changes, but the customer controls when those changes are authorized. Practitioners should design for that split authority explicitly.

BYOC validates the move from infrastructure trust to identity trust. The old SaaS assumption was that the vendor’s environment could be trusted as the primary control plane. Customer-hosted software breaks that premise and makes identity the only durable governance layer across clouds, regions, and regulated workloads. That applies to human operators, service identities, and automation alike. Practitioners should re-evaluate every workflow that still assumes one party can safely act on behalf of the other without visible authorization.

This deployment model signals that enterprise software is becoming more conditional, more regional, and less centrally controlled. Data residency and business continuity requirements are pushing vendors toward designs that work inside customer-owned boundaries. That does not remove identity risk. It relocates it into support, orchestration, and change management paths that must be governed with the same discipline as privileged access. Practitioners should expect BYOC to increase scrutiny on delegated access and remediation rights.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• For a deeper governance lens, see Top 10 NHI Issues for the access and lifecycle problems that reappear when control boundaries move into customer environments.

What this signals

Delegated change authority: BYOC deployments will push more teams to treat vendor remediation as a governed privilege, not a support convenience. As customer-hosted software becomes more common in regulated sectors, organisations will need to decide which actions can be observed, which can be proposed, and which can be executed only after customer approval.

With 70% of organisations already granting AI systems more access than human employees performing the exact same job, the broader trend is clear: access models are drifting faster than governance models can adapt. BYOC is another place where that drift shows up, because runtime control, support access, and approval logic all cross identity boundaries.

Teams that already struggle with cloud workload identities should expect BYOC to expose the same weak points in a new form. The practical question is whether access reviews, offboarding, and audit logging can keep up when a vendor operates inside the customer’s cloud rather than outside it.

For practitioners

• Map every vendor support identity Inventory the human and non-human identities that can reach customer-hosted environments, then classify which ones are read-only, change-capable, or remediation-capable.
• Require approval for runtime changes Block deployment and remediation actions unless a customer-approved change record exists for the specific cloud account, cluster, or workload being modified.
• Separate drift detection from remediation rights Allow monitoring to observe configuration drift, but require a distinct entitlement and approval path before any corrective action is executed in a customer environment.
• Review vendor access for standing privilege Replace persistent cross-account access with narrowly scoped, time-limited access tied to a specific support case or operational window, then revoke it automatically after closure.
• Align BYOC governance with lifecycle controls Apply provisioning, review, and offboarding rules to vendor-access identities the same way you would for internal service accounts, especially where access spans multiple customer environments.

Key takeaways

• Bring Your Own Cloud shifts enterprise software governance from shared SaaS trust to explicit customer-controlled boundaries.
• Drift detection and approval workflows matter because customer-hosted deployment turns support access into a privileged identity problem.
• BYOC will force IAM and cloud teams to define exactly who can change, remediate, and recover workloads inside customer-owned environments.

Key terms

• Bring Your Own Cloud: A deployment model where software runs inside the customer’s cloud account rather than the vendor’s environment. It gives the customer stronger control over data residency, operational boundaries, and access decisions, while forcing the vendor to support the application through explicitly governed cross-boundary workflows.
• Drift Detection: The process of comparing intended application state with what is actually running in a live environment. In BYOC setups, it becomes both a configuration control and an identity signal, because unauthorized drift can reveal who changed the system and whether the change was approved.
• Delegated Change Authority: A governance pattern where one party can propose or remediate a change, but another party controls whether that change is authorized to take effect. It is especially important in customer-hosted deployments, where vendor support actions must not silently become standing administrative power.

Deepen your knowledge

Bring Your Own Cloud governance and delegated access control are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for customer-hosted deployments or cross-boundary support access, it is worth exploring.

This post draws on content published by WorkOS: The Bring Your Own Cloud Movement: Nuon's Solution for Enterprise AI Deployment At Enterprise Ready Conference 2025. Read the original.