AI Security and Compliance in Government Projects: A Practical Guide for 2026

AI security and compliance in government projects comes down to one engineering question: can the system prove that every person, service and AI agent only touched the data and actions they were allowed to? Frameworks such as FISMA, NIST SP 800-53, FedRAMP, GovRAMP and the NIST AI Risk Management Framework set the expectations. The architecture is what meets them.

This guide is written for state and local agency IT leaders, federal program and security teams, civic tech organizations, and government contractors. It covers the rules that changed in 2026, a reference architecture, secure RAG, AI agent controls, accessibility, and a rollout plan that starts with one service.

TL;DR

• Enforce access before data reaches the model. Filtering an AI answer afterwards is not access control.
• A FedRAMP- or GovRAMP-certified cloud does not make your application compliant. Your system still needs its own review.
• FedRAMP moved to the Consolidated Rules for 2026 and the 20x “Certification” model. FIPS 140-2 modules went to the Historical list after September 21, 2026.
• State and local projects usually mean GovRAMP (formerly StateRAMP), state AI laws, and ADA Title II accessibility (deadline now April 26, 2027 for larger entities).
• AI agents get their own narrow identities, backend-checked permissions, and human approval for consequential actions.
• Start with one service, one case type and one staff queue. Expand after the pilot proves it.

Why AI security is different in government

Government AI handles information where a mistake affects people’s rights, benefits, safety or legal status, not just a customer’s preferences. One platform may hold public records, resident PII, tax and benefits data, case files and Controlled Unclassified Information side by side.

AI also adds attack surfaces that a normal web app doesn’t have. The most common in government settings are:

• Indirect prompt injection. A hidden instruction inside an uploaded or retrieved document tries to make the assistant leak data or call a tool.
• Over-permissioned agents. An agent with a broad service account can do far more than the task needs.
• Unauthorized retrieval. A shared vector index returns another department’s records.
• Data poisoning and supply-chain risk in datasets, models, packages and third-party APIs.
• Sensitive data in logs. Full prompts and responses become a new, unprotected copy of resident data.

Public accountability raises the bar further. THE TISA’s own GovTech practice takes a clear position: AI can check completeness, extract document data and flag issues, but determinations that grant or deny benefits stay with authorized staff, with reasons recorded for notices and appeals.

The 2026 regulatory landscape

No single framework makes an AI system compliant. What applies depends on the agency, data type, system categorization, hosting, contract terms and state law. Map these before you choose a cloud or a model.

Federal frameworks at a glance

FISMA and NIST SP 800-53 in practice

For a federal AI-enabled system, the path is familiar: categorize the system, select a control baseline, implement and document controls, assess them, get an authorization to operate (ATO), then monitor continuously. The AI parts don’t skip any step. They add evidence: model and prompt versions, retrieval permissions, agent tool scopes and evaluation results.

FedRAMP 20x and the Consolidated Rules for 2026

FedRAMP launched its Consolidated Rules for 2026 (CR26) in late June 2026 (FedRAMP announcement). Optional early adoption began July 4, 2026, and the rules become mandatory for all stakeholders on January 1, 2027 (official timeline). Four changes matter to AI teams:

1. New vocabulary. FedRAMP now issues Certifications in Classes A–D. Class C is presumed adequate for most Low or Moderate agency systems, and some High systems with compensating controls (certification classes). FedRAMP stresses that a class describes how much assurance information the provider supplies. It is not a security rating and not a substitute for the agency’s own impact level.
2. New pipelines and deadlines. The 20x Class A pipeline opened August 3, 2026, and Class B and C opened August 31, 2026. FedRAMP Ready became legacy on July 28, 2026, and new Rev5 applications close on June 11, 2027. A Class D (High) pilot is estimated for FY27 Q1–Q2 (FedRAMP 20x).
3. Continuous, machine-readable evidence. 20x providers must keep their certification package current at least monthly for Class B, every 2 weeks for Class C and weekly for Class D. Every 3 months is recommended for Class A (package rules). That favors automated compliance pipelines.
4. The first certifications are out. FedRAMP granted the first 20x Class A certification on August 25, 2026, and the first full CR26-compliant 20x Class C certification on October 29, 2026 (FedRAMP, Nov 2, 2026).

Two rules have not changed. A certified cloud service does not certify the application you build on it. And the agency still categorizes its own system and decides whether its system may operate. In practice, if you sell an AI cloud service to federal agencies, design for continuously updated evidence from day one. If you build on a certified cloud, document exactly which controls you inherit and which you own.

NIST AI RMF

The AI RMF organizes AI risk work into four functions:

• Govern: owners, policies, accountability.
• Map: use case, users, data, affected residents, potential harms.
• Measure: accuracy, security, privacy, bias, reliability.
• Manage: mitigations, monitoring, incident response.

For generative AI, NIST AI 600-1 (July 2024) adds 12 risk categories, including confabulation, data privacy and information security. A document classifier, for example, should be measured on extraction accuracy and also on wrong-department exposure and the cost of a misclassification.

OMB M-25-21 and M-25-22

Both memos were issued April 3, 2025 (OMB memoranda index). M-25-21 covers how agencies govern AI use and manage high-impact AI. M-25-22 covers how agencies buy AI, including data ownership, portability, vendor lock-in and performance terms. A later memo, M-26-04 (Dec 11, 2025), sets unbiased-AI principles that agencies may apply to LLM purchases. For vendors, the practical result is that you should be ready to document intended use, data handling, model dependencies, evaluation results and exit terms.

State and local requirements

Most GovTech work happens at the state, county and city level, where the rules are different.

• GovRAMP (formerly StateRAMP). This is the cloud security verification program for state, local, tribal and education entities. It announced the GovRAMP name on February 14, 2025, but StateRAMP remains its legal name, so older contracts may use either (GovRAMP announcement). Verification is based on NIST SP 800-53 Rev. 5.
• State AI laws. These change every session. Track them with the NCSL AI legislation database, which NCSL updates monthly, and keep a jurisdiction-by-jurisdiction compliance matrix.
• ADA Title II web accessibility. DOJ’s interim final rule, effective April 20, 2026, moved compliance to April 26, 2027 for entities serving 50,000+ people. Smaller entities and special district governments now have until April 26, 2028 (Federal Register 2026-07663). The standard is still WCAG 2.1 AA.
• HHS Section 504. HHS also extended its parallel web accessibility rule for funding recipients. Recipients with 15+ employees must comply by May 11, 2027, and those with fewer than 15 by May 10, 2028 (Federal Register 2026-09266).
• Records retention and public records laws. AI logs, indexes and outputs may themselves be public records. Plan retention and export from day one.

A reference architecture for secure government AI

The core rule is simple: the model never decides who can see what. Trusted application services make every access decision before any content reaches the model’s context window.

Identity first, least privilege always

• A resident sees their own application, and nothing else.
• A caseworker sees cases assigned to their program and office.
• An administrator configures the system without automatically reading confidential records.
• An AI service gets its own identity, scoped to the single task it performs.

Use short-lived credentials, separate production permissions and periodic access reviews. When a team member rolls off, revoke access and rotate secrets.

Encryption and key management

• At rest: encrypt databases, object storage, backups, vector indexes and model artifacts (AES-256 where appropriate).
• In transit: TLS 1.2 or 1.3 everywhere, including internal service traffic. Use mutual TLS between services where it fits.
• Validated cryptography: FIPS 140-2 validations stayed active only until September 21, 2026. All remaining FIPS 140-2 certificates then moved to NIST’s Historical list (CMVP FIPS 140-3 transition). Historical modules can generally stay in existing systems. New systems that require validated cryptography should use modules with active FIPS 140-3 certificates. Check the actual module certificate, not the vendor’s marketing claim.
• Keys: document ownership, rotation, revocation and separation of duties. Customer-managed keys or BYOK/HYOK can strengthen control, but none of them automatically guarantees the provider can never reach plaintext. That depends on the implementation.
• Plan for post-quantum: OMB M-26-15 (June 24, 2026) directs federal migration to post-quantum cryptography. Keep cryptographic choices configurable rather than hard-coded.

Zero Trust

NIST SP 800-207 and the CISA Zero Trust Maturity Model v2.0 fit AI systems well. CISA’s model covers five pillars: identity, devices, networks, applications and workloads, and data. Every request is evaluated on identity, workload, device context and resource sensitivity, never on being “inside the network.”

Securing RAG and government knowledge bases

Retrieval-augmented generation (RAG) is the most useful AI pattern in government: policy assistants, caseworker knowledge tools, public information portals and procurement research. It is also where most unauthorized-access failures happen.

The failure in one example. Finance, Public Health and Legal share one AI assistant and one vector index. A finance analyst asks for “the latest internal investigation report.” Without permission-aware retrieval, the index returns a Legal record and the model summarizes it. That is an access-control breach, not a hallucination.

The secure RAG pipeline

1. Controlled ingestion. Accept files only from approved sources. Validate type, scan for malware, record the owner.
2. Classification. Tag each document with department, sensitivity, retention period and access list.
3. Permission-aware indexing. Store those tags with every chunk and embedding.
4. Identity-aware retrieval. Resolve the requesting user’s permissions first, then search only what they may see.
5. Context minimization. Send the model only the passages needed for the answer.
6. Model call through a gateway. Use approved model endpoints only, with logging and provider data settings enforced.
7. Citations. Return the source document for every answer so staff can verify it.
8. Audit and retention. Log retrieval events as metadata. When a source document is deleted, delete its chunks too.

Vector database protection

Embeddings are derived from sensitive documents, so don’t treat them as harmless. Require authentication on the vector store. Isolate departments or tenants. Encrypt storage. Restrict admin access. Monitor unusual query volumes. Make retention and deletion propagate from the source system.

THE TISA covers this pattern in depth in its Enterprise RAG implementation guide.

Securing AI agents and workflow automation

Agents don’t just answer questions. They act: search records, draft notices, create tasks and call APIs. That makes execution control the main security problem.

Essential agent controls

• Scoped tools. Expose only approved API operations, never raw database access.
• Backend authorization on every call. The model can request an action, but the application decides whether to allow it.
• Human approval before any consequential or irreversible step.
• Isolated execution for any tool that runs code or touches files.
• No secrets in prompts. Credentials live in a vault and are never placed in model context.
• Action logs recording who requested what, the authorization result and the outcome.
• Limits and kill switches: rate and spend caps, loop detection, one-click suspension and credential revocation.

Human-in-the-loop that actually works

The agent prepares a recommendation with evidence and citations. The application checks permissions. An authorized employee approves, edits or rejects it. Only then does the system execute and record the decision. A reviewer needs enough context, authority and time. An “Approve” button pressed 400 times a day is not oversight.

For more on agent architecture, see guides on agentic AI development and multi-agent systems.

AI threat modeling with MITRE ATLAS

Use MITRE ATLAS alongside your normal threat model to find AI-specific attack paths. Then turn each one into a test.

For each threat, record the component, impact, preventive and detective controls, test procedure, residual risk and owner. That record becomes compliance evidence.

Data sovereignty and where government data actually goes

“Hosted in the US” isn’t enough. Trace every hop a piece of resident data can take:

1. Where it’s collected
2. Where it’s stored (primary, backup, disaster recovery)
3. Where it’s processed, including model inference
4. Where logs and telemetry go
5. Which subprocessors touch it
6. Where administrators access it from
7. How long each copy is kept and how it is deleted

Choosing a deployment model

AI model provider checklist

Before choosing a model provider, confirm in the contract, not the marketing page:

• Input and output retention, and whether data is used for training
• Processing region and private networking options
• Encryption, key options and admin access controls
• Subprocessors and audit rights
• Model version change notice and deprecation terms
• Data deletion, export and portability (an OMB M-25-22 theme)

Design the model layer so it can be swapped. Prices, accuracy and terms change every quarter. THE TISA explains this approach in Vendor-Agnostic AI.

Accessibility and resident trust

A secure AI service that residents can’t use still fails. In government, accessibility is a legal requirement as well as a design goal.

• Standard: WCAG 2.1 AA for ADA Title II (state and local) and Section 508 (federal ICT), unless the contract specifies more.
• Design system: the U.S. Web Design System (USWDS) gives tested, accessible components.
• Identity: use Login.gov or the state identity provider the security team already accepts, not a new account system the agency can’t revoke. Federal agencies are being pushed toward Login.gov by OMB M-26-18 (Aug 31, 2026).
• AI-specific checks: chat and assistant interfaces must work with screen readers and the keyboard. Answers need plain language. There must always be a path to a human. AI-generated documents, alt text and PDFs need the same accessibility review as human-written ones.
• Testing: use automated tools (e.g., axe), keyboard-only runs and screen-reader sessions, and document conformance before release.
• Transparency: tell residents when they are interacting with AI, what it can and can’t do, and how to appeal a decision.

Continuous governance and compliance automation

Compliance is not a launch milestone. Models change, data drifts, permissions creep and new integrations appear. FedRAMP’s move toward continuous, machine-readable evidence reflects this.

Policy-as-code in the pipeline

Use tools such as Open Policy Agent to block a release when:

• A data store is public or unencrypted
• A secret appears in code
• An unapproved model endpoint or base image is used
• Required logging is off
• Prompt-injection, retrieval-authorization or data-leakage test suites fail

Legal review, bias assessment and high-impact use-case approval still need people. Automate the repeatable checks so reviewers have time for the judgment calls.

Audit logs without a new privacy problem

Log authentication, sensitive record access, retrieval events, model and prompt version changes, agent actions, approvals, failed authorization and data exports. Make logs tamper-evident. Federal teams should also check the logging and visibility expectations in OMB M-26-14 (May 22, 2026).

Don’t log full prompts and responses by default. Prefer event IDs, document references and hashes, and keep full-content logs only where policy requires them, with restricted access.

Monitor the AI, not just the servers

Track:

• Answer accuracy and citation quality
• Unauthorized retrieval attempts
• Prompt-injection indicators
• Unexpected tool calls
• Model drift and input quality
• Performance differences across resident groups where relevant
• Cost per task

Set thresholds per use case, and define what triggers rollback.

A 7-phase roadmap: start with one service

The safest first release is small: one service, one form or case type, and the staff queue that reviews it.

Seven mistakes that fail security reviews

1. “It’s on GovCloud, so it’s compliant.” The cloud’s certification doesn’t cover your application, models or integrations.
2. Giving agents admin credentials to save integration time.
3. Treating prompt filters as the security boundary. Authorization belongs in the backend.
4. One shared vector index with no document-level permissions.
5. Logging every conversation in full, which creates a second unprotected copy of resident data.
6. No version history for models, prompts and datasets, so you can’t explain last month’s bad answer.
7. Ignoring accessibility until the end, when fixing forms and chat UIs costs the most.

What this looks like in practice

A county wants to cut processing time for a benefits-related application.

1. A resident applies through an accessible, USWDS-based portal and signs in with the state identity provider. They can save and resume, and upload documents.
2. An AI step checks the application for completeness and extracts fields from the uploaded documents. It asks the resident for missing items automatically.
3. The complete case is routed to the right program queue. The caseworker’s view shows AI-extracted data with citations to the source documents.
4. A RAG assistant answers the caseworker’s policy questions, retrieving only policies and records their role permits.
5. An agent drafts the notice. The caseworker records the determination and the reasons, and approves the notice. The AI never decides eligibility.
6. A legacy adapter writes the result to the existing system of record. Every view, change, retrieval and approval is logged.

First-hand evidence from THE TISA’s own projects (education and SaaS, not government):

• OpsPilot. THE TISA integrated OpenAI report summaries into an enterprise administration platform. The platform manages 6,400+ student records for 2,850 monthly active users, with application context and controlled access to enterprise data.
• Clove. An AI project-management SaaS uses the OpenAI API to draft milestones, sprints and task assignments. A manager reviews and approves them before anything is assigned, the same human-in-the-loop pattern this guide recommends.

The same permission-aware access, controlled data scope and review-before-action patterns carry over directly to public-sector workflows.

How THE TISA builds secure AI for government

THE TISA is an AI software development and product engineering company. Its AI team (agents, RAG, automation) and its product engineering team (portals, case management, APIs) scope projects together. That way, the permission model and audit trail the AI needs exist in the application from the start.

What that means for a public-sector engagement:

• Architecture written down before code. You can challenge it while changes are still cheap (our process).
• Evaluation against a scored dataset built from your real cases. You see accuracy, latency and cost per task before go-live.
• Deployment behind approval gates, with monitoring and a rollback path.
• A swappable model layer, benchmarked on your data rather than tied to one vendor.
• Your environment, your keys. We can build in agency-owned cloud accounts, on certified services where the contract requires them, with named accounts, scoped access and documented offboarding (security approach).
• GovTech building blocks: USWDS interfaces, Login.gov or state identity, Section 508 / WCAG testing, and legacy-system adapters (Government & Public Services).
• Clear ownership. The agency owns its data and, as agreed in the contract, the code. Handover documentation is written so you could replace us.

Relevant services: AI Integration Services · RAG Development · AI Agent Development · AI Workflow Automation · Case studies

THE TISA builds software and engineering controls that support the requirements defined for each engagement. Formal FedRAMP or GovRAMP certification, agency ATOs and independent assessments are separate processes involving the agency and qualified assessors. Procurement routes vary: we can confirm whether we contract directly, as a subcontractor or through another vehicle.

What’s next for government AI security

• Agentic AI will need workload identities, per-action authorization and execution isolation as standard.
• Automated compliance evidence will become the default, following FedRAMP 20x’s lead.
• AI supply-chain inventories (models, datasets, prompts) will sit next to the SBOM.
• Continuous evaluation will replace one-time model validation.
• Interoperability and portability will increasingly be written into AI contracts.

Conclusion

Secure, compliant government AI is an architecture problem before it’s a paperwork problem. Enforce identity before retrieval. Give agents narrow, audited powers. Keep consequential decisions with people. Make the service accessible. Treat compliance as continuous evidence.

Whether you’re a county modernizing one permit workflow or a contractor preparing a FedRAMP 20x submission, the right engineering choices up front decide whether a pilot reaches production.

Frequently Asked Questions

Q1. What security standards apply to AI projects in the US government?
Ans. It depends on the agency, data and hosting. Federal systems typically involve FISMA, NIST SP 800-53, FedRAMP for cloud services, FIPS 140-3 for validated cryptography, and the NIST AI RMF. State and local projects often involve GovRAMP, state AI and privacy laws, records rules and ADA Title II accessibility. Contracts add their own requirements.

Q2. Is FedRAMP required for every government AI application?
Ans. No. FedRAMP covers cloud services used by federal agencies. State and local agencies more often use GovRAMP or their own programs. Running on a certified cloud also doesn’t certify the application built on top of it.

Q3. What changed with FedRAMP 20x in 2026?
Ans. FedRAMP launched the Consolidated Rules for 2026 in late June 2026. Optional adoption began July 4, 2026, and the rules became mandatory on January 1, 2027. FedRAMP now issues Certifications in Classes A–D instead of the old authorization labels, and the 20x pipelines opened in August 2026. The first full CR26-compliant 20x Class C certification was granted October 29, 2026. New Rev5 applications close June 11, 2027.

Q4. What is GovRAMP, and is it the same as StateRAMP?
Ans. Yes. StateRAMP began operating as GovRAMP in February 2025 to reflect its state, local, tribal and education members. StateRAMP remains the legal name, so older documents may use either name.

Q5. What happened to FIPS 140-2 in 2026?
Ans. After September 21, 2026, all FIPS 140-2 certificates moved to NIST’s Historical list. Historical modules can generally remain in existing systems. New systems that require validated cryptography should use modules with active FIPS 140-3 certificates.

Q6. When must state and local government websites meet ADA Title II accessibility rules?
Ans. DOJ’s April 2026 interim final rule extended the deadline to April 26, 2027 for entities serving 50,000 or more people. Smaller entities and special district governments have until April 26, 2028. HHS separately extended its Section 504 web rule for funding recipients to May 11, 2027 (15+ employees) and May 10, 2028 (fewer than 15). The technical standard remains WCAG 2.1 AA.

Q7. How do you stop a government RAG assistant from leaking restricted documents?
Ans. Resolve the user’s permissions before retrieval, and store access metadata with every chunk. Isolate departments in the vector store. Send only the minimum context to the model. Filtering the answer after generation is not a substitute.

Q8. How should AI agents be secured in government workflows?
Ans. Give each agent its own narrow identity and only approved tools. Check every action in the backend. Require human approval for consequential steps, and log each request, decision and outcome.

Q9. Can AI decide eligibility for public benefits?
Ans. It shouldn’t make final determinations. AI can check completeness, extract document data and flag issues. Determinations that affect benefits or rights should be made by authorized staff, with reasons recorded for notices and appeals.

Q10. What do OMB M-25-21 and M-25-22 mean for AI vendors?
Ans. M-25-21 governs how federal agencies use and oversee AI. M-25-22 governs how they buy it. Vendors should expect questions on intended use, data ownership and portability, model dependencies, evaluation results and exit terms.

Q11. Does THE TISA build AI software for government agencies?
Ans. THE TISA builds AI-enabled public-service software: accessible resident portals, case management, RAG knowledge assistants, AI agents and legacy integrations. It focuses on state and local agencies, civic tech organizations and government contractors. Hosting, security controls, procurement route and compliance responsibilities are scoped for each engagement. Certifications and ATOs are confirmed separately.