On April 2, 2026, Microsoft turned on Researcher, Analyst, Agent Builder, and Copilot Studio publishing across U.S. government clouds, with Researcher rolling out starting in GCC (Government Community Cloud). Agentic AI is now live in environments where, six months ago, the most aggressive thing your users could do was ask Copilot to summarize a document.
Here is the question almost nobody is asking out loud: none of that was in scope when your ATO was written. Your authorization boundary describes a system that no longer matches the one your users are touching.
Agents Are Not Just Faster Copilot
Traditional Copilot answered a prompt and stopped. Agentic AI changes the shape of the system in three ways your System Security Plan probably never accounted for.
Autonomy. Researcher runs multi-step processes; it plans, retrieves, and assembles across your content without a human approving each hop. Analyst reasons over data and produces visualizations and written conclusions. The system now takes a sequence of actions on a single instruction. Your AU and SI control narratives were written for request-response, not for a process that runs itself.
Expanded data-access scope. An agent reaches across everything the invoking identity can touch, and it does so deliberately and at depth to complete its task. The same oversharing that was a slow risk under static Copilot becomes an actively-traversed risk under an agent. Your access-control documentation assumed a narrower reach than the system now has.
A publishing surface. Agent Builder and Copilot Studio publishing let users create agents and share them. That is a new distribution channel inside your boundary, built by end users, capable of being handed to others. If your SSP has no concept of a user-published agent, you have an entire category of system component that exists in production and nowhere in your documentation.
The capability shipped to your tenant. The authorization to run it did not ship with it.
What You Update Before Your ISSO Finds Out the Hard Way
This is not a reason to block agents. It is a reason to bring your authorization package up to the system you actually operate. Concretely:
- Boundary and data flow. Update the SSP to describe agent behavior: autonomy, what content agents traverse, and where outputs land.
- Access control (AC). Document and constrain who can invoke and who can build agents. Agent creation is a privilege, not a default.
- Configuration management (CM). Establish an agent inventory and a governance gate. An agent published by an end user is a configuration change.
- Audit (AU). Confirm agent activity is logged and reviewable. Purview DSPM for AI extends to agent interactions; use it.
- Risk acceptance. If the gap is real, it belongs in a POA&M with a remediation timeline, not in a blind spot.
Why This Bites Harder in GCC
In commercial tenants, an undocumented capability is a governance headache. In a government environment operating under an ATO, it is the difference between authorized and operating outside your authorization. The features run inside Microsoft’s FedRAMP-authorized GCC boundary and can be governed to align with CMMC and NIST 800-171 control objectives, but alignment is something you configure and document. It does not arrive switched on. The platform gave you the engine. The control narrative is still your job.
Who’s Behind This
I am Jacob, a U.S. Navy veteran and the engineer behind Puget Sound AI, a veteran-owned small business that architects, builds, and governs M365 AI inside GCC. I work the engineering and the compliance framing together, because in this environment they are the same job. No account managers; you talk to the person doing the work.
If agents are live in your tenant and your authorization package still describes last year’s system, that is worth a conversation before your next assessment. Let’s talk.