Government & public sector

Extend the authorization you already have

Samba runs inside your cluster, under your identity, on your network. There is no new vendor authorization to sponsor, no new data-sharing agreement to negotiate, and no third party holding your data on the other side of your boundary.

We are not FedRAMP authorized. That is the model.

It is the first question, so here is the answer before you ask it. Cirrus Tempo does not hold a FedRAMP authorization and is not pursuing one. Samba is not a service you connect to — it is software you run, inside a boundary you already had authorized.

The closest familiar analogy is the way you already treat software operating inside your authorized tenant: the authorization boundary is yours, the data never leaves it, and the vendor is not in the data path. Your existing ATO, StateRAMP authorization, or agency security package extends to cover Samba's operation the same way it covers the other workloads in that cluster.

This is a narrower claim than "we are authorized," and a more useful one. A vendor authorization is a thing you inherit risk from. A workload inside your own boundary is a thing you already know how to assess.

You own the boundary

Samba deploys into your Kubernetes cluster, under your IAM, on your network. The accreditation boundary is the one you already maintain — we do not add a new one for you to account for.

We are not in the data path

Credentials, payloads, and audit logs never transit a Cirrus Tempo system. There is no vendor tenant holding your data, which is why our row in your security package is a short one.

Evidence stays with you

Control evaluation and the immutable audit log are generated inside your environment. Your staff and your assessor read them directly, rather than requesting an artifact from a vendor.

Change control is yours

You choose the version and the change window. An integration promotes through Development, Testing, and Production behind approval gates you configure — not on a vendor's release schedule.

Where the architecture lands

Each of these frameworks cares, in one way or another, about where your data sits and who can reach it. A customer-deployed integration tier gives the same answer to all of them.

Framework What it asks about the integration tier What the customer-deployed model answers
FedRAMP / FISMA Is there a cloud service in the boundary that needs its own authorization? No service to authorize. Samba is a workload inside the boundary you already accredited, assessed under the controls you already apply.
StateRAMP Same data-isolation expectations, at state scale and state budget. Single-tenant by architecture rather than by contract term, so isolation is not something to verify annually.
NIST 800-171 How is the system boundary protected, and what crosses it? Data does not leave your cluster. Boundary protection is a property of where the software runs, not of a vendor's controls.
CJIS Who can reach criminal justice information, and from where? Access is governed by your IdP and your network policy. No vendor personnel or vendor infrastructure sit between you and the data.
FERPA Is student data disclosed to a third party, and under what terms? There is no disclosure to negotiate around the integration tier, because the platform never receives the records it moves.
ITAR Does export-controlled technical data stay within authorized infrastructure? It stays in your cluster, in your region, under your access controls. No vendor egress path exists in the data plane.

Handling CUI under CMMC? That conversation has its own page — the boundary math for a Level 2 assessment.

Two conversations, one architecture

Federal civilian
No vendor authorization to sponsor

The friction in adopting a new integration platform is rarely the software. It is the authorization work that follows — sponsoring a package, assessing a vendor, defending the addition to your boundary at the next review.

A workload deployed into infrastructure already inside your accreditation boundary does not create that work. The question moves from "can we authorize this vendor?" to "does this workload meet the controls we already apply?" — which is a question your team answers routinely.

State, local & higher education
Federal-grade obligations, without federal budget

StateRAMP in an RFP, CJIS in a justice-system integration, FERPA across a student information system — the obligations are real, and the team carrying them is usually small and already stretched across an SIS or ERP modernization.

The single-tenant model removes the third-party assessment cycle entirely, and the platform is built to be operated by a small team: health and failure analysis are built in, and recovery actions are scoped and reversible rather than free-form.

"And where does the AI run?"

Inside your tenant. AI authoring runs against your Azure OpenAI endpoint, under your key — you are pointing Samba at a Microsoft service that carries its own authorizations in the relevant clouds, not at an inference endpoint Cirrus Tempo operates on your behalf. Your prompts, and the code they produce, stay in your subscription.

Everything the AI produces is validated against a formal grammar before it can reach the runtime, and what ships is Python your staff can read and your change process can review. When the AI is diagnosing a problem rather than authoring one, it works from a closed catalog of findings and labels its own certainty — it cannot invent a diagnosis.

And if external inference is not acceptable in your environment at all: the platform runs entirely without it. Every AI surface is additive and degrades cleanly, leaving a fully functional integration platform. If a disconnected deployment is a hard requirement, tell us early and we will be straight with you about where that sits rather than implying it ships today.

Evidence generated in your environment, on your schedule

Samba evaluates a catalog of 54 security controls against the cluster it is actually running in, each carrying its SOC 2 criterion and NIST 800-53 lineage. Your staff read the results directly — no vendor in the loop, nothing to request, no one else's schedule to wait on.

Take it with you

The government fit, in two pages — the boundary case, what's built and visible today, and where it lands for DIB, federal civilian, and SLED. No form to fill out.

Download the one-pager (PDF)

Bring your security architect

The useful first conversation is an architecture review, not a demo. The boundary model either fits your environment or it does not, and that is a faster thing to establish with the person who will have to defend it.