Ownership by design

Kapten · Whitepaper WP-03 · 13 October 2026

1. Two questions that used to have one answer

When a team adopts a hosting platform, two questions are usually answered together without anyone noticing that they are separate:

1. Who operates the infrastructure? Who provisions it, upgrades it, patches it, watches it and gets paged when it fails.
2. Who owns the infrastructure? Whose account it lives in, whose bill it appears on, whose region it sits in, whose audit trail records what happens to it.

A traditional platform-as-a-service answers both with “the vendor”. Self-hosting answers both with “you”. Bring-your-own-cloud (BYOC) is the architecture that answers them differently: the vendor operates, and you own.

That split is the subject of this paper. It is worth taking slowly, because the terms are used loosely. BYOC is frequently described as a flavour of self-hosting, and it is closer to the opposite. Self-hosting hands you the software and the operational burden. BYOC leaves the operating with the vendor and hands you the account it happens in.

2. Control plane and data plane

The architecture rests on a separation that networking engineers will recognise.

The data plane

The data plane is everything that serves your users: the Kubernetes cluster, the containers running your services, the managed databases, the caches, the object storage, the load balancers, the network between them, and above all the data itself. In a BYOC architecture, all of this lives in your cloud account.

The control plane

The control plane is everything that decides what the data plane should look like and makes it so: the user interface, the API, the agents, the workflow engine, the plans, the history of deployments and the record of who approved what. In Kapten’s architecture, the control plane is operated by Kapten.

The boundary between them

The two planes meet at a single, deliberately narrow point: a role in your account that the control plane may assume to make changes. Everything interesting about the security of the model is a property of that boundary.

The fourth row is the one that matters most. If the control plane is unavailable (for maintenance, for an outage, or because you have stopped using it), the data plane continues to serve your users. You lose the ability to make changes through Kapten until it returns, not the application.

3. The access boundary, precisely

Every BYOC vendor says “least privilege”. The useful version of that sentence names what the vendor can do. Here is the shape Kapten asks for, described the same way as in our article on what a scoped role actually scopes.

A role you create

You create a role in your account and allow Kapten’s control plane to assume it. Kapten holds no long-lived credential for your account: no access keys, no stored passwords. If you delete the role, access ends at the next session boundary.

Short-lived sessions

Each operation assumes the role for a short session (fifteen minutes, 900 seconds), and the session expires on its own. There is no standing connection to revoke, because there is no standing connection.

Limited to what the platform created

The role’s permissions are conditioned on a tag that the control plane sets when it creates a resource. The role can create and manage resources carrying that tag, and nothing else. It cannot read your object storage contents, it cannot read your database contents, and it cannot modify resources it did not create: the existing VPC your billing system runs in is outside its reach.

Recorded where you can see it

Every call made through the role appears in your cloud provider’s own audit trail, attributed to the role. You do not need to trust Kapten’s log of what Kapten did; you can read your own.

The one-sentence test

The useful test of an access model is whether you can describe, in a single sentence, what the vendor could do on its worst day. For this model: create, modify and destroy the infrastructure it provisioned, for fifteen minutes at a time, in one account, with every call in your own audit trail. If a vendor cannot give you an equivalent sentence, the policy is probably broader than it looks.

Agents inside the boundary

Kapten’s agents act through exactly the same boundary. An agent applying an approved plan uses the same scoped, short-lived role as any other operation; it gains no additional reach by being an agent. The permission tiers described in The agentic SRE (Observe, Plan, Act) sit on top of the role, never beside it.

4. Residency, regions and the data question

The most common reason teams look at BYOC is a question from a customer, a regulator or their own legal counsel: where is our data?

With a hosted platform, the honest answer is “in our vendor’s account, in the regions they operate in, under their sub-processors”. That answer is often acceptable, but it is not yours to change.

With a BYOC architecture, the answer is your own architecture:

• You choose the region. The cluster, the databases and the storage are created in the region you select for each environment, and they stay there.
• Application data does not transit the control plane. Requests from your users go to your load balancer in your account. Your database contents are not read by the role. What the control plane does see is metadata: resource identifiers, configuration you choose to manage through it, deployment status, and the logs and metrics you choose to surface.
• You can draw the diagram. For a security questionnaire or a data processing assessment, you can describe exactly what runs where, because it is in your account and you can inspect it.

Account layout

Ownership is easier to reason about when the account structure reflects it. A layout that works well for most teams:

• One account per environment class. Production in its own account, staging and previews in another. A mistake in a preview cannot reach production resources, because they are not in the same account, and the scoped role in each account is granted separately.
• One region per production environment, chosen deliberately. Multi-region is a real requirement for some applications and an expensive habit for others. Start with the region your users and your data obligations point to.
• Shared services kept apart. Your existing VPCs, identity configuration, billing tooling and anything Kapten did not create stay out of reach of the role by construction, because the role is limited to tagged resources.

This is an example, not a prescription. Teams with an existing landing zone or organisation structure should fit Kapten’s role into it rather than the reverse; that conversation is part of onboarding.

Data residency in practice

It is important to be precise here, because overstatement is common. BYOC does not make data residency automatic. Observability data, build artefacts, support access and any third-party services your application uses each need their own answer. The architecture makes those answers yours to give; it does not give them for you.

5. Bills, credits and commitments

The second most common reason is money, and it is less obvious than it looks.

The resources are on your invoice

Infrastructure usage appears on your cloud provider’s bill, at your provider’s prices. Kapten’s fee is separate and does not include a markup on compute or storage.

Your existing agreements apply

Because usage is in your account, it counts towards whatever you already have with the provider: startup credits, committed-spend agreements, reserved capacity, savings plans, enterprise discounts and marketplace arrangements. For teams that have negotiated these, a hosted platform’s resources are invisible to them. A BYOC platform’s resources are not.

Cost is visible at the source

Your finance team sees infrastructure spend where they already look for it, tagged by environment and service. The Purser agent reads the same source when it estimates plans and looks for idle resources. There is one bill to reconcile, not two that overlap.

The trade-off

Owning the bill also means owning its surprises. A hosted platform absorbs some cost variability into a flat price; a BYOC deployment exposes it. That is why cost estimation on every plan, budget caps per environment and regular reviews of idle resources are part of the operating model rather than optional extras.

6. Exit as a design requirement

The quality of an architecture shows most clearly at its end. A platform you can only leave by rebuilding is a platform you are locked into, whatever its contract says.

Standard building blocks

Kapten provisions conventional infrastructure: Kubernetes, the provider’s managed databases and storage, standard networking and load balancing. Nothing in your account requires Kapten’s software to keep running. Your workloads are container images in a registry you can read.

What leaving looks like

If you stop using Kapten:

1. Revoke the role. Within one session lifetime, Kapten can no longer act in your account.
2. Your applications keep serving traffic. The cluster, the databases and the network are unchanged.
3. Your team takes over operations: upgrades, certificates, scaling, backups, monitoring, deployments.

Step three is real work, and it should be planned rather than discovered. A reasonable exit plan answers, before you need it:

• Who will operate the cluster and apply upgrades?
• How will deployments run: which pipeline, which tooling?
• Where will monitoring and alerting come from?
• Who owns backups and has tested a restore?
• Which resources are tagged as created by Kapten, and which of those should remain?

Exit as the natural next step

For many teams, leaving a managed operations layer is not a failure but a milestone: the point at which they hire a platform team. The most useful thing an operations platform can do for that team is to hand over an inventory of standard, tagged, documented resources rather than an opaque system to be reverse-engineered.

7. Deploying into your customers’ clouds

The same architecture extends naturally to a harder problem: a SaaS vendor whose customers want the software to run inside their cloud account.

Enterprise customers ask for this for the same reasons as above (residency, procurement through their own cloud agreements, data that never leaves their perimeter), and it has historically been expensive to offer. Each customer deployment becomes a bespoke installation, operated by a vendor team that has to negotiate access separately every time.

Three parties, three boundaries

With BYOC, the customer deployment has three parties:

• The customer owns the account, the data and the bill.
• The vendor owns the application and its releases.
• Kapten operates the platform the application runs on, through a scoped role the customer grants.

Each boundary can be described in the same one-sentence style, and each can be reviewed by the customer’s security team.

A repeatable shape

The practical value is repeatability. The vendor defines the application’s shape once (services, data stores, configuration), and each customer environment is an instance of it in a different account and region, with its own secrets and its own owner. Releases follow the same plan-and-approve path for every customer, so the vendor’s release process does not fork per customer.

Customer-cloud deployments are a pilot use case during early access. Automated fleet rollout, reseller workflows and dynamic customer provisioning should be scoped with the Kapten team before you commit to them; availability is confirmed during onboarding.

Onboarding a customer, step by step

An illustrative sequence for a first customer pilot:

1. Agree the account model. A dedicated account in the customer’s organisation is the cleanest option. The customer’s cloud team creates it, or nominates an existing one.
2. Agree the access model. The customer creates the scoped role from a policy they can read in full, and decides who on their side is notified of changes.
3. Instantiate the application shape. The vendor’s services, data stores and configuration are planned for the customer’s region, with customer-specific secrets entered by the people entitled to hold them.
4. Review the plan together. The customer’s security team sees exactly what will be created before it is created: a plan, not a promise.
5. Release. The vendor’s release goes out behind health checks, following the same path as every other environment.
6. Agree the operating rhythm. Release windows, incident contacts, upgrade notice periods and the exit procedure are written down before the first incident, not during it.

The point of writing this sequence down is that the second customer should be faster than the first, and the tenth should be routine.

Shared responsibility

The split will differ for every contract. Its value is that the conversation starts from a written split rather than an assumption.

8. Questions for a security review

Whether you are adopting BYOC for your own infrastructure or reviewing a vendor who wants to deploy into yours, these are the questions worth asking. They apply to Kapten and to any other vendor.

Access

• What exactly is the role allowed to do? Can the vendor describe the worst case in one sentence?
• Is any long-lived credential stored by the vendor? Where, and how is it rotated?
• How long does a session last? Can access be revoked immediately?
• Is the role restricted to resources the vendor created? How is that enforced?

Data

• Which data, if any, leaves the account? Logs, metrics, build artefacts, configuration?
• Can the vendor read database or object storage contents? Under what circumstances?
• Where is control-plane metadata stored, and in which region?

Agents

• Which actions can agents take without human approval?
• How are approvals attributed to named people?
• How is untrusted content (logs, repositories) prevented from becoming instructions?
• Are agent actions distinguishable in the audit trail?

Operations and exit

• What happens to running workloads if the control plane is unavailable?
• What is the documented process for leaving? What is handed over?
• Who is responsible for upgrades, patches and backups, and how is that verified?

Evidence

• Which claims are backed by documentation you can read, and which by assurances?
• Which certifications does the vendor hold today, as opposed to plan to hold?

The last question deserves emphasis. During early access, verify every security claim, including ours, against documentation and the policies you are asked to deploy, rather than against marketing pages.

Where to start

• Review security and access for the boundary described in this paper.
• Explore bring your own cloud and the SaaS vendor solution.
• Work through the customer-cloud deployment guide before a first customer pilot.
• See how agents act within the same boundary on the MCP overview and in the workflow library.
• Request early access with your target account model and the questions your security team will ask.