The first time you try to package an agent system for an ATO, you discover that the System Security Plan template assumes a world that no longer exists. The agent calls a model that calls a tool that spawns a subagent that retrieves a document that rewrites the prompt that triggers a different tool. The data flow diagram you submitted last quarter is already wrong. The control implementations you wrote against AC-4 and SI-10 assume deterministic, inspectable inputs. Your assessor wants to know what the boundary is, and the honest answer — “it depends on what the planner decides at runtime” — is not going to clear the package.
This is the actual problem facing anyone trying to authorize agentic AI in 2026. The technology shipped before the boundary discipline caught up, and a lot of programs are papering over the gap with one-page “AI appendices” that do not survive contact with a serious assessor. What follows is a workable approach: treat the agent runtime as a distinct enclave, treat tools as external interconnections, and stop pretending the LLM is just another microservice.
Why the Microservice Boundary Model Breaks
A traditional service has a closed set of inputs (the API contract), a closed set of downstream calls (the dependency graph in your manifest), and deterministic behavior modulo bugs. You can enumerate trust boundaries because the code enumerates them.
An agent has none of those properties. The planner LLM emits tool invocations that are a function of the prompt, the retrieved context, and the model weights. A tool registered through Model Context Protocol can be added to a running agent without a code change. The same user query can produce a three-tool trajectory on Monday and a fourteen-tool trajectory on Tuesday because someone updated the system prompt or swapped the model checkpoint.
That means the static artifacts RMF assessors expect — a data flow diagram, an interconnection table, a list of ports and protocols — describe a snapshot, not the system. If you authorize the snapshot, the system you actually run is unauthorized within a week.
The Three-Plane Decomposition
The pattern that holds up under assessment is to decompose the agent system into three planes, each with its own boundary and its own control story.
The control plane is everything that decides what the agent is allowed to be: model registry, system prompt store, tool catalog, MCP server registrations, policy engine, evaluation harness, and the CI/CD that promotes any of those into production. This plane is conventional software. CM-3, CM-5, CM-8, and SR-3 apply directly. Every promotion to the runtime plane should be a signed, attested artifact, and the signing identity should be logged to an append-only store under AU-9.
The runtime plane is the agent loop itself: the planner model, the executor, the working memory, the tool dispatcher, and the per-session context window. This is where non-determinism lives. The boundary here is not the set of tools the agent could call — it is the set of tools the dispatcher will permit it to call for a given principal in a given session. That distinction is the entire ballgame for AC-3 and AC-6. If your dispatcher enforces a per-session capability list derived from the authenticated user’s authorizations, you have a defensible least-privilege story. If your dispatcher executes whatever JSON the model emits, you do not.
The tool plane is everything the agent reaches into: databases, SaaS APIs, internal microservices, file stores, other agents. Each of these is an external system from the agent runtime’s perspective, even when it lives in the same VPC. Treat them as interconnections under CA-3. The interconnection agreement — even an internal one — should specify the data sensitivity flowing in both directions, because a tool response is an injection vector into the planner’s context.
Mapping to 800-53
The control families that carry the most weight for an agentic system are not the ones programs usually emphasize.
| Family | Where it actually bites |
|---|---|
| AC-3, AC-4, AC-6 | Per-session tool capability enforcement; egress filtering on tool responses |
| AU-2, AU-3, AU-12 | Full trajectory logging: prompt, retrieved context, tool calls, tool responses, final output |
| CA-3, CA-9 | Each MCP server and external tool as a documented interconnection |
| CM-3, CM-8 | Model checkpoints, system prompts, and tool registrations as configuration items |
| SI-10, SI-15 | Input validation on tool responses before they re-enter the context window |
| SR-3, SR-4, SR-11 | Provenance for model weights and any third-party tool definitions |
The one most teams underweight is AU-3. A trajectory log that captures only the final answer is useless for incident response. You need the full chain — including the tool responses that shaped the planner’s next step — because that is where prompt injection lands. If a downstream document tells the agent to exfiltrate, your only forensic evidence is the retrieved chunk and the tool call that followed it.
Indirect Prompt Injection as a Boundary Problem
The community has spent two years treating prompt injection as a model alignment problem. It is not. It is a boundary problem. The planner’s context window is a privileged execution environment, and any data that enters it from a less-trusted source is the equivalent of unsigned code being loaded into a kernel. The mitigations follow from that framing: classify every context source by trust level, refuse to execute tool calls whose justification depends solely on untrusted context, and require a separate authorization step for any action that crosses a sensitivity boundary.
This is also why “the LLM is just a function” is the wrong mental model for the SSP. A function does not change behavior because its arguments contained imperative English. The planner does. SI-10 implementations that only validate tool call schemas, and not the content that motivated the call, miss the actual attack surface.
What a Defensible Package Looks Like
An authorization package for an agent system in 2026 should include, at minimum: a tool catalog with sensitivity labels and per-role capability matrices; an MCP server inventory treated as interconnections; a model and prompt change-management procedure tied to CM-3; a trajectory logging specification mapped to AU-2/AU-3; an evaluation harness with red-team results against indirect injection; and a continuous monitoring plan that re-runs that harness on every model or prompt change. The continuous monitoring piece is what converts a one-time authorization into something that survives the next checkpoint swap.
The agent is not the system. The agent is what the system does on a given Tuesday. Authorize the machinery that decides what it can do, log every step it takes, and treat every tool as a foreign country.