Redaction for Government and Federal Workloads: FedRAMP, CMMC, ITAR, and the Air-Gap Imperative
Government workloads have the strictest data-handling requirements of any sector in the West — and the smallest population of commercial tools that genuinely qualify. Most PII redaction products marketed to "enterprise" customers fail at the first authorization step because the underlying architecture assumes a hosted SaaS data path. Federal contractors quickly discover that "we redact your PII for you" means "we move your CUI to our infrastructure first," which is the opposite of what FedRAMP, CMMC, ITAR, and the rest of the federal compliance stack require.
This post walks through how Philter and the rest of the Philterd toolkit map onto federal compliance frameworks — not because we have a FedRAMP authorization (we don't directly; the architecture is what matters), but because the open source, self-hosted, air-gap-capable design is precisely the shape of tool that federal compliance frameworks were written for.
The frameworks that matter
Five frameworks dominate federal data handling, and most contracts involve at least two of them:
- FedRAMP. The Federal Risk and Authorization Management Program governs cloud services used by federal agencies. Three impact levels (Low, Moderate, High) with progressively stricter controls. Hosted SaaS products need FedRAMP authorization to be used by agencies at all; tools deployed inside an already-authorized environment (an agency's own AWS GovCloud account, for example) inherit the authorization of that environment.
- CMMC (Cybersecurity Maturity Model Certification). Defense Industrial Base contractors handling Controlled Unclassified Information (CUI) need CMMC Level 2 (110 security controls from NIST SP 800-171); contractors handling Federal Contract Information (FCI) need at least Level 1. As of 2025, CMMC 2.0 is rolling into DoD contracts with explicit cybersecurity requirements that flow down to subcontractors.
- ITAR / EAR. Export-controlled technical data (defense articles for ITAR, dual-use for EAR) is subject to U.S.-person-only access restrictions. Any technology that processes ITAR data has to ensure foreign-national personnel can't read it — including any cloud provider's support staff outside the U.S.
- FISMA and DFARS clause 252.204-7012. FISMA governs federal information systems; DFARS imposes the NIST SP 800-171 controls on defense contractors handling CUI.
- The Privacy Act of 1974. Governs PII in federal systems of records. Less stringent than HIPAA in detail, but every federal agency operates under it.
Two things to notice about this list: (1) the requirements layer rather than substitute — a defense contractor often handles ITAR-controlled data and CUI and personal information and classified material in adjacent systems; and (2) the controls focus heavily on where the data is, not just what is done with it. A tool that does great redaction but sends the data to a non-FedRAMP-authorized SaaS for processing is disqualified before its accuracy is even evaluated.
Why most commercial PII tools don't qualify
Walk through the typical commercial PII redaction product:
- SaaS API path. Sends text to the vendor's cloud for processing. Outside the agency's authorization boundary. Disqualified for any moderate-or-higher FedRAMP workload.
- Proprietary models. Black-box NLP that can't be audited. Doesn't satisfy CMMC's "Limit information system access to authorized users" if you can't even see what the system is doing.
- Phone-home telemetry. Even self-hosted commercial tools often check in with the vendor for license validation, model updates, or anonymous usage stats. Any outbound network call from a CUI enclave is an authorization-boundary violation.
- Foreign-national support staff. If the vendor's support team includes non-U.S.-persons with access to deployed instances (even rarely, for troubleshooting), ITAR-controlled workloads are off the table.
- Air-gap incompatibility. Many "self-hosted" tools assume internet access for container pulls, model downloads, or license servers. A truly disconnected deployment exposes these assumptions immediately.
None of these are insurmountable engineering problems, but they're features that have to be designed in from the start. Bolting them on after the fact rarely passes a serious assessment.
What the architecture actually needs
The federal-compliance-friendly architecture has five properties:
- Self-contained deployment. Container images with every dependency bundled. No registry pulls at runtime. No "Docker Hub will be available" assumption.
- Local model repositories. NLP and AI models loaded from local storage, not fetched from a model hub. No outbound calls for inference.
- Zero phone-home. No telemetry, no license check, no anonymous usage data. The deployed binary makes zero network calls outside the explicitly-configured downstream services.
- Auditable source. Open source code that a security team can read, audit, and verify against the running binary. "Trust me" doesn't pass a 800-171 assessment.
- Air-gap-capable. Operational in a completely disconnected environment. No assumed internet at any phase of installation, upgrade, or steady-state operation.
These properties are what "Deploying Philter in Air-Gapped Environments" walks through in detail. The same architecture that enables defense and intelligence deployments is precisely the architecture that satisfies CMMC and FedRAMP-inheriting deployments — the federal compliance frameworks were written for software that behaves the way Philter behaves by design.
FedRAMP via inheritance
The cleanest path to FedRAMP-eligible use isn't usually for the redaction tool itself to be FedRAMP-authorized — it's for the tool to be deployed inside an environment that already is. AWS GovCloud (Moderate or High), Azure Government, and Google Distributed Cloud Hosted are all FedRAMP-authorized environments. Software deployed inside those boundaries inherits the authorization for the deployed instance (subject to the agency's own ATO process for the system as a whole).
Philter ships container images that run unchanged in any of those environments. The agency or contractor's existing FedRAMP authorization covers the runtime; the open source nature of the code lets their security team complete whatever supply-chain analysis their ATO requires.
CMMC alignment: the relevant controls
CMMC 2.0 Level 2 includes 110 controls drawn from NIST SP 800-171. A subset are directly relevant to how a PII redaction tool gets deployed; Philter's architecture aligns naturally:
- AC.L2-3.1.1 (Limit access to authorized users). Self-hosted deployment with the customer's own IAM controlling access. No vendor-side accounts.
- AC.L2-3.1.3 (Control CUI flow). No outbound data flow; the redacted CUI never leaves the boundary.
- AU.L2-3.3.1 (Create and retain system audit logs). Detection logs from Philter feed into the customer's SIEM (Splunk, OpenSearch, etc.) for retention per agency policy.
- CM.L2-3.4.1 (Establish baseline configurations). Open source policies as configuration; version-controlled, reproducible, auditable.
- RA.L2-3.11.2 (Scan for vulnerabilities). Container images can be scanned by the customer's vulnerability scanner before deployment; the bundled dependencies are explicit and inspectable.
- SC.L2-3.13.6 (Deny network communications by default). Philter operates correctly in deployments with deny-by-default outbound rules — in fact, we recommend it.
The point isn't that Philter "satisfies" CMMC by itself — CMMC compliance is a property of the whole system, not any single tool. The point is that Philter doesn't introduce control failures the way commercial alternatives do.
ITAR and foreign-national access
ITAR's U.S.-person-only access restrictions are where commercial SaaS gets eliminated quickly. If your tool requires occasional vendor support — even read-only, even rare — the support staff has to be all-U.S.-persons. Few SaaS vendors can credibly commit to that.
The self-hosted, open-source path sidesteps this entirely. There is no vendor-side support staff with deployment access. Code-level support (which doesn't require touching customer data) happens against the open source repository. ITAR-controlled deployments can operate with zero non-U.S.-person involvement in either steady-state operations or break-fix scenarios.
Federal workflows
Three patterns where federal agencies and defense contractors typically apply PII redaction:
- FOIA response preparation. Records released under the Freedom of Information Act have to be reviewed for exempt content — personal information (Exemption 6), law-enforcement records (Exemption 7), classified material (Exemption 1), and others. Automated pre-redaction massively reduces the human review time per request without removing the human judgment for borderline cases.
- CUI handling in unclassified-but-controlled systems. Defense contractors process CUI across email, document collaboration platforms, ticket systems, and ML training datasets. Redaction at the boundary between CUI systems and adjacent less-restricted systems keeps the CUI scope as narrow as possible (and keeps the CMMC certification scope manageable).
- Cross-domain information transfer. Moving information between security domains (classified to unclassified, ITAR to non-ITAR) requires reviewer attestation that no controlled content traverses. Automated pre-screening flags candidates for review and produces the audit trail.
The bottom line
Federal data handling is the case where "self-hosted, open source, no phone-home" stops being a marketing differentiator and becomes a hard architectural requirement. Tools built around SaaS data paths can't qualify regardless of how good their detection is; tools built around the federal-architecture pattern can support agencies and defense contractors in deployments where almost nothing else qualifies.
The same Philter that runs in a healthcare data lake runs in an AWS GovCloud isolated region or a defense contractor's on-prem cluster — same code, same policy format, different deployment posture. Pair it with the air-gapped deployment pattern and the toolkit covers everything from "FedRAMP-inheriting deployment in GovCloud" to "completely disconnected SCIF-grade environment."
If you're working a federal or defense contract that needs PII or CUI redaction and the architectural constraints have eliminated the commercial options, get in touch. The deployment patterns are well-documented; the policy work to match the specific data flows is where we typically focus engagement time.