# "Just put the gateway in your own tenant" is the wrong fix

October 15, 2026 · Eric Magliarditi

Canonical: https://consus.io/blog/gateway-in-your-own-tenant-is-the-wrong-fix

> Deploying an AI gateway into your own government cloud tenant makes your CMMC boundary bigger, not smaller. Here is why, and when it is still the right call.

There is a pitch going around the defense industrial base that sounds great in a demo. It goes like this: don't send your CUI through someone else's gateway. We'll deploy a gateway into your own Azure Government, AWS GovCloud, or GCP Assured Workloads account. Your boundary stays exactly where it is. Tokens at cost. One line of code.

I spent years at SpaceX and Castelion on the receiving end of compliance architecture, and I now run a company whose entire product is routing AI inference for contractors handling CUI and ITAR data. I want to explain why "a gateway in your tenant" is a worse deal than it looks, and when it is actually the right call.

## The boundary does not stay unchanged. It grows.

The core claim is that deploying into your tenant keeps your assessment boundary untouched. The opposite is true.

Every resource a vendor stands up inside your account is yours the moment it is created. The compute. The networking. The key vault. The log sink. The identity federation. The patch cadence. At your CMMC Level 2 assessment, nobody asks who originally clicked the buttons. They ask who operates it, who reviews the logs, who rotates the keys, who responds when something breaks at 2am, and where that is written down in your SSP.

A "hardened environment configured before the first request" is a snapshot. Compliance is not a snapshot. It is 110 practices you have to keep doing. If the gateway runs in your tenant, you are the system owner for every one of those practices as they apply to it. The vendor's evidence package tells your assessor what the configuration looked like on day one. It does not tell them who has been maintaining it since.

Compare that to Consus. Your prompt goes in, the response comes back, and your prompts and completions are never written to disk, logs, or any store along the way. We keep only operational metadata (model, tokens, timestamps, routing decision), which is the audit trail your assessor wants to see. Consus still goes into your SSP, as an external service provider with its own body of evidence. What it does not add is infrastructure you operate, because there is no new infrastructure in your account.

## "Every model your cloud offers" means one cloud, one vendor

This is the part the diagram leaves out.

Claude is not on Azure Government. OpenAI's frontier GPT models are not on AWS GovCloud. Gemini is only on GCP, and Vertex generative serving is not inside the ITAR scope of Assured Workloads at all. If you want Claude and GPT for your engineers, and you want them on authorized infrastructure, you need at least two government clouds. Three if you want Gemini for non-ITAR work.

"Deploy into your tenant" quietly becomes "deploy into your tenants." Each one needs its own account, its own authorization, its own model enablement (Bedrock model access in GovCloud and Azure OpenAI approval in Azure Government are both separate requests with their own timelines), its own key management, and its own logging. That is three environments you now operate, and the gateway in each of them is yours.

Consus runs those three clouds so you don't have to. One API key reaches Claude on Bedrock GovCloud, GPT on Azure Government, and Gemini on Vertex in Assured Workloads. The compliance level is in the model ID. `claude-sonnet-4-5:itar` goes to an ITAR-authorized path and nowhere else. A request with no compliance level is rejected. The multi-cloud engineering is the product. That is not a markup; it is the thing you are buying.

## Most small contractors do not have a government cloud account

If you have 30 engineers and a DFARS 7012 clause, there is a decent chance you do not currently have an Azure Government subscription or a GovCloud account. Getting one is not instant. Microsoft screens Azure Government customers. AWS GovCloud requires an existing commercial account and its own vetting. Then you need the Bedrock or Azure OpenAI enablement on top. Realistically that is weeks, and for some teams it is months.

The "one line of code" in the in-your-tenant pitch is the last line. Everything that comes before it is on you.

With Consus, access is typically approved within 24 hours, you change one base URL, and you are running real requests through a compliant path the same day. Your compliance team reviews our architecture and evidence in parallel. Nobody waits on a cloud onboarding queue.

## "Tokens at cost" has three cloud bills attached

Tokens at cost is a fine principle, and we do it too. Both models also charge a platform fee on top of the tokens. The difference is what sits next to that fee. In your own tenant, you are also paying for provisioned throughput on Azure OpenAI, Bedrock capacity on GovCloud, and Vertex on GCP. That is three cloud bills, three sets of reserved capacity decisions, and three sets of idle-capacity risk, plus the engineering time to keep all of it running. With Consus, the platform fee and the tokens are the whole bill.

The honest way to compare cost is total cost under the same workload assumptions: volume, required models, compliance levels, retention, staffing, and evidence obligations. For a small team, the labor line dominates the token line every time.

## Who gets admin access to your government tenant?

To deploy a gateway into your tenant, the vendor usually needs privileged access to your tenant, unless your own team runs their deployment. Someone from outside your company is creating resources, configuring identity, and setting up key management inside the environment that holds your CUI.

That is not disqualifying, but it is an access-control question your assessor will ask, and you need a good answer. Who at the vendor had access? For how long? Was it revoked? What did they touch? Is any of it still running under a service principal they created?

Consus needs zero access to your tenant. You get an API key. We never see your cloud.

## "ITAR by design" is not a region setting

ITAR is an export control regime. It is about who can access technical data, not just where the server sits. A US region is a good start, but it does not make a system ITAR-compliant on its own. The question is whether a foreign person could get at your unencrypted technical data anywhere in the path, and whether you can show that they could not. We answer it the conservative way: US-only regions, US persons only in the data plane, FIPS 140 validated encryption end to end, and no prompts or completions stored.

Consus routes ITAR-tagged requests only to providers with an ITAR-authorized path (today that is Bedrock in AWS GovCloud and Azure OpenAI in Azure Government; Gemini is not offered for ITAR because it does not qualify). We do not treat "US region" as the finish line, and you should not accept a pitch that does.

## The question you should ask us, and anyone else

Here is the strongest argument for the in-your-tenant model, and I am going to make it for them because you should hear it.

If a third party processes your CUI, that third party is an external service provider under the CMMC rule, and it needs FedRAMP Moderate authorization or equivalency. "Zero persistence" is a good architecture, but it does not by itself get anyone out of that requirement. A gateway that cannot show you FedRAMP Moderate equivalency is asking you to extend your boundary to an unassessed system.

So ask. Consus is FedRAMP Equivalent: in October 2026 a 3PAO assessed us against all 410 FedRAMP High controls, well past the Moderate baseline the rule requires. We also hold a SOC 2 Type II, and submits an SPRS score of its own. Our SSP, POA&M, and architecture documentation are available to your assessor. If whoever you are evaluating cannot show you that, the in-your-tenant pitch is right about them. It is not right about us.

## When deploying into your own tenant is actually correct

I don't think the model is dumb for everyone. It is correct when:

- Your workload needs one vendor's models and you are fine never using the others.
- Your contract or program office explicitly requires inference to run in infrastructure you control. Some do. If yours does, the decision is made for you.

In that case the gateway in your tenant is a small addition to a system you already own. Go do it.

For everyone else, which in my experience is most contractors under a few hundred people, you are being offered a compliance project dressed up as a product.

## What the split looks like with Consus

Consus is a routing layer. We guarantee your request goes to the right provider, at the right compliance level, through authorized infrastructure, without persisting your prompts or completions along the way. We handle routing, isolation, encryption, FIPS endpoints, key management, and the provider-side evidence.

We also enforce where requests are allowed to go. You set an org-wide ceiling by compliance level or by model, map your identity provider's groups to policies, and no key can call anything outside them. A key capped at ITAR cannot reach a non-ITAR model, whatever the user sends.

What we do not do is read prompt content. Data classification and DLP stay in your own application layer, where your assessor expects to find them. That is a deliberate line, and it keeps your assessment story simple.

## Try it before you believe any of this

Request a key. Once it is approved, point your OpenAI or Anthropic client at `api.consus.io` and run a real request through an ITAR path in five minutes. Then hand our evidence package to your assessor and ask them which architecture they would rather sign off on.

[Book an intro call](https://cal.com/emagliarditi/consus-gateway-intro-discussion).