On February 17, 2026, the National Institute of Standards and Technology launched the Center for AI Standards and Innovation (CAISI) AI Agent Standards Initiative, backed by $55 million in new federal funding. The initiative is organized around three pillars: industry-led standards developed through ISO/IEC JTC 1, community open-source protocols including the Model Context Protocol, Agent-to-Agent, and Agent Communication Protocol, and fundamental research into agent behavior and evaluation.
For a company building the enforcement layer for AI-powered systems, this is an inflection point worth taking seriously. The shape of the agent ecosystem over the next five years will be heavily influenced by how the standards conversation plays out — who participates, which protocols win adoption, what compliance pathways are defined for federal buyers, and where the boundary between training-time and runtime safety gets drawn. CAISI itself sits at the intersection of commercial AI and national security: its remit includes evaluating AI capabilities with national security implications and coordinating across DoD, DOE, DHS, and the Intelligence Community. Standards written there will reach defense tech and aerospace and defense programs, not just commercial SaaS.
Below are four positions Containment.ai is willing to defend publicly as the standards conversation moves forward.
1. Runtime enforcement is not training-time alignment
A meaningful share of the public AI governance conversation still collapses two distinct problems into one. The first is making a model behave well when it is trained — alignment, post-training safety work, constitutional methods. The second is making an AI system behave well when it is deployed inside an organization, with access to real data, real users, and real business consequences. These are different engineering problems, with different failure modes and different controls.
Training-time alignment is the responsibility of model developers. It is necessary, it is hard, and we are glad model labs are investing in it. It is not, however, sufficient for an enterprise. An aligned model is still capable of executing a poorly scoped tool call, surfacing data through a permissioned action, or following an instruction that an employee should not have given it in the first place.
Runtime enforcement is what happens after the model ships. It is policy authorization at the point of action: deciding which tool calls an agent can invoke, which data classifications can leave the organization, and which actions require human approval — before the action executes, with no model in the decision path. CAISI's framing — explicitly scoped to agent behavior in deployment — recognizes this distinction, and we read that as a positive signal for the category.
2. Open standards beat vendor lock-in
The second pillar is the most consequential one for buyers. CAISI is investing public funds in community-developed, open-source protocols rather than letting a single vendor's proprietary agent stack become the de facto standard.
This matters because the alternative is already visible. Every major model provider is shipping its own agent runtime, its own tool-calling format, and its own integration surface. Without open protocols, an enterprise buyer who picks one vendor's agent platform inherits that vendor's decisions about how agents discover tools, how they pass context, and how they are audited. Switching costs become structural rather than incidental.
Open protocols change the math. If an organization's audit logs, policy enforcement, and tool inventories speak MCP, the question of which model sits behind the agent becomes a procurement decision rather than an architectural one. That is the world enterprise security teams want. It is also the world a healthy enforcement market needs in order to exist at all — an enforcement layer that only works with one model vendor is a feature of that vendor, not an independent control.
We support the open-protocol pillar without reservation. Containment.ai's enforcement layer is built to be model-agnostic, and we will continue to invest in MCP support specifically because it is the protocol most likely to make that promise real for our customers.
3. Federal AI buyers need a compliance pathway, not a moratorium
The federal contracting community has been navigating a difficult question for two years: how to adopt commercial AI tools without an authorization framework purpose-built for them. FedRAMP exists for cloud services. There is no equivalent, today, for an autonomous agent that calls external APIs, holds short-term memory across sessions, and acts on behalf of a federal employee.
The practical effect of that gap has been either over-cautious procurement that excludes the most capable tools or under-governed deployment that creates audit risk later. Neither is good for federal mission outcomes — and the stakes are highest exactly where agent adoption pressure is strongest, in national security and defense programs where an agent's action may be irreversible.
CAISI's posture points toward something more useful: a FedRAMP-adjacent pathway for agent systems that codifies what "demonstrably governed" looks like for federal use. To be explicit about our own status: Containment.ai holds no certifications yet — and makes no certification claims. What we will say is that a clear, testable pathway is the right outcome for the agency CIOs and CISOs we talk to, and that the standards conversation should drive toward it rather than around it. Action-time enforcement evidence — a deterministic verdict on each agent action, recorded before execution — is precisely the kind of artifact a continuous-authorization case for agents will need, and standards should define what that evidence looks like.
4. AI Action Enforcement is its own category
The fourth position is the most contested, and the one we expect to defend most often. Ruling on AI agent actions at runtime is a distinct product category — we call it AI Action Enforcement. It is not a feature of a model provider. It is not a feature of a SIEM. It is not a feature of a CASB or a DLP. And it is not the same thing as the agent control planes the large platform vendors are shipping — those manage the AI estate; enforcement authorizes the individual action at the seam where it becomes irreversible. The layers overlap at the edges and are structurally different at the core. A control plane can sit on top of an enforcement layer; most should.
The structural difference is this: enforcement for AI agents has to evaluate the action itself, at machine speed, across surfaces a traditional security stack was not built to observe. A DLP tool can tell you that a string matching a credit card pattern left the organization. It cannot tell you that an agent was asked to summarize a customer database and chose, on its own, to include account numbers in the response. A SIEM can ingest a log of which API was called after the fact. It cannot rule, before execution, on whether the tool call was within the policy scope the organization approved for that agent.
CAISI's framing of agent evaluation as an open research question is a useful tailwind here. The more the standards conversation treats runtime agent behavior as a first-class problem, the easier it becomes for buyers to understand why the controls that worked for static SaaS do not, by themselves, work for agents.
What we plan to do
Containment.ai will participate in the standards conversation where we can be useful and stay quiet where we cannot. Concretely, that means contributing to the open-protocol working groups around MCP, publishing what we learn about action-time policy enforcement in production, and being clear with our customers and prospective federal buyers about what we are and are not authorized to do today.
We will not overstate our compliance posture. We will not claim parity with frameworks we have not earned. We will not use the initiative as a marketing prop. The standards process works because the participants treat it seriously, and we intend to be one of those participants.
Containment.ai is The AI Action Enforcement Layer — the independent enforcement layer for AI-powered systems. This post reflects our reading of the public CAISI materials at nist.gov/caisi and does not represent NIST's positions. This draft was prepared with AI assistance and reviewed before publishing.