Which NIST AI RMF requirements a self-hosted Dify helps with
A regulated team that deploys Dify workflows and agents and must show AI risk management should expect Dify to supply evidence for the Measure and Manage functions and for parts of Govern, while the Map function and the organization's own policies remain its work. The NIST AI Risk Management Framework is voluntary. NIST states that it does not validate or endorse any organization's use of it, and there is no AI RMF certification, accreditation or conformity assessment program. DeployOpen plans, configures and documents systems and collects evidence for a review, but it does not certify conformance, and neither does any independent auditor who reads that evidence on the framework's behalf.
The AI RMF Core is organized into 4 functions, 19 categories and 72 subcategories. Govern has 6 categories and 19 subcategories, Map has 5 categories and 18 subcategories, Measure has 4 categories and 22 subcategories, and Manage has 4 categories and 13 subcategories, as listed in Tables 1 to 4 of NIST AI 100-1 (NIST AI 100-1). Govern is cross-cutting, and NIST says the actions are not a checklist and that users may choose which categories and subcategories to address. Most users start with Map once Govern outcomes exist, so a team should confirm which subcategories its own program scopes in before it maps any Dify setting to them.
Mapping AI RMF functions to Dify capabilities and configuration
This table maps each NIST AI RMF function to the Dify capability, configuration and documentation that supports it. Read the Edition note column first, because SSO, multiple workspaces and audit logging depend on Dify Enterprise, while the other rows apply to the Community edition. The main takeaway is that Dify gives you tooling for measurement and management, but the governance and mapping decisions still need to be documented by your organization.
| AI RMF function | Dify capability and configuration | Dify source | Edition note |
|---|---|---|---|
| Govern: who can build and change AI apps | Use workspace roles and SSO scopes for workspace access, and limit who can create accounts and change apps | Dify Enterprise SSO introduction | Enterprise for SSO and multiple workspaces; Community is limited to one workspace |
| Govern: secrets and encryption keys | Set SECRET_KEY before first use, since changing it later logs out all users. Review how workspace encryption keys are stored | Dify environment variable reference | Confirm which key storage options your edition exposes |
| Map: inventory of AI apps and their context | Export apps as YAML DSL files that record prompts, workflow nodes, model parameters and knowledge base links | Dify app management docs | Available in Community; DSL files exclude API keys, knowledge content and usage logs |
| Measure: tracing and output monitoring | Enable LLMOps monitoring and tracing for each app, and set log retention to match your evidence period | langgenius/dify repository | Confirm trace retention and export options for your version |
| Measure: human correction of answers | Use annotation replies to correct known answers, and review the annotations on a fixed schedule | Dify app management docs | Confirm annotation behavior and records for your version |
| Manage: moderation and response control | Attach moderation endpoints to apps so flagged inputs or outputs are blocked or logged before a response is returned | Dify app management docs | Confirm moderation options available in your edition |
| Manage: outbound requests and agent containment | Keep the SSRF proxy enabled so outbound requests are filtered for internal and private IP ranges, and keep agent sandbox network isolation on | Dify environment variable reference; Dify 1.16.1 release notes | Available in Community; verify these settings after each upgrade |
| Manage: service authentication and upgrades | Track the monthly minor releases, back up before each upgrade and check .env.example for new variables. Token-based service authentication arrived in 1.16.1 | Dify releases page; Docker Compose deployment docs | Confirm the Enterprise upgrade path with Dify before scheduling changes |
What evidence a self-hosted Dify produces and how to keep it
A reviewer testing a Dify deployment against NIST AI RMF activities usually asks for the same record types: what ran, how each app was built, which version was live, what could be restored and who had access. Each card names one artifact, what it covers and what to check before an assessment. Dify produces some of these records, but retention and export depend on decisions your organization makes.
Tracing and run logs
Tracing and run logs show what each workflow, agent or knowledge base call did, which model responded and what inputs and outputs were recorded. A reviewer sampling Measure activities will ask for these first. Confirm which run data your Dify version records, where it sits in the metadata database and whether you can export it on a schedule into storage you control. Export before any cleanup job runs.
App configuration exported as DSL
DSL exports capture app configuration, workflow nodes, model parameters, prompts and knowledge base connections, so a reviewer can see how an app was built at a given point. The export does not include third-party API keys, knowledge base content or usage logs. Record those separately in your secrets inventory, model provider records and log exports. Keep exported files in version control with a dated commit for each review.
Version and upgrade records
Each Dify release lists its changes on the GitHub Releases page, and the upgrade guide for the target version sets the steps. Keep a dated record of the running version, the change ticket, the backup taken beforehand and the .env.example differences you applied. The 1.16.1 notes describe agent sandbox network isolation, token-based API authentication between services and sandboxed Jinja2 template rendering, so these belong in your change evidence. Minor releases arrive roughly monthly.
Backup and restore records
Backups are the evidence that a deployment can return to a known state. Cover the metadata database (PostgreSQL by default), file storage, the vector store and the .env configuration. Record each backup's time, scope and the result of a restore test. Keep SECRET_KEY in a secrets store, since changing it after deployment logs out all users and it also encrypts OAuth credentials, so a restore must be tested with the original value.
Access records from SSO and roles
The Community edition is limited to a single workspace, so role boundaries and environment separation need their own planning. Enterprise SSO supports three protocols: OpenID Connect, SAML and OAuth2, with identity providers such as Microsoft Entra ID, Okta and GitHub. It separates scopes for workspace access and web app access. Export sign-in and role assignment records on a schedule, and ask your identity team which group changes they can supply for each access review.
Retention and cleanup settings
Retention is the organization's responsibility, and it must be planned in storage the organization controls. Read the environment variable reference for cleanup-related settings in your Dify version, then compare them with the retention periods in your AI policy and records schedule. Where the two differ, change the setting or copy records into your own storage before cleanup removes them. Document the configured value, the policy and the date you checked both.
How Govern, Map, Measure and Manage fit together in a Dify rollout
Govern is the cross-cutting function that has to exist before the others produce useful output. NIST's AI 100-1 describes Govern as cross-cutting, says its actions are not a checklist or an ordered set of steps, and notes that most users start with Map once Govern outcomes are in place, then continue to Measure or Manage. In a Dify program, that means the first work is organizational: an inventory of every Dify app, workspace and knowledge base, a named owner for each app who can accept its risks, and a written rule for who may publish to production. Map then documents what each app is for, who uses it, which model providers and knowledge sources it touches, and where a failure would hurt someone. Those use-case records are the input the later functions need.
Measure and Manage follow from that record. In Dify, measurement depends on tracing and LLMOps monitoring being switched on for each app and retained long enough to review, so confirm the retention settings for your version in the Dify docs before you rely on them. Management covers moderation endpoints, annotation replies for correcting known bad answers, and human review steps for sensitive actions. Test each app against its documented use case, configure the controls, then monitor the traces and feedback and send results back to the risk owner. Expect to loop: a monitoring finding usually sends you back to Map or Govern, not forward. The Dify docs on app management are the natural next read for the app records this sequence depends on.
Two warnings apply throughout. The AI RMF is voluntary and has no certification, so no one can be "RMF certified" and the sequence proves nothing to an auditor on its own. The Playbook is also not a checklist. NIST describes it as suggested actions, documentation prompts and references, and its audit log shows the last content update in August 2023. NIST says AI RMF 1.0 is being revised under the White House AI Action Plan and has not yet published a revised version, so confirm the current state with NIST before you map your records to any subcategory wording.
What the platform does not cover in the AI RMF
A self-hosted Dify supplies logs, controls and separation that feed the AI RMF functions, but the framework leaves much of the work to the organization. The cards below list the items your team must author, commission or confirm before anyone can say the deployment aligns with the framework.
No certification or attestation
The AI RMF is voluntary, and NIST does not validate, endorse or certify any organization's use of it. Neither Dify nor DeployOpen can issue an AI RMF certificate or attestation for your deployment. Treat any vendor or partner claim of AI RMF certification as a prompt to ask what, specifically, was assessed and by whom. Your own documented mapping, reviewed internally or by an independent assessor you engage, is the evidence you can actually present.
Risk tolerance and policy authorship
The framework asks the organization to define its own risk tolerance, approval gates and policies, but it does not supply their content. Dify can enforce a threshold only after someone decides what the threshold is, such as which apps may reach customer data or which outputs need a human reviewer. Assign an owner for these decisions, record who approved them and tie each rule to the Dify app or workspace it governs.
Context, intended use and affected people
Map depends on analysis that happens before any workflow is built: the purpose of each app, the people it affects, the settings in which outputs are used and the harms that could follow. Dify holds the workflow definition, but it cannot know who your customers, patients or staff are or how a wrong answer would reach them. Document these answers per app and keep them with the DSL export and version history so the context stays linked to the code.
Generative AI Profile mapping
NIST AI 600-1 defines 12 generative AI risks and attaches suggested actions to AI RMF subcategories. Applying it is a separate exercise: you must decide which of the 12 risks apply to each Dify chatbot, agent or RAG app and show how your controls address them. Running the platform does not complete that analysis, so schedule it as its own work item with named owners and a review date.
Model provider and third-party risk
Dify routes prompts and retrieved content to model providers, embedding services and plugins that your organization does not operate. Their security practices, data retention, availability and model changes sit outside the platform. Keep a register of each provider and model endpoint in use, record the contractual terms you hold, and confirm with each provider how they handle the data your apps send.
Data quality, bias and framework revision
Dify does not test whether retrieved knowledge is accurate, whether outputs are valid for the task or whether results differ unfairly across groups. Those checks need evaluation datasets and documented acceptance criteria that your team or a testing partner designs. NIST states that AI RMF 1.0 is being revised as part of the White House AI Action Plan and has not published a revised version as of 17 October 2026, so re-check the mapping when the revision is released.
Configuration sequence for an AI RMF evidence program
This sequence sets up a self-hosted Dify so that the records behind each AI RMF function exist, are protected and can be exported on a schedule. It is ordered so that each step depends on the one before it.
Confirm edition, SSO and audit capabilities
Before any configuration, confirm with the Dify vendor which edition you will run. The Community edition is free and limited to a single workspace, while the Enterprise edition adds SSO, multiple workspaces, advanced security and professional support. Check the pricing page and the Enterprise SSO documentation against your identity provider and workspace model. Ask the vendor in writing which audit log features your edition includes. The output is a short written record of edition, SSO protocol and workspace layout that the rest of the sequence relies on.
Set secret key and encryption key handling
Generate the SECRET_KEY value in your secrets manager, not in a shared file, and set it in the deployment environment before first use. Changing it after deployment logs out all users, so record the decision and the owner of the value. Decide where workspace encryption keys are stored, either locally or in Azure Key Vault, and document who can read them. Confirm that backups of the database are protected by the same key-handling rules. The output is a recorded key inventory showing where each secret lives and who controls it.
Route outbound requests through the SSRF proxy
Configure SSRF_PROXY settings so that outbound requests from Dify, including tool calls and model endpoints, pass through the proxy that blocks internal and private IP ranges. Then test from inside the application that a request to an internal address is refused and that an approved external endpoint still works. Record the proxy configuration and the test results. For agent workloads, also confirm that the sandbox network isolation described in the 1.16.1 release notes is present in the version you run. The output is a dated test record showing blocked and allowed destinations.
Enable tracing and configure moderation and annotation replies
Turn on tracing and LLMOps monitoring for each production app so that inputs, outputs and node executions are recorded for the Measure function. Configure moderation settings and annotation reply behavior for each app, and write down which rules apply and who approves changes to them. Test a sample of conversations to confirm that traces appear and that moderation triggers as the written rule says. Confirm where traces are stored and how long they are retained, since retention depends on your deployment and log settings. The output is a per-app settings register and a test log showing traces and moderation events.
Separate workspaces for development and production
Create distinct workspaces or environments for development, testing and production, and restrict who can publish to production. Under the Community edition, the single-workspace limit means separation has to come from separate deployments, so confirm this design early. Record which app versions are promoted, by whom and on what date. Check that a change made in development cannot reach production without the recorded approval. The output is an environment map with named owners and a promotion log that auditors can sample.
Define role-based access reviews
Assign roles to workspace members and, on Enterprise, map them to groups in your identity provider. Define who may create, edit, publish and view apps and knowledge bases, and separate web app access from workspace access. Schedule a review in which each owner confirms that current members still need their roles, then remove access that is no longer needed. Keep the signed review record with the date and reviewer name. The output is a role matrix and a completed review record for each review cycle.
Set backups and a pre-upgrade backup step
Define backups for the metadata database, file storage and vector store, and test a restore into a separate environment before relying on them. Add a rule that a backup is taken before every upgrade, as the Docker Compose documentation recommends. Store backups under the same access and encryption rules as production data. Record the restore test date, the result and the person who performed it. The output is a backup runbook and a restore test record that you can show an assessor.
Schedule evidence exports and upgrade checks
Document a recurring schedule for exporting access reviews, promotion logs, trace samples, audit log exports where your edition provides them, and app DSL files, noting that DSL exports exclude third-party API keys, knowledge base content and usage logs. Assign an owner to each export. After every version change, compare your environment file against .env.example and record any new variables, since upgrades can add settings your deployment needs. Minor releases arrive roughly monthly, so plan a regular review of release notes. The output is a dated evidence calendar and an upgrade record for each version change.
Measuring and managing AI risk in Dify without overstating coverage
Dify produces inputs for the Measure and Manage functions of the NIST AI RMF, but it does not perform measurement or management on its own. Tracing, run logs and moderation outputs are evidence that your team can analyze. The metrics, thresholds, review cadence and response actions belong to your organization. AI 100-1 describes seven characteristics of trustworthy AI, and a useful way to plan is to ask, for each one, which Dify signal informs it and which work sits outside the platform. Start with the characteristics Dify can inform most directly: valid and reliable (tracing of workflow runs and node inputs and outputs, which lets you compare behavior across app versions), safe (moderation outputs and annotation replies that you review, not just enable), and secure and resilient (the sandboxed code execution, SSRF proxy settings and token-based service authentication described in Dify's release notes, which you still need to verify in your own environment).
Accountable and transparent and explainable and interpretable depend heavily on what you record. Tracing shows the path through a workflow, but it does not explain why a model produced an answer. Decide which runs must be retained, who reviews them and how long they stay available, and confirm the retention behavior of your Dify version before you promise it to an auditor. Privacy-enhanced is only partly covered: logs and knowledge chunks may contain personal data, so the measurement plan must say what is logged and who can see it. Fair with harmful bias managed is the clearest gap. Dify can show you outputs for a set of test inputs, but deciding which populations to test, what counts as harmful bias and what remediation is acceptable is a governance and domain task. Treat fairness as work your organization or a specialist partner must design, with its own datasets and sign-off, and do not record it as covered by the platform.
Put the signals into a written measurement plan before go-live. For each application, name the metric, the threshold that triggers review, the reviewer role, the review cadence and the response action, such as pausing an app version or rolling back to an earlier one. Reviewers should be separate from the people who build the workflow where your risk tolerance requires it. Re-run the plan after each Dify upgrade, since minor releases arrive roughly monthly and can change behavior. Map each characteristic to the specific NIST AI RMF subcategories you have chosen to address, using the NIST AI RMF Playbook as a source of suggested documentation, while noting that the Playbook is not a checklist and that NIST does not certify or endorse any organization's use of the framework.
Questions teams ask before mapping Dify to the NIST AI RMF
Does NIST certify Dify deployments against the AI RMF?
No. NIST does not certify, accredit or endorse products, deployments or organizations under the AI RMF. NIST describes the framework as voluntary and publishes no conformity assessment program for it. A mapping of Dify to the framework is a internal record of how your organization addresses each function, and it becomes useful evidence only when your own governance owners review it and your auditors or assessors evaluate it on their terms. Ask any partner to describe the output in those terms, and treat any claim of certification as a red flag.
How much effort does a Dify AI RMF mapping take?
Effort depends on how much of your AI estate sits inside Dify and how much of the control environment already exists. The main drivers are the number of apps and workflows, the number of model providers and embedding or rerank models, the number and sensitivity of knowledge base sources, the size of the team that must answer for each app, and whether SSO and centralized logging already cover Dify. A team with a current inventory and working identity and logging will need far less discovery than one starting from scratch. Ask any quote to break effort down by these drivers so you can see which ones your environment changes.
What does the mapping need from our team?
The work needs decisions from people, not just access to systems. Expect to name risk owners for each AI use case, provide an inventory of Dify apps, models and data sources, grant access to the environment for review and testing, and identify the decision-makers who approve risk acceptance and remediation priorities. Governance subcategories depend on owners who can answer for the system's purpose, data and impact, so a mapping without named owners will stall at the Govern and Map steps. Confirm these commitments and their timing in the written scope before work starts.
Can our team map Dify to the AI RMF without a partner?
A team can do this alone if it has staff who understand the AI RMF functions, can run a self-hosted Dify deployment, and can operate its logging, identity and backup tooling. The Community edition is free and limited to a single workspace, so a team with that internal expertise can build the mapping in-house. A partner adds experience with the framework's subcategories, a second reviewer for control design, and hands-on work on configuration, testing and evidence collection. Decide based on whether your staff can keep the mapping current as Dify releases roughly monthly and as the AI RMF itself changes.
What changes with Dify Enterprise for AI RMF evidence?
Enterprise adds capabilities that make governance evidence easier to produce and maintain. Its listed features include SSO, multiple workspaces, advanced security, a commercial license and professional support, and it can be deployed on Kubernetes for high availability. The SSO documentation covers OpenID Connect, SAML and OAuth2 with named identity providers, and separate scopes for workspace and web app access. Audit logging is described in separate Dify Enterprise material. Enterprise is custom priced, so ask the vendor for a written quote and confirm which of these features your required controls depend on.
How does the AI RMF 1.0 revision affect our planning?
NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan and has not yet published a revised version, so the current text may change. Plan the mapping around the function and category structure you can trace today, keep each mapped item linked to the Dify configuration that supports it, and record the framework version you mapped against. Confirm with NIST's AI Risk Management Framework pages when the revision is published and budget time for a re-mapping review at that point. NIST also expects a formal review no later than 2028, so build the mapping to be updated rather than treated as final.
Which Dify settings should an engineer check first?
Start with settings that produce evidence and limit exposure. Confirm that the SECRET_KEY is set before first use, since changing it later logs out all users, and that outbound requests use the SSRF proxy so internal and private ranges are blocked. Review where the metadata database, file storage and vector store are located, and confirm backups run before each upgrade. Check that the Dify release you run includes the agent sandbox network isolation described in the 1.16.1 release notes. Record each check with the version tested so the evidence can be sampled later.
How DeployOpen scopes and delivers AI RMF evidence configuration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including self-hosted Dify. For NIST AI RMF work, we configure the Dify settings that produce measurement, management and governance evidence, and we prepare that evidence for your own review. We do not issue framework certifications, since none exists for the AI RMF.
How we scope
- We list every Dify app, workflow and agent in the engagement and assign each to a named owner.
- We map which AI RMF functions and subcategories you intend to address, agreed with you in writing before work starts.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing; ongoing support is available as a retainer.
How we build
- We configure tracing and log retention in Dify so measurement evidence exists for each in-scope application.
- We set up moderation endpoints, annotation replies and access roles, then test them against the risks you have documented.
- We separate development, staging and production environments and document how changes move between them.
How we hand over
- You receive a configuration record, a function-by-function evidence map and the runbooks your team needs to operate it.
- We document which AI RMF subcategories each control supports and which ones still depend on your own policies and staff.
- We walk your team through the evidence exports so reviewers can sample records without relying on us.
How we support
- Retainers cover Dify upgrades, reviews of new releases and updates to the evidence map as your applications change.
- We re-check configuration after each Dify upgrade, since minor releases arrive roughly monthly.
- We confirm with you, in writing, any change to scope that affects which framework subcategories the evidence covers.
Sources and further reading
- NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0), January 2023 ↗
- NIST AIRC: AI RMF Playbook ↗
- NIST AI 600-1, Generative Artificial Intelligence Profile, July 2024 ↗
- Dify docs: Environment variables ↗
- Dify Enterprise docs: SSO introduction ↗
- langgenius/dify GitHub repository ↗
