FedRAMP and GovRAMP: Evidence as a Command

Contents9 sections

Building to FedRAMP and GovRAMP with an AI workflow

FedRAMP and GovRAMP decide whether government can buy your software. Both judge how you build and test it, as well as what it does. We built those rules into an AI development workflow. Every change our agents make is built and tested inside a boundary we control and leaves a record; the evidence is a command anyone can run.

What FedRAMP and GovRAMP are

Both are security authorizations for cloud software sold to government. FedRAMP covers federal agencies; GovRAMP covers states, local governments and other public bodies, schools among them. Each certifies that a named system, inside a stated boundary, meets a fixed set of security controls and keeps meeting them; a product's features sit outside what either one checks.

Table 1. FedRAMP and GovRAMP side by side.

NIST SP 800-53, the control catalog the National Institute of Standards and Technology publishes, is the shared language. It's a list of security and privacy controls (access control, configuration management, supply chain, testing, audit); each baseline selects from it. FedRAMP is also moving to a faster track, FedRAMP 20x, with automated checks built on evidence — the FedRAMP Marketplace lists 20x certifications beside the classic ones.

Why they matter, and when they are required

An authorization is a condition of sale. A federal agency may not put its data in a cloud service that lacks a FedRAMP authorization at the right level. A growing number of states write GovRAMP, or its equivalent, into their contracts. Without the authorization the deal doesn't happen, however good the software is.

• When it's required. FedRAMP applies when a cloud service stores, processes or transmits unclassified federal information for an agency. GovRAMP applies when a participating state or local government requires it of its vendors.
• The level follows the data. Low covers public or low-risk data, Moderate covers most government systems; High covers law enforcement and emergency services, and financial or health data whose loss would be severe.
• Health care sits close to High. Systems for patient records, for benefits and for public health hold data whose disclosure harms people. They draw Moderate or High baselines on top of HIPAA, the federal health privacy law.

The reason behind them is the supply chain. An attacker who changes how software is built reaches every customer at once, so the frameworks look past the running product to who can change the code, where it's built and tested, what it depends on, and whether the release that ships is the one that was tested. In an AI workflow the agents write and test the code, so they and the machines they use are part of the system being authorized.

What they ask of building and testing

The build pipeline must sit inside a boundary the provider controls, or every outside service in it must be named and justified. It must also leave evidence an assessor can check. These are the NIST SP 800-53 controls that land on it, with the ISO/IEC 27001:2022 clauses we tracked beside them (ISO 27001 is the international standard for an information security management system).

Table 2. The controls that land on a build pipeline.

How we built it into an AI workflow

Our software is written mostly by AI agents: Claude Code sessions, with Codex, Gemini and Copilot as reviewers. Muther, a desktop app that runs the Collective's build and test machines, coordinates them. Compliance went in at the start. It's part of the rules every agent reads before it writes a line, and part of the machinery that runs each build.

1. Rules every agent reads first. Each repository has one entry file (AGENTS.md) that every agent loads, pointing to binding rules, a ship checklist and a ledger of failures already paid for. An agent that skips a step is caught by the checks. The class of mistake goes into the ledger so it isn't repeated.
2. Tests and checks run on machines we control. Every pull request is tested on self-hosted runners on the Collective's PC rather than a shared cloud; jobs that need a secret never run there.
3. Builds inside the boundary, in Docker. Release installers are built on the PC in a single-use container. It has a pinned base image, a cap on cores and memory, no capabilities, no secrets, and the source as a read-only snapshot of the exact commit. Muther builds her own releases this way and builds MAX4's in a second container; MAX4's own build lane takes over only if she doesn't answer.
4. Evidence as a command. compliance-check prints one line per control (actions pinned to commit hashes, least-privilege tokens, lockfile-only installs, the dependency audit, release integrity) and fails the build on any gap. Every release carries a CycloneDX software bill of materials (SBOM) and a manifest naming where it was built, the tool versions and the lockfile hash.
5. Nothing merges red, nothing ships vulnerable. Continuous integration (CI) fails on any high or critical dependency advisory; the AI releases only what passed CI on the main branch.
6. Visible and audited. Each build container is labelled with what it builds and who started it, shown on Muther's runners display, and every start and stop, and every clean-up, goes to an audit log. Each entry says how to undo it.

The build in Docker (step 5 in the figure) is what moved building inside the Collective's boundary. Every other step was already local or hosted by GitHub, which stays a named outside service.

What is proven today, and what is still open

The build and test side is in place and checked by command. No authorization has been sought yet, because the product isn't offered to an agency; we assume the Moderate baseline.

Table 3. Where each control stands on 25 October 2026.

The bar stayed where it was, and the evidence grew: each agent leaves a pull request, a test run and an audit line. The same check an assessor would run is the one that blocks a bad merge.

Why this has to continue: MARA

This work is the ground floor for MARA, the Medical Agentic Resident Assistant. MARA is meant to hold one patient's whole record, across a lifetime, for every role in their care. The patient, providers, imaging, the lab, pharmacy, treatment teams, the payer and billing each read and add to the same story, instead of rebuilding it from scattered charts. She learns from outcomes, across a person and across similar patients. Every recommendation she makes comes with its reason, and a person makes the decision.

For a clinic, that means the facts from one visit are there at the next, a patient isn't asked for the same history at every handoff, and a warning can come from what happened to patients like this one. A system trusted with that has to meet HIPAA. Wherever public health and government programs depend on it, it has to meet FedRAMP or GovRAMP too. So these controls carry forward. MAX4, the generation before her, already builds and tests to them — the security and regulatory evidence MARA needs exists before any patient depends on her.

Sources

• FedRAMP: the program site and Marketplace, including FedRAMP 20x (read 25 Oct 2026).
  • fedramp.gov
• FedRAMP Codified: a new law aims to streamline federal security authorizations, Davis Wright Tremaine, Jan 2023: the 2022 Act, the presumption of adequacy, the 2011 OMB start.
  • dwt.com · fedramp authorization cloud services
• FedRAMP Revision 5 explained, Cloud Security Alliance, 14 Jul 2023: baseline control counts.
  • cloudsecurityalliance.org · fedramp revision 5 explained
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations.
  • csrc.nist.gov · final
• StateRAMP is now GovRAMP, Government Technology, 14 Feb 2025.
  • govtech.com · stateramp is now govramp reflecting broader participation
• Our own record: docs/COMPLIANCE.md and scripts/compliance-check.mjs (AlienInterface), docs/compliance/BUILD_AND_TEST_FROM_MUTHER.md and docs/reference/architecture/Building_MARA.md (MAX4).

Glossary