Where the integration tier sits in your boundary
Most organizations should buy a multi-tenant integration platform. It is cheaper to operate, it has more connectors, and the shared-runtime economics are genuinely better. This page is about the case where none of that is available to you — and what changes when the integration tier has to stay inside a boundary you already had authorized.
The structural problem
An integration platform is, by definition, the system that holds credentials to every other system. It authenticates to your EHR, your ERP, your claims processor, your PLM. It sees the payloads in between. It is the one component in your estate whose job description is having access to everything.
When that component runs in a vendor's tenant, three things become true at once, and they compound:
Your credentials live somewhere you do not control. Not the data — the keys to the data. A breach of the integration vendor is a breach of everything it connects to.
Your payloads transit a boundary your authorization does not cover. If those payloads contain PHI, CUI, or cardholder data, you have extended the scope of your obligations to an environment you cannot inspect.
Your change control becomes someone else's release schedule. In a validated or authorized environment, an unannounced upstream change is not a convenience question. It is a revalidation event.
None of this is a criticism of multi-tenant design. It is an accurate description of what that design costs in a context where the boundary is the product of years of work and an auditor's signature.
The same integration, two architectures
Where the integration tier sits is the entire difference. Everything else follows from it.
Nothing crosses the line. The integration tier is one more workload inside a boundary your assessor has already signed off on.
A second boundary to account for. Plus a vendor in your SSP, a risk assessment that renews annually, and a release schedule you do not control.
Two designs, side by side
Written to be checked. If any row here does not match what you find in evaluation, tell us and we will fix the page.
| Dimension | Single-tenant, customer-deployed |
Multi-tenant SaaS |
|---|---|---|
| Where payloads are processed | Inside your Kubernetes cluster, in your subscription. | Inside the vendor's tenant, on shared infrastructure. |
| Where system credentials live | Your secret store (Vault), under your key management. | The vendor's credential vault, under theirs. |
| Identity & access | Your IdP, your groups, your conditional access policies. | The vendor's user model, federated to your IdP. |
| Network position | Inside your segmentation. Can reach private endpoints with no inbound path from the internet. | Outside. Typically requires an egress path, an agent, or exposure of private systems. |
| Authorization boundary | Extends the ATO, HITRUST, or CMMC boundary you already hold. | A distinct boundary you must assess, sponsor, and re-assess. |
| Vendor risk profile | Software you operate. The vendor holds none of your data. | A data processor in your critical path, and a fourth-party question for your examiner. |
| Upgrade control | You choose the version and the change window. | The vendor's release train, usually without opt-out. |
| Control evidence | Generated in your environment, readable by your assessor on their schedule. | Requested from the vendor, delivered on theirs, scoped to their environment. |
| Breach blast radius | Contained to your own cluster, like any other application you run. | A platform compromise is potentially a compromise of every tenant on it. |
| Exit | The deployment and its configuration are yours; source escrow is available. | Migration off the platform, on the vendor's export terms. |
| Connector breadth | Zero pre-built connectors. REST, JSON/XML, and Python transforms. | Hundreds of maintained connectors — a genuine advantage. |
| Operating cost | You run the cluster. That is real infrastructure and real staff time. | Amortized across tenants. Meaningfully cheaper to operate. |
What the single-tenant design costs you
This design is not free. Here is what you take on, stated plainly, so you can decide whether the trade is worth it in your environment.
You operate a Kubernetes cluster
Samba deploys as a self-contained cluster into your cloud account, but it is still infrastructure in your estate. If you have no Kubernetes capability and no intent to build one, that is a real cost and you should weigh it honestly.
There are no pre-built connectors
Zero. Integrations are REST endpoints and Python transforms. For a team that wants to click a Salesforce tile and be done, this is the wrong product — and a competitor with 400 connectors is the right one.
You own the upgrade decision
Controlling the change window means you have to schedule it. Version currency becomes your responsibility rather than something that happens to you.
Per-tenant economics are worse
A dedicated cluster costs more to run than a slice of a shared one. We think the boundary is worth it in regulated contexts. In unregulated ones it usually is not.
"And where does the AI run?"
This is the right question and it is usually the second one we get. The honest answer has three parts.
One. AI authoring runs against your Azure OpenAI endpoint, under your key, inside your tenant. Cirrus Tempo does not host inference on your behalf. Your prompts and the code they produce stay in your subscription.
Two. That holds when your deployment is provisioned with its own AI configuration, which is how customer deployments are provisioned. It is a question worth asking us directly about your specific deployment, and we will answer it precisely rather than generally.
Three. The platform runs without AI at all. The AI surfaces are additive and degrade cleanly — an operator who declines external inference entirely still has a fully working integration platform. If you need inference against an endpoint you host yourself, that sits behind a single-method interface that nothing else in the system depends on. It is contained work against an existing seam. It is also code rather than configuration, and we would scope it with you rather than imply it is a setting you can flip.
What we will not tell you is that Samba is air-gapped or model-agnostic today. One inference provider is implemented. Model-portable by design; Azure OpenAI today.