Home > Security and Compliance Blog > Cybersecurity Risk Management > Why FIPS 140-3 Encryption Matters for AI Agent Data Access

Why FIPS 140-3 Encryption Matters for AI Agent Data Access

by Bob Ertl updated March 25, 2026 Cybersecurity Risk Management

Reading Time: 9 minutes

Most organizations deploying AI agents against regulated data believe they have encryption covered. The API calls use TLS. The data at rest is AES-256. The model hosting provider has a security page that mentions encryption. The box is checked.

It isn’t. Not for compliance purposes. CMMC SC.3.177 requires FIPS-validated cryptography — not strong cryptography, validated cryptography. HIPAA’s 2025 Security Rule amendments made encryption of ePHI mandatory and require validated cryptographic modules. FedRAMP Moderate requires FIPS 140-validated encryption throughout. The requirement is not “use AES-256.” It is “use a cryptographic module that has been validated by NIST to correctly implement AES-256.” Those are different things, and the gap between them is where AI agent deployments are currently falling short.

Table of Contents

This post explains what FIPS 140-3 validation actually means, where AI agent data paths introduce encryption gaps in otherwise compliant environments, and why validated encryption at every point in the agent pipeline is the third foundational governance primitive — after authenticated identity and ABAC policy — that regulated AI deployments require.

Executive Summary

Main Idea: FIPS 140-3 validation is not a grade of encryption strength. It is a certification that a specific cryptographic module — a software library, hardware device, or firmware component — has been tested by an accredited laboratory and validated by NIST to correctly implement approved cryptographic algorithms under defined operating conditions. An AI agent data path that uses unvalidated AES-256 is not FIPS-compliant. An AI agent data path that uses FIPS 140-3 validated modules at every transit and storage point is.

Why You Should Care: AI agent inference pipelines introduce multiple data transit and storage points that most organizations have not assessed for FIPS validation status: API gateways, model hosting environments, vector databases, temporary inference caches, output delivery channels. Each is a potential encryption gap. For defense contractors, the gap is a CMMC SC.3.177 finding. For healthcare organizations, it is a HIPAA Security Rule deficiency. For federal contractors broadly, it is a FISMA and FedRAMP compliance failure. The assessment required is straightforward — but most organizations haven’t done it for their AI infrastructure.

Key Takeaways

FIPS 140-3 validation is a module certification, not an algorithm specification. The question is not “does this system use AES-256?” It is “does the cryptographic module implementing AES-256 in this system appear on NIST’s Cryptographic Module Validation Program list?” Unvalidated implementations of approved algorithms do not satisfy FIPS requirements.
AI inference pipelines have multiple transit and storage points, each of which requires independent assessment. The TLS connection from the application to the API gateway. The connection from the gateway to the model host. The model’s temporary working memory. The vector database. The output cache. Confirming FIPS validation at the application layer does not confirm it at every downstream component.
Multi-tenant cloud AI infrastructure rarely provides FIPS validation documentation by default. General-purpose commercial AI platforms are not built to satisfy federal cryptographic validation requirements. Organizations deploying these platforms against regulated data workflows must specifically request FIPS module validation certificates — and many will find they cannot produce them.
FIPS 140-3 supersedes FIPS 140-2 for new validations. NIST transitioned the program to FIPS 140-3 in September 2021. Organizations and vendors still referencing only FIPS 140-2 should verify whether their modules have been revalidated under the current standard. New procurements should require FIPS 140-3 validation specifically.
Validated encryption is the layer that makes the rest of the governance stack durable. Authenticated identity and ABAC policy enforcement prevent unauthorized access. Validated encryption ensures that even if data transits an unintended path, it cannot be read. The three controls are complementary — each addresses a different failure mode. Encryption without access control leaves data readable to anyone who gains access. Access control without validated encryption leaves data readable in transit to anyone who intercepts it.

What FIPS 140-3 Validation Actually Means

The Federal Information Processing Standard 140-3 is a U.S. government standard that specifies the security requirements for cryptographic modules used to protect sensitive information. It is administered by NIST through the Cryptographic Module Validation Program (CMVP). A module achieves validation by being tested by an accredited third-party laboratory against the standard’s requirements, with NIST issuing the final validation certificate.

Validation covers four security levels, from Level 1 (basic requirements, software-only implementations acceptable) to Level 4 (highest physical security, tamper-evident and tamper-responsive). For most regulated enterprise applications — including healthcare, financial services, and defense contracting — FIPS 140-3 Level 1 validation is the applicable requirement. The key point is that any level of FIPS validation requires the module to have actually been tested and certified — not merely to use approved algorithms.

What validation certifies: the module correctly implements the approved algorithm. The key management functions are implemented correctly. The module’s self-tests function as specified. The module’s security documentation is accurate and complete. What validation does not certify: that the system using the module is otherwise secure. A FIPS-validated cryptographic module in an otherwise poorly secured system is still a poorly secured system — but it satisfies the cryptographic requirement that CMMC, HIPAA, FedRAMP, and NIST 800-171 impose.

FIPS 140-2 vs. FIPS 140-3

NIST formally transitioned the CMVP to FIPS 140-3 in September 2021, with FIPS 140-2 validations no longer accepted for new submissions after September 2026. Organizations should be aware that many existing vendor certifications still reference FIPS 140-2. For current procurements and compliance assessments, FIPS 140-3 is the applicable standard — and the distinction matters when evaluating AI infrastructure vendors whose security documentation may reference the older standard.

You Trust Your Organization is Secure. But Can You Verify It?

Read Now

Where AI Agent Pipelines Introduce Encryption Gaps

A typical AI agent data path in a regulated environment involves more transit and storage points than most compliance assessments have evaluated. Each represents a potential FIPS validation gap — not necessarily because encryption is absent, but because the specific cryptographic module in use may not be validated.

Pipeline Component	Data at Risk	Common Validation Gap
Application to API gateway	Regulated data in the agent’s request payload	TLS implementation may use standard OpenSSL build, not a FIPS-validated module
API gateway to model host	Prompt context including regulated data retrieved for inference	Internal cloud provider transit often outside validated encryption boundary
Model inference environment	Regulated data in working context window during inference	GPU memory and inference runtime typically have no FIPS validation status
Vector database (RAG)	Embedded representations of regulated data used for retrieval	Vector database encryption often uses unvalidated libraries
Temporary output cache	Agent output containing or derived from regulated data	Cache storage frequently unencrypted or using unvalidated encryption
Output delivery channel	Final agent output to downstream system or user	Delivery may use standard TLS without confirmed FIPS module validation

The practical implication: an organization that has FIPS 140-3 validated encryption at its application layer — using a validated module for its primary data store and communications — may have an entirely unvalidated encryption posture across the AI inference pipeline it has layered on top of that application. The FIPS validation status of the primary data store says nothing about the validation status of the API gateway, model host, vector database, and output cache the AI agent uses.

The Multi-Tenant Cloud Problem

General-purpose commercial AI platforms — major LLM APIs, AI orchestration services, vector database vendors — are built for broad enterprise adoption, not for federal cryptographic validation compliance. Their security documentation may mention encryption, reference industry-standard algorithms, and include various security certifications. What it typically does not include is NIST CMVP validation certificates for the specific cryptographic modules used in the components that handle regulated data during AI inference.

This is a structural gap: the commercial AI market was not built to satisfy FIPS 140-3 requirements, and most vendors do not maintain CMVP-validated modules as a standard feature of their platforms. Defense contractors and federal agencies have addressed this for primary systems by requiring FedRAMP-authorized cloud services and government-specific product variants. Few have extended that assessment to the AI inference layer they are now deploying against those same systems.

How to Assess and Close Encryption Gaps in AI Agent Deployments

1. Map Every Encryption Boundary in the Agent Data Path

Start with a complete map of every point at which regulated data is in transit or at rest within the AI agent pipeline: from the data source through the agent orchestration layer, API gateway, model hosting environment, any retrieval databases, output processing, and final delivery. For each point, identify the cryptographic module providing encryption. This is not the same as identifying the encryption algorithm — it requires identifying the specific software library or hardware module implementing that algorithm.

2. Verify CMVP Validation Status for Each Module

Cross-reference each identified cryptographic module against the NIST CMVP validated modules list, available at csrc.nist.gov. A module that does not appear on the list — or whose listed validation has expired — is not FIPS-compliant regardless of what algorithm it implements. For vendor-provided infrastructure, request the CMVP certificate number directly. A vendor that cannot produce a CMVP certificate number for the cryptographic module handling your regulated data does not have FIPS-validated encryption for that component.

3. Document Gaps and Remediation Plans

For each pipeline component where validated encryption is absent or unconfirmed, document the gap, the regulated data at risk, and the applicable compliance requirement. This documentation serves two purposes: it defines the remediation roadmap, and it demonstrates to assessors that the organization has conducted the required risk assessment and has a plan to close identified gaps. Organizations undergoing CMMC assessment should have this documentation ready — it is a predictable evidence request.

4. Require FIPS 140-3 Validation in AI Vendor Contracts

Add FIPS 140-3 module validation requirements to AI vendor contracts for any vendor whose infrastructure handles regulated data. This should specify validation at each component handling that data, not just at the primary storage layer. It should also require vendors to notify the organization when validated modules are updated, replaced, or when validation status changes — since CMVP certificates are version-specific and a software update can invalidate a prior certification.

How Kiteworks Provides FIPS 140-3 Validated Encryption for AI Agent Data Access

The Kiteworks Private Data Network is built on FIPS 140-3 Level 1 validated encryption for all data in transit and at rest. This validation covers the full data path through which AI agent regulated data interactions are processed — not just the primary storage layer, but every component in the governance architecture that handles regulated data.

When an AI agent accesses regulated data through Kiteworks, every transit and storage operation uses validated cryptographic modules. The same validated encryption that protects human user access to regulated data automatically protects AI agent access — because the governance layer sits between the agent and the data, and every data interaction passes through that layer. There is no separate AI-specific encryption assessment required; the FIPS validation extends to AI agent data access by architecture.

For defense contractors, this means SC.3.177 is satisfied for AI agent CUI interactions with CMVP certificate documentation producible directly to C3PAO assessors. For healthcare organizations, the mandatory encryption requirements of the 2025 HIPAA Security Rule amendments are satisfied for AI agent PHI access. For federal contractors broadly, the FedRAMP Moderate authorization covering the Kiteworks platform extends to AI agent workflows operating through it.

Validated encryption is not the most visible AI governance control — it operates below the surface of every data interaction. But it is the layer that ensures that authenticated identity and ABAC policy enforcement are not undermined by data that can be read in transit. The three controls together — identity, policy, and validated encryption — constitute the governance stack that makes every AI agent regulated data interaction defensible. Learn more about Kiteworks Compliant AI or schedule a demo.

Frequently Asked Questions

CMMC SC.3.177 requires FIPS-validated cryptography — specifically, cryptographic modules that appear on the NIST CMVP validated modules list. Using AES-256 through an unvalidated implementation does not satisfy this requirement. A C3PAO assessor will ask for CMVP certificate numbers, not algorithm descriptions. If your AI infrastructure vendor cannot produce those certificates for the components handling CUI, you have a SC.3.177 finding regardless of encryption strength.

The 2025 amendments require that ePHI be encrypted in transit and at rest using validated cryptographic modules — not just strong algorithms. For AI agent deployments, this means every component in the inference pipeline that handles PHI — API gateways, model hosts, vector databases, output caches — must use FIPS-validated encryption. The HIPAA Security Rule requirement applies to the full data path, not just the primary storage system.

Request the NIST CMVP certificate number for each cryptographic module the vendor uses in components handling your regulated data. Then verify that certificate number against the NIST CMVP validated modules list at csrc.nist.gov. A vendor that describes their encryption as “FIPS-compliant” or “AES-256” without providing a CMVP certificate number has not demonstrated FIPS 140-3 validation. The certificate number is the only verifiable evidence of validation status.

Not automatically. FedRAMP authorization covers the authorized service boundary. AI inference components — the orchestration layer, API gateways, model hosting, vector databases — that you have added on top of a FedRAMP-authorized platform are not within that platform’s authorization boundary unless specifically included. Each added component requires its own FIPS validation assessment. The FedRAMP authorization of the underlying platform provides a strong foundation but does not substitute for validation of the AI components layered above it.

The three controls address different failure modes. Authenticated identity and the delegation chain prevent unauthorized access by ensuring only properly authorized agents can reach regulated data. ABAC policy enforcement ensures that even authorized agents can only access the specific data their current workflow requires. Validated encryption ensures that data intercepted in transit — whether by an attacker on the network or by an unauthorized component in the inference pipeline — cannot be read. Each layer closes a gap the others cannot. Together they constitute a governance stack where a failure at any one layer doesn’t compromise the whole.

Additional Resources