Revoking Vendor Compute Access Without Losing Developer Deployment Ergonomics

A PaaS built on bring-your-own-cloud (BYOC) architecture deploys workloads directly into a customer's own AWS, GCP, or Azure account. That single design choice makes revoking a departing developer's access, or a vendor's own implicit access, either a routine IAM operation or a multi-system scramble. This piece explains why traditional PaaS platforms make access revocation so disruptive, and why BYOC is the structural fix.

Why revoking vendor compute access breaks developer workflows

A payments company in Irvine learned the gap between "disabled" and "revoked" the hard way. But for nineteen days, someone with no contract, no badge, and no SSO account held a working credential to a production AWS account, and the only reason anyone found out was luck.

Disabling the Entra account never touched that key because the two were never connected, which is the architectural root of the problem. Traditional PaaS platforms don't break access revocation because the tooling is bad. They break it because the vendor's infrastructure runs as both the control plane (the UI, the CI/CD pipeline, the routing logic) and the data plane (the actual compute where workloads execute) at once. A developer's deployment experience and the security perimeter sit on the same surface. Revoking a person's access means touching the deployment path itself, which forces a choice between keeping things running smoothly and locking things down properly.

This is the product design, not a flaw a patch release fixes. The Irvine case shows what that habit costs.

How far vendor credentials travel before anyone notices

The access surface a contractor or engineer leaves behind on a vendor-hosted platform runs far wider than the single SSO account you switch off. Disabling an identity provider account stops new logins. It does nothing to existing sessions already in progress, tokens already issued, or keys the person generated themselves outside the provisioning system.

Microsoft's own Entra ID documentation backs this up: access tokens last one hour by default, and once an application issues its own session cookie, Entra "can't directly revoke a session token issued by an application." GitHub's SCIM documentation carries a similar warning, stating that members whose IdP access is removed "aren't automatically removed from the organization" if SCIM provisioning was never set up. Both gaps sit quietly in most offboarding workflows until something forces them into view.

The credential that lingers longest is usually the one nobody logged in the first place: a personal access token or IAM key a developer created on day twelve to unblock a CI job, never tracked in any provisioning ticket, never reviewed because nobody knew to look for it. Rotating them means coordinating with the vendor's own access model, not just clicking through an internal IAM console.

AI agent workloads make the same problem sharper. Scalekit's security questionnaire for AI agent vendors names this the "integration layer," the part of the stack that stores a refresh token for every connected app and executes every tool call. Regulated buyers now ask, directly, where that layer runs, where data lands on each hop, and who holds the key to the credentials it stores.

Where tighter SSO and more audit tooling fall short

Better identity tooling helps, but it patches individual credential types and never touches the structural cause. The list of tools grows every time a new vendor joins the stack, and the maintenance burden grows with it.

In a shared-tenant PaaS, the vendor's own service accounts and infrastructure credentials run alongside a customer's, and that overlap is what causes all of the tooling above to fall short. A security team can revoke its own team's access cleanly. It cannot revoke the vendor's implicit access to the compute its workloads run on, because that access was never granted through a system the customer controls. It was built into the platform from the start.

That distinction matters most under regulatory scrutiny. A SOC 2 auditor or HIPAA reviewer doesn't stop at asking who on a team had access. The question extends to who could have accessed data at the infrastructure layer, and in a vendor-hosted model, the honest answer includes the vendor itself. Scalekit's security questionnaire framework for AI agent vendors captures the same shift among regulated buyers: they want to know whether the integration layer can run entirely inside their own boundary, not whether the vendor holds a SOC 2 certificate. It says nothing about whether the customer could produce its own answer to the auditor's question without the vendor's help.

The strongest defense of the status quo usually sounds something like this: "We have SSO, SCIM, and a 30-minute offboarding runbook, that's enough for our risk profile." That runbook closes the provisioned-credential surface described above. No amount of additional tooling raises it, because the tooling operates downstream of a boundary the vendor, not the customer, controls.

What BYOC separates

A BYOC architecture resolves the tension between revocation and ergonomics by moving the security boundary from the credential level to the infrastructure level. The vendor's control plane still orchestrates deployments. The compute where workloads run and data lands sits inside the customer's own cloud account, under the customer's own IAM.

The split works like this. The data plane, customer-owned, covers the VPC, the cluster, the running containers, the database instances, and object storage: everything that holds code, data, and credentials while the workload is actually running.

Platforms built on this model sidestep the conflation described earlier. Revoking access to specific cloud resources becomes a standard IAM operation inside a customer's own AWS, GCP, or Azure account, governed by that customer's own audit trail and rotation schedule.

Self-hosted this way, Scalekit has no database access and no visibility into stored data.

The part developers actually touch doesn't change. The git-push workflow, the environment dashboard, the preview environments, none of it moves. The separation is invisible during normal operation and only becomes visible to the security team at the exact moment it matters: when someone needs to revoke, rotate, or restrict access without waiting on the vendor.

What clean revocation looks like in a BYOC deployment

Once compute runs inside a customer's own cloud account, revocation becomes a set of standard cloud IAM operations: auditable, automatable, and scoped to exactly the resources that need to change.

Revoking a developer's deployment access in this model follows a short sequence. Any IAM role or service account the developer was bound to gets rotated through a native AWS, GCP, or Azure operation. Running workloads are unaffected by either step, because they're bound to cluster-level service accounts, not to the departing developer's personal identity.

Revoking the vendor's own access to a customer's compute, the question a shared-tenant model structurally can't answer, works the same way. In a BYOC model, the vendor's control plane connects to the customer's cluster through a narrowly scoped role, typically a cross-account IAM role or a Kubernetes service account with defined permissions. Credential decryption itself sits under the customer's unilateral control.

AI agent identities follow the same pattern. Agents provisioned inside a customer's own VPC hold their credentials in that customer's secrets store, not the vendor's, so rotating them follows the same secret rotation playbook already in use for everything else.

What ties all of this together is a unified audit trail. CloudTrail, the customer's SIEM, and the cluster's own audit log all see the same events because the customer owns both the compute and the logging infrastructure underneath it.

Preserving the deployment experience developers depend on during the transition

Git-push deploys, environment promotion, preview environments, and managed backing services are all control-plane capabilities. A well-built BYOC platform delivers every one of them unchanged while the data plane moves into the customer's own cloud account.

The features that define modern PaaS ergonomics are orchestration features, not compute features, and the distinction holds up under scrutiny. A git push still triggers a build in the control plane, which schedules a workload on the customer's cluster. The developer just sees a deploy log, so where the cluster physically runs doesn't change that experience. Managed databases, Postgres, Redis, and similar services run inside the customer's VPC. The security team gets network-level isolation and encryption keys it actually controls.

The practical worry that follows is reasonable: does the platform team now own cluster upgrades, CVE patches, and autoscaling? Porter deploys production-ready environments directly into a customer's own AWS, GCP, or Azure account and manages cluster upgrades, CVE patching, autoscaling, and networking on the customer's behalf, so moving the data plane in-house doesn't hand the platform team a new operational burden. Porter charges for the compute teams request, by vCPU and GB of RAM, rather than for raw cloud instance capacity, and bills a request sized larger than what's actually used at the size requested.

Onboarding doesn't suffer either. The control plane provisions workspace access, the new developer's identity is scoped to the customer's own IdP from the first day, and the compute they touch already sits inside the customer's perimeter. No new credential surface opens up outside the boundary the security team already controls.

Where compliance and data residency requirements make BYOC non-optional

For a team under active compliance review, where compute runs stops being an architectural preference. It becomes the literal answer to the auditor's question about who had access to data at the infrastructure layer.

SOC 2 Type II and HIPAA both require you to demonstrate that access controls operated correctly over time, and that claim depends on owning the audit log and the access boundary being audited. In a shared-tenant PaaS, the vendor's infrastructure sits inside the scope of that audit whether the customer wants it there or not. The vendor's own SOC 2 certification covers the vendor's controls, not the customer's. In a BYOC model, the compute sits inside the customer's own AWS, GCP, or Azure account, so the CloudTrail log, the VPC flow log, and the cluster audit log all belong to the customer. So the auditor's access control questions have answers the customer can actually produce.

Data residency rules, increasingly common across healthcare, financial services, and government work, specify not just where data sits at rest but where it gets processed. A vendor-hosted model can't answer that with "inside your perimeter," because the perimeter in question belongs to the vendor, not the customer.

AI startups face this faster than most teams expect. Inference workloads process user data at runtime. Input and output logs from the model may contain PHI or PII. Each of these is a data residency question in its own right, not a side effect of model quality.

A structural fix requires separating where workloads run from where the vendor's control plane lives. Porter's SOC 2 and HIPAA compliance tooling is built around exactly this intersection: compliance controls run inside the customer's own cloud account as part of the infrastructure itself, so audit evidence comes from the infrastructure directly rather than getting assembled after the fact from scattered logs.

Deciding how much of the BYOC model your team needs right now

BYOC isn't an all-or-nothing migration. The right amount to adopt depends on which specific tension between revocation and ergonomics a team is already feeling, and the path toward it should match that tension.

Three triggers tend to make the move urgent. The first is an offboarding incident that exposes a real credential gap, the Irvine case being the clearest example of what that looks like. The fix for that kind of incident isn't a longer checklist. The second is a compliance review, SOC 2 Type II, HIPAA, or a regulated buyer's security questionnaire, that asks directly where compute runs and who holds infrastructure-layer access, a question a shared-tenant PaaS cannot answer to a reviewer's satisfaction. The third is an AI agent or integration layer that holds OAuth tokens and runs tool calls against sensitive systems, the point at which that layer's residency turns into a first-class security question, exactly as Scalekit's questionnaire framework documents.

Starting small doesn't mean doing less of the work that matters. Moving production compute into a customer's own cloud account while keeping the vendor's control plane intact is the minimal viable BYOC step: developers notice nothing different day to day, and the security team gains the IAM boundary it needed. Teams that choose a platform handling upgrades, patching, and autoscaling automatically, Porter's model among them, don't need to staff a platform engineering function just to take this step.

Waiting carries a real cost. Every month spent on a shared-tenant PaaS is another month in which new credentials get issued outside the IAM boundary, new agents get provisioned without proper key custody, and the audit gap widens. The set of credentials and agents that need revoking doesn't hold steady at its current size. It grows with the team, and the team that builds the BYOC separation early doesn't face a multi-month remediation project the day an enterprise customer sends over a security questionnaire or a contractor offboarding incident surfaces the next credential gap nobody was tracking.