This page is for risk managers, security architects, and the engineers who answer NIST AI RMF questions in vendor questionnaires, federal proposals, and board reports for organizations running AI agents. It maps the controls Praesidia provides to the framework's four functions, Govern, Map, Measure, and Manage, at the subcategory level, and it lists the evidence you can export for each.
The NIST AI Risk Management Framework 1.0 (January 2023) is voluntary, outcome-oriented, and deliberately technology-neutral. It defines seven characteristics of trustworthy AI (valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, fair) and organizes practice into four functions with numbered categories and subcategories. The Generative AI Profile (NIST AI 600-1, July 2024) adds suggested actions for generative risks under the same structure. Nothing certifies alignment; the framework asks you to be able to show your work.
Agents change the difficulty of that showing. GOVERN 1.6 asks for an inventory of AI systems; agents are created by developers faster than any registry is updated. MEASURE 2.4 asks for production monitoring; an agent's behaviour is a stream of tool calls and inter-agent messages, not a single output. MANAGE 2.4 asks for mechanisms to supersede, disengage, or deactivate; a fleet on shared credentials cannot be stopped one agent at a time. The NIST AI RMF for agents post works through each function; the AI governance guide gives the broader control model.
Control mapping
| Requirement / criterion | What Praesidia provides | Evidence you can produce |
|---|---|---|
| GOVERN 1.4 — Risk-management processes are transparent and documented | On the Enterprise plan, framework report generation against the AI RMF control catalogue with evidence collection and gap tracking, and compliance reports summarising posture. | Generated framework report; gap list with owners and status. |
| GOVERN 1.5 — Ongoing monitoring and periodic review of the risk process | Alert rules over the audit stream (Advanced tier and Enterprise); access-review workflows on a schedule you set (Enterprise); per-agent risk classification (Advanced tier and Enterprise), reassessable on change. | Alert history; completed access-review records; classification revision history. |
| GOVERN 1.6 — Inventory of AI systems maintained and resourced | Registration of every agent, MCP server, and application with its own identity; discovery surfaces agents operating outside governance so they can be adopted. | Inventory export; the discovery inbox listing agents that were observed but not yet adopted. |
| GOVERN 1.7 — Safe decommissioning processes | Single-agent revocation without affecting the fleet: the agent is issued no new token and its further calls through Praesidia are refused, its MCP tool calls under the enforce governance mode, while an identity token issued before the revocation stays valid until it expires and model calls through the gateway with an application key continue to be accepted for up to a minute, until the gateway's next policy refresh refuses the key, while requests already running finish and a streamed response can last up to 10 minutes (see MANAGE 2.4). Recorded in the trail with the reason, naming the member who revoked the agent. | Revocation events with the reason and time. |
| GOVERN 2.1 — Roles, responsibilities, and lines of communication documented | Customer control; Praesidia contributes role-based access for the control plane (Advanced tier and Enterprise), SSO/SCIM tied to your identity provider (Enterprise), and scoped API keys so automation has a named, bounded role. | Role assignments; SCIM lifecycle records; API-key scope listing. |
| GOVERN 6.1 — Policies for third-party software, data, and supply-chain risks | Customer control; Praesidia contributes bring-your-own-key model-provider access, governed MCP-server connections with per-tool authorization, and a published subprocessor list on the security page. | Provider and MCP-server inventory; tool-authorization configuration. |
| MAP 1.1 — Intended purposes, context of use, and assumptions documented | Declared connections, permitted tools, guardrails, and policies per agent as a machine-readable statement of intended operation; risk tier recorded on the agent (Advanced tier and Enterprise). | Per-agent configuration export; classification record. |
| MAP 5.1 — Likelihood and magnitude of impacts characterised | Customer control; Praesidia contributes structured per-agent risk classification (Advanced tier and Enterprise) and the historical behaviour data (denied requests, guardrail hits, spend) needed to ground the estimate. | Classification with rationale; behaviour metrics for the period. |
| MEASURE 2.4 — Functionality and behaviour monitored in production | OpenTelemetry traces your instrumented agents send to your Praesidia workspace, a per-organization metrics export, guardrail hit rates, denied-request counts, spend attribution per agent, team, and workflow, SIEM forwarding (Advanced tier and Enterprise). | Metric exports; dashboards; forwarded events. |
| MEASURE 2.7 — Security and resilience evaluated and documented | Bidirectional guardrails against prompt injection and data exfiltration; intent rules that block the right call against the wrong data; non-human identity with rotation and vaulted credentials. | Guardrail decision records; blocked-injection samples; rotation history. |
| MEASURE 2.8 — Transparency and accountability risks examined | An append-only, hash-chained audit trail of the decisions Praesidia makes, signed under the default configuration (an operator can turn signing off), with an offline verifier. A signed record shows it was not changed afterwards, not that every action was captured; calls that do not pass through Praesidia are not recorded. | Signed bundle export plus verifier result, reproducible by a third party. |
| MEASURE 2.10 — Privacy risk examined and documented | PII detection and redaction in both directions; data residency, with each organization assigned one residency region: any deployment whose region differs from the organization's refuses that organization's API requests, while requests that carry no organization, and the model gateway's own calls, are not checked against the region; GDPR erasure support. See the GDPR mapping. | Redaction decision records; the organization's assigned residency region; erasure records. |
| MANAGE 2.4 — Mechanisms to supersede, disengage, or deactivate | Single-agent revocation: a revoked agent's next A2A call is refused and it is issued no new token, and its MCP tool calls through Praesidia are refused from the next call under the enforce governance mode, while in observe mode the call still runs and is recorded as a would-deny decision. An identity token issued to the agent before its revocation stays valid until it expires, by default minutes after issuance, for a service that checks it offline, and model calls made through the gateway with an application key continue to be accepted for up to a minute, until the gateway's next policy refresh refuses the key; requests already running then finish, and a streamed response can last up to 10 minutes. Guardrails that can block a specific agent task or chat-turn tool call; tool policies that refuse an MCP tool call or hold it for a person's approval, only under the enforce governance mode; budget policies, on the Team and Enterprise plans, that can pause or block new agent tasks once spend reaches a threshold you set, and refuse a model call through the gateway that would exceed an agent's or the organization's budget, with no budget checked on an MCP tool call; human approval gates before consequential actions. | Revocation events with the reason and time, naming the member who revoked the agent; approval decisions with the approver; guardrail, tool-policy and budget refusals with reason and time, where they were recorded. |
| MANAGE 4.1 — Post-deployment monitoring, incident response, recovery, and change management | Customer control; Praesidia contributes forensic search and alert rules (Advanced tier and Enterprise), a chain view that traces an agent-to-agent chain hop by hop (Enterprise), and audit records of control-plane changes, attributed to the operator or API key that made them. Not every change is recorded, and for most changes recording is not guaranteed. | Incident-period export with chain views; the recorded changes to the affected connection. |
What this mapping is not
The NIST AI RMF is voluntary and has no certification scheme, so there is nothing to certify against; this mapping supports your assessment and does not constitute certification or an endorsement by NIST. It shows which subcategories Praesidia's controls contribute to and what artefacts you can pull for each. It does not decide your risk tolerance (MAP 1.5), rank your risks (MANAGE 1.2), or write your incident-communication plan (MANAGE 4.3).
Most of GOVERN is organisational: policy, culture, workforce competence, and engagement with affected communities (GOVERN 1.1, 1.2, 3, 4, 5). The MAP function is largely analytical work by people with domain knowledge (MAP 1.2, 2.3, 3). Praesidia gives those activities a system of record and operating data; it does not perform them.
Two scoping statements belong in any alignment claim you make. Calls that do not pass through Praesidia are not recorded. And Praesidia records the decisions it makes in an append-only, hash-chained audit trail, signed under the default configuration; an operator can turn signing off. A signed record shows it was not changed afterwards. It does not show that every action was captured. Those limits are written out at /security/verify-your-audit-trail, and a careful reviewer will want them stated rather than discovered.
Getting started
- Close the GOVERN 1.6 gap first. Register every agent, MCP server, and application at /start, following the getting-started guide, and adopt anything discovery surfaces that nobody registered.
- Record intended purpose and a risk tier per agent (risk classification is on the Advanced tier and Enterprise; MAP 1.1, MAP 5.1), then attach the treatments, guardrails and policies, to the connections they mitigate, and a gate that holds each task for a person's approval and a monthly spend cap to a connection between two agents; no budget is checked on an MCP tool call, and a tool call is sent for a person's approval by the agent's tool policy, not by its connection to an MCP server, which refuses a tool it marks as requiring approval.
- Rehearse MANAGE 2.4. Revoke a test agent, confirm the rest of the fleet keeps running, and confirm the revocation appears in the trail. The kill-switch post covers the design questions; the incident readiness checklist covers the runbook.
- Produce one piece of MEASURE 2.8 evidence end to end via from agent action to audit evidence, verify the export offline per /security/verify-your-audit-trail, then, on the Enterprise plan, generate the AI RMF framework report and assign owners to the gaps it lists.
Common questions
It is voluntary guidance from the U.S. National Institute of Standards and Technology, published as AI RMF 1.0 in January 2023 with a Generative AI Profile (NIST AI 600-1) in 2024. It is widely referenced in U.S. federal procurement, state laws, and customer questionnaires, so many organizations treat alignment as a practical requirement even though no regulator certifies it.
It means you can show, subcategory by subcategory, what you do and what evidence supports it. On the Enterprise plan, Praesidia generates framework reports against the AI RMF control catalogue with evidence collection and gap tracking, so the claim is backed by exports rather than a narrative. This mapping supports your assessment and does not constitute certification.
GOVERN 1.6 (inventory) because agents proliferate; MEASURE 2.4 and 2.7 (production monitoring, security and resilience) because agents act continuously against live tools; and MANAGE 2.4 (the ability to supersede, disengage, or deactivate) because an agent that cannot be stopped surgically is a risk the framework names explicitly.
Revocation acts on one agent and leaves the rest of the fleet running. Once an agent is revoked, its next A2A call is refused and it is issued no new token, and its MCP tool calls through Praesidia are refused from the next call when the organization's agent governance mode is enforce; in observe mode those calls still run and are recorded as would-deny decisions. An identity token issued to the agent before its revocation stays valid until it expires, by default minutes after issuance, for a service that checks it offline, and model calls made through the gateway with an application key continue. Narrower stops sit beside it: guardrails that can block a specific agent task or a tool call in a chat turn; a tool policy, which refuses or holds an MCP tool call only when the organization's agent governance mode is enforce; and budget policies, on the Team and Enterprise plans, that can pause or block new agent tasks once spend reaches a threshold you set, and refuse a model call through the gateway that would exceed an agent's or the organization's budget. A revocation is recorded in the audit trail with the reason and the time and names the member who revoked the agent; an agent revoked with an organization API key names neither a user nor the key. Refusals are recorded with the reason and the time where they are enforced. Recording is not guaranteed, and a signed record shows it was not changed afterwards, not that every action was captured; these records are the evidence MANAGE 4.1 asks you to keep.
The Profile adds suggested actions for generative risks such as prompt injection, data leakage, and confabulation under the same four functions. The guardrail, identity, and monitoring rows below are the controls those actions point to; the Profile's governance and content-provenance actions remain largely yours.