A private AI deployment for an unclassified public-sector sensitive workload is defensible when seven control categories are in place and can be shown, not just described: tenant or environment isolation, a documented data boundary, identity and access control scoped to the workflow, explicit tool and action permissions, attributable logging, model and supply-chain provenance, and a tested kill-switch tied to a change-review cadence. Choosing to build private is a decision. These controls are the evidence that the decision was real.
This guide picks up after the boundary decision has already been made. If a program has decided a workflow needs a stronger private boundary, the next question is what that boundary actually has to contain. Too many federal AI builds treat “private” as the finish line. It is closer to a starting requirement: private infrastructure without the controls below is just an unmonitored version of the same risk the program was trying to avoid.
Why “private” alone does not satisfy security or acquisition
A private deployment answers “where does this run.” It does not answer “who can reach it,” “what can it do,” “what happens when something goes wrong,” or “how do we know any of that is still true next quarter.” Security reviewers, acquisition leads, and program oversight tend to ask those questions in roughly that order, and a program that can only answer the first one is going to spend the review cycle explaining infrastructure instead of demonstrating control.
That gap is where most private AI builds lose credibility. The fix is not more infrastructure. It is a control architecture that maps to what the workflow actually does.
The seven control categories a defensible build needs
| Control category | What it has to show | Common failure mode |
|---|---|---|
| Tenant / environment isolation | The workload runs in a boundary not shared with unrelated tenants or workloads | “Private” marketing language over a multi-tenant SaaS backend |
| Data boundary and residency | Where data lives, what leaves the boundary, and under what condition | No documented answer beyond “it’s in our cloud” |
| Identity and access control | Who and what can reach the system, scoped to role and need | Broad service accounts with standing access nobody reviews |
| Tool and action permissioning | What the AI can do on its own versus what requires approval | Tool access granted by default instead of by workflow |
| Attributable logging | Prompts, outputs, tool calls, and approvals tied to an identity and a timestamp | Logs that exist but cannot be attributed or queried under review |
| Model and supply-chain provenance | Which model, which version, which upstream dependencies, and how changes are reviewed | No record of what changed when the vendor pushed an update |
| Kill-switch and change-review cadence | A tested way to halt the system and a schedule for revisiting the boundary | A theoretical kill-switch nobody has exercised |
Each row is a control a program should be able to demonstrate on request, not a policy statement filed and forgotten. The rest of this guide walks through what “demonstrate” means for the categories that generate the most review friction.
Tenant isolation and the data boundary
Isolation is not binary. A dedicated tenant inside a shared cloud region is a different boundary than an air-gapped deployment, and both can be legitimate depending on the workload. What matters is that the program can state, specifically, what is isolated from what: compute, storage, the document corpus the AI retrieves from, and the network path data takes to reach the model.
The data boundary question that actually gets asked in review is narrower than “is it private”: it is “what leaves this boundary, to where, and under what condition.” A workload that never sends data to an external inference endpoint has a simple answer. A workload that calls an external model API, even a reputable one, needs to document that call as a boundary crossing and account for it in the control story, not quietly exclude it because the rest of the system is private.
Identity, access, and tool permissioning
Access control for an AI system has two layers that are easy to conflate: who can reach the system, and what the system itself is allowed to do once someone reaches it. Both need to be scoped to the workflow, not granted broadly because it was simpler to set up that way.
The tool layer is where public-sector reviewers focus hardest, because it is where an AI system stops being a drafting aid and starts being an actor. A workflow assistant that can only retrieve and summarize internal documents carries a different risk profile than one that can query a live system, generate an artifact that feeds procurement or operations, or take an action without a human in the loop. Programs that cannot name, specifically, what tools the AI can call and under what approval gate are the ones that struggle to answer the “what can this actually do” question when it comes up.
A workable pattern: enumerate every tool or system the AI can reach, assign each one an approval requirement (autonomous, human-reviewed, or blocked pending review), and revisit that list on the same cadence as the kill-switch review below. Treat new tool access as a change that requires the same review as a new deployment, not a configuration tweak.
Attributable logging as the evidence layer
Logging that exists is not the same as logging that is useful under review. A defensible logging model attributes every prompt, output, tool call, and approval to an identity and a timestamp, retains it long enough to matter for the program’s audit cycle, and can be queried without engineering support standing between the reviewer and the answer.
This is the layer that turns “we have a private AI system” into “we can show what it did.” Programs that skip this step usually discover the gap the same way: a security or oversight review asks what left the environment on a specific date, and the honest answer is that nobody can produce it quickly. That is an evidence gap, not a technology gap, and it is the cheapest of the seven categories to close before it becomes a finding.
Model and supply-chain provenance
A private deployment does not eliminate supply-chain risk; it narrows the number of places that risk can hide and makes it inspectable. The program still depends on a model provider, likely an orchestration layer, a tool or plugin surface, and whatever document corpus the system retrieves from. Each of those is a dependency that can change without the program’s direct action.
The control that matters here is change review: does the program know when the underlying model version changes, when an orchestration dependency updates, or when the document corpus is refreshed, and does someone with authority sign off before that change reaches production. A private boundary that silently absorbs vendor changes has the same blind spot as a vendor path, just with better real estate.
The kill-switch and the review cadence
A kill-switch that has never been exercised is a documentation artifact, not a control. The practical version is a tested, timed procedure for halting the system, degrading it to a safe state, or cutting a specific tool or data path without taking down unrelated functions. It should be rehearsed on a schedule, not written once and assumed to work.
Pair the kill-switch with a standing review cadence for the whole control set: tenant isolation, data boundary, access grants, tool permissions, logging coverage, and supply-chain changes. Quarterly is a reasonable default for a program supporting an active mission workflow. The review does not need to be elaborate. It needs to happen on a schedule the program can point to when asked.
What “CMMC-aware” and “FedRAMP-aware” actually mean here
Vendors describing a private AI build sometimes let “CMMC-aware” or “FedRAMP-aware” language drift into implying a completed certification. That distinction matters and should not get blurred in a program’s own documentation. CMMC-aware delivery means the control architecture and practices are built to map cleanly to CMMC Level 2 expectations and can support a self-assessment or future certification effort. FedRAMP-aware means the same relationship to FedRAMP control families. Neither is a substitute for the formal authorization process, and a program should be explicit with its own oversight about which posture it currently holds.
What this guide is / What it is not
What it is: a practical control checklist for a private AI deployment supporting an unclassified, sensitive public-sector workload, covering isolation, access, logging, provenance, and kill-switch readiness. What it is not: legal or compliance advice, a certification, or a guarantee of any security authorization, audit, or examination outcome. DSE helps programs build and document these controls and prepares the evidence a review will ask for. We do not certify systems and do not guarantee any authorization or audit result.
FAQ
Does a private AI deployment eliminate supply-chain risk for a federal program?
No. A private deployment narrows where supply-chain risk can hide and makes it more inspectable, but the program still depends on a model provider, an orchestration layer, and often a document corpus and plugin surface it does not fully control. The control that matters is change review: knowing when a dependency changes and requiring sign-off before that change reaches production.
What is the difference between CMMC-aware and CMMC certified?
CMMC-aware delivery means the control architecture and practices are built to map cleanly to CMMC Level 2 expectations and can support a self-assessment or future certification effort. It is not a completed certification. Programs and vendors should keep that distinction explicit rather than letting the language imply an authorization that has not happened.
How often should a program review its private AI control set?
Quarterly is a reasonable default for a program supporting an active mission workflow, covering tenant isolation, data boundary, access grants, tool permissions, logging coverage, and supply-chain changes. The review does not need to be elaborate, but it needs to happen on a schedule the program can point to when asked.
What makes AI system logging useful under a security review instead of just present?
Logging is useful under review when every prompt, output, tool call, and approval is attributed to an identity and timestamp, retained long enough to matter for the program’s audit cycle, and queryable without engineering support standing between the reviewer and the answer. Logs that exist but cannot be attributed or queried on demand do not satisfy a review, even if the volume looks complete.
Does an isolated tenant automatically satisfy the data boundary requirement?
No. Tenant isolation and the data boundary are related but separate controls. A program also has to document what leaves the boundary, to where, and under what condition, including any call to an external inference endpoint. A workload that never calls an external model has a simple answer; one that does needs to account for that call as a boundary crossing, not exclude it because the rest of the system is private.
DSE’s federal AI governance path helps unclassified public-sector programs build the control architecture behind a private AI boundary: tenant isolation, access and tool permissioning, attributable logging, supply-chain provenance, and a tested kill-switch, mapped to NIST AI RMF and delivered CMMC-aware. Read when federal AI needs a stronger private boundary for the decision that comes before this checklist. Scope the engagement →
Key facts
- A defensible private AI deployment for unclassified public-sector sensitive workloads needs seven control categories: tenant isolation, data boundary, identity and access, tool permissioning, attributable logging, supply-chain provenance, and a tested kill-switch (DSE, 2026).
- CMMC-aware and FedRAMP-aware delivery describe posture and control mapping during a build, not a completed certification; a program should never accept vendor language that blurs that line (DSE, 2026).