Notifications
Clear all
Topic starter
07/06/2026 9:02 pm
TL;DR: Bring Your Own Cloud is becoming a practical requirement for regulated enterprise software because customers want applications to run in their own AWS, GCP, or Azure environments, with drift detection and approval workflows used to preserve operational control, according to WorkOS coverage of Nuon at Enterprise Ready Conference 2025. The governance question is no longer whether to support customer-hosted deployment, but how to do it without losing change control, supportability, or identity boundaries.
NHIMG editorial — based on content published by WorkOS: The Bring Your Own Cloud Movement: Nuon's Solution for Enterprise AI Deployment At Enterprise Ready Conference 2025
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- The live conference demo of drift detection against a Kubernetes config map in a customer-hosted cluster.
- The approval workflow mechanics used to review customer changes before they are applied.
- The deployment and troubleshooting workflow for vendors that need support visibility without direct cloud access.
- The conference context and speaker framing behind the BYOC discussion.
👉 Read WorkOS's recap of Nuon's BYOC demo for enterprise AI deployment →
Bring your own cloud deployments: what IAM teams need to know?
Explore further
08/06/2026 8:48 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Bring your own cloud changes enterprise AI deployment controls
