Running a Digital Workforce Under FedRAMP: A Practical Guide for 2026 :

What changed in FedRAMP

Three changes matter most for anyone planning AI agents in federal work. First, OMB memo M-24-15, issued in July 2024, reshaped the program around agency and multi-agency authorizations with a FedRAMP Board, rather than the old Joint Authorization Board path. Second, FedRAMP 20x, a new approach that relies more on automated validation, moved through a Low pilot in 2025 and a Moderate pilot that issued its first certifications in March 2026. FedRAMP says 20x is now in its third phase, and it has said it will stop accepting new Rev5 certifications on June 11, 2027. Third, in 2026 FedRAMP renamed its authorizations to FedRAMP Certifications and replaced impact levels with Classes A through D. Class B covers the former Low and Li-SaaS baselines, Class C the former Moderate baseline, and Class D the former High baseline. Class A is a new pilot baseline. Rules and names are still settling, so check fedramp.gov before you plan against any date.

Two different questions

Leaders tend to mix up two questions. The first is whether an agency or contractor can use AI agents on federal data. That depends on whether every service the agents touch, including the model, is certified at the right class and approved for use by the agency. The second is whether a software company can sell a product with agents in it to agencies. That depends on the product itself being certified, with the agents inside the assessed boundary. The work is different, and so is who carries it.

If you are putting agents to work on federal data

Most agency and contractor teams will build agents on top of services that are already certified. The rules for the digital workforce are practical.

• Check the FedRAMP Marketplace for every service the agents use, including the model provider, and confirm its class covers your data.
• Keep the agents' tools inside the boundary. An agent that calls an uncertified web service, plug-in, or model is an easy way for data to leave the boundary.
• Record each agent in the system's documentation: its job, identity, permissions, tools, and approval rules. Agents are components, not features.
• Treat changes to instructions, tools, and models as configuration changes. Some will need your agency's change process before release.
• Confirm the agency's authority to operate covers the new use. A certified cloud service does not by itself approve every use of it.

If your product includes agents

For a software company, agents are part of the cloud service offering. The assessment will look at them the way it looks at any other component, and a few points deserve early attention.

• Decide where the model runs. If it comes from an outside provider, that provider's service must meet the requirements for your class, and the data flow must be documented.
• Design agent identity and logging before the assessment, not during it. Retrofitting per-agent identity into a shared service account is slow.
• Plan for model updates. When a provider retires a model, the switch is a change to the certified system and needs testing and documentation.
• Watch the NIST work on AI overlays. NIST is developing control overlays for securing AI systems under SP 800-53, called COSAiS. As of its last update they were outlines, not requirements.

Where human approval fits

Nothing in FedRAMP requires a person to approve every agent action, and nothing forbids agents from acting. What assessors want to see is that consequential actions are controlled and attributable. In practice that means the same tiering used anywhere else: routine work runs and is logged, sensitive work is sampled, and actions that change records, send information outside the boundary, or cannot be undone wait for a named person. The approval, the approver, and the action are recorded together, so an assessor can follow one task from request to result.

Where the NIST AI RMF fits

The NIST AI Risk Management Framework is voluntary and is not a FedRAMP requirement. It is still useful. It gives a clear way to write down AI-specific risks, such as wrong output delivered confidently, that the security controls assume but do not name. NIST has said it is revising the framework, and it has published a Generative AI Profile, NIST AI 600-1, to go with it. A short appendix that maps your agents' risks to the framework's functions (govern, map, measure, manage) and then to the controls that address them answers a question agencies often ask.

Where programs stall

The problems that most often slow federal agent work are ordinary ones, discovered late.

• A tool or model the agent depends on is not certified at the required class.
• Agents share one service account, so the logs cannot show which agent acted.
• Agent instructions change weekly with no change record.
• Logs capture the conversation but not the tool calls, so a task cannot be reconstructed.
• The agent was scoped as a pilot and never documented as a component of the system.

How LYFYE helps, and what we do not do

LYFYE designs and builds digital workforces: the agents, their identities and permissions, the approval steps, the logs, and the tests. For federal work we build on the certified services your agency already uses and document each agent so it fits your system's security plan. LYFYE does not hold a FedRAMP certification, is not a third-party assessment organization, and does not decide whether a system is approved. Your assessor and your agency do that. Our job is to make sure the agents are built so the evidence is there when they look.