Table of Contents

Reach SOC 2 Compliance in 6 Weeks or Less.

  /

  / NIST AI RMF 1.0 Explained: The AI Governance Benchmark

NIST AI RMF 1.0 Explained: The AI Governance Benchmark

The NIST AI Risk Management Framework (AI RMF 1.0) is the most widely referenced standard for managing AI risk in the United States, and it is not a law, a regulation, or a certifiable standard. It is voluntary guidance. That combination explains both its rapid adoption and the confusion around it: regulators cite it, enterprise buyers ask about it in security questionnaires, and AI governance programs are built on it, yet no auditor will ever hand you an AI RMF certificate. This article explains what the framework actually contains, how its four core functions work, and where it fits alongside ISO/IEC 42001 and the EU AI Act.

NIST AI RMF 1.0

What Is the NIST AI RMF 1.0?

Background and Purpose of the Framework

The AI RMF is a structured approach for identifying, assessing, and managing the risks that AI systems create across their entire lifecycle, from design and data collection through deployment, monitoring, and decommissioning. Its stated goal is to help organizations build and use AI systems that are trustworthy: valid, reliable, safe, secure, accountable, transparent, explainable, privacy-enhanced, and fair. The framework treats AI as a socio-technical system, meaning risk does not come from models and data alone. It also comes from how people build, deploy, oversee, and interact with those systems. That framing is the single most important idea in the document, because it pushes risk management beyond model accuracy metrics and into governance, human oversight, and organizational culture.

Who Published It and When

The framework was published by the National Institute of Standards and Technology (NIST), an agency of the U.S. Department of Commerce, on January 26, 2023. The official document is NIST AI 100-1, developed over 18 months of public workshops, requests for information, and two public draft rounds. Congress directed NIST to create it through the National Artificial Intelligence Initiative Act of 2020, so the framework carries legislative backing even though compliance with it does not.

Voluntary Nature of the Framework

NIST describes the AI RMF as voluntary, rights-preserving, non-sector-specific, and use-case agnostic. There is no enforcement mechanism, no audit regime, and no certification. In practice, the word voluntary undersells its weight. U.S. regulators, including the FTC and sector agencies, reference NIST principles when assessing whether an organization exercised reasonable care; federal contractors face growing expectations to demonstrate NIST-aligned AI governance, and enterprise procurement teams increasingly ask vendors how they apply it. Voluntary frameworks have a habit of becoming de facto requirements, and the AI RMF is following that exact path.

Insider Note: In vendor risk assessments, “do you align with the NIST AI RMF” is becoming the AI equivalent of “do you have a SOC 2 report.” There is no certificate to show, so what buyers actually want is documented evidence: an AI inventory, a risk assessment methodology, and named accountability for AI decisions. Organizations that can produce those three artifacts pass most questionnaires.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Why the NIST AI RMF 1.0 Was Developed

Addressing Unique AI Risks

Traditional software risk frameworks assume deterministic systems: the same input produces the same output, and failures are traceable to specific defects. AI systems break those assumptions. Models drift as real-world data shifts; training data can embed historical bias at scale; outputs can be opaque even to their developers; and the same model can behave differently across deployment contexts. The AI RMF was built specifically for these properties. It treats risk as continuous rather than one-shot, requiring ongoing measurement and monitoring instead of a single pre-deployment review.

Building Trustworthy AI Systems

The second driver was the trust gap. By 2022, organizations were deploying AI faster than they could explain or govern it, and high-profile failures in hiring, lending, and facial recognition had made AI bias a mainstream concern. NIST’s answer was to define trustworthiness in operational terms rather than aspirational ones, breaking it into seven measurable characteristics that risk, security, and product teams could actually work against.

Key Drivers Behind Its Creation

Three forces converged. First, the congressional mandate in the National AI Initiative Act of 2020. Second, international momentum: the framework explicitly aligns with the OECD AI Principles, positioning U.S. guidance within a global consensus on responsible AI. Third, industry demand for a shared vocabulary. Before the AI RMF, every organization defined AI risk differently, which made procurement, audits, and cross-industry collaboration unnecessarily painful. The framework gave executives, engineers, auditors, and regulators a common language.

Core Concepts Behind the NIST AI RMF 1.0

Defining AI Risk

The framework defines risk as the composite measure of an event’s probability of occurring and the magnitude of its consequences. Two things distinguish the AI RMF’s treatment of risk from older frameworks. It explicitly considers positive impacts as well as harms, framing risk management as a way to maximize benefits, not just avoid downsides. And it acknowledges that AI risk is genuinely hard to measure: third-party models, emergent behavior, and a lack of agreed metrics mean organizations must often manage risks they cannot precisely quantify.

Characteristics of Trustworthy AI Systems

The AI RMF defines seven characteristics of trustworthy AI: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair with harmful bias managed. Validity and reliability is described as a necessary precondition for all the others, since an inaccurate system cannot be meaningfully safe or fair. The framework is candid that these characteristics involve trade-offs. Improving explainability can reduce accuracy, and strengthening privacy can limit the data available for bias testing. Managing those tensions is a governance decision, not a technical one.

Framing Risks: Harms to People, Organizations, and Ecosystems

The framework organizes potential harm into three groups. Harm to people covers individual civil liberties, physical and psychological safety, and economic opportunity, as well as harm to communities and society at large. Harm to organizations covers business disruption, security breaches, financial loss, and reputational damage. Harm to ecosystems covers damage to interconnected systems, including the global financial system, supply chains, and natural resources. This breadth is deliberate. It forces impact assessments to look beyond the deploying organization’s own balance sheet.

Structure of the NIST AI RMF 1.0

Part 1: Foundational Information

Part 1 sets the conceptual ground. It explains how AI risks differ from traditional software risks, defines the audience of AI actors — everyone who plays a role across the AI lifecycle, from data scientists to procurement teams to end users — describes the harm taxonomy above, and details the seven trustworthiness characteristics. It also addresses the practical challenges of risk measurement, risk tolerance, and prioritization, acknowledging that organizations cannot eliminate AI risk and should not try to treat every system as equally critical.

Part 2: Core and Profiles

Part 2 is the operational half. It presents the AI RMF Core: four functions broken into categories and subcategories that describe specific outcomes, plus the concept of Profiles for tailoring the framework to specific use cases and sectors. If Part 1 explains why AI risk management matters, Part 2 is the part teams actually implement.

The Four Core Functions of the NIST AI RMF 1.0 Explained

The Core organizes everything into four functions: Govern, Map, Measure, and Manage. They are not sequential steps. Govern is cross-cutting and continuous, while Map, Measure, and Manage are applied to specific AI systems and contexts, often iteratively.

Govern

Govern establishes the organizational foundation: policies, accountability structures, risk tolerance, and culture. It covers legal and regulatory compliance, workforce diversity and competence, third-party risk, and processes for engaging affected communities. NIST positions Govern as the function everything else depends on. Without named accountability and a defined risk appetite, mapping and measuring risks produces documentation that nobody acts on.

Map

Map establishes context. For each AI system, the organization documents its intended purpose, deployment setting, the people it affects, its capabilities and limitations, and the risks and benefits of each component, including third-party models and data. Mapping is where most organizations discover their first uncomfortable truth: they do not actually know how many AI systems they are running, especially once embedded AI features in SaaS tools are counted.

Measure

Measure analyzes and tracks the risks identified during mapping, using quantitative and qualitative methods. This includes testing systems against each trustworthiness characteristic, monitoring for drift in production, and evaluating the effectiveness of the measurement program itself. The framework leans heavily on test, evaluation, verification, and validation (TEVV) processes performed throughout the lifecycle rather than once before launch.

Manage

Manage allocates resources to treat the risks that mapping and measuring surfaced, based on the priorities Govern established. It covers risk response (mitigate, transfer, avoid, or accept), documentation of residual risk, incident response, and decommissioning. Manage closes the loop: it is where risk assessments turn into decisions, including the decision not to deploy a system at all.

Pro Tip: Do not start with Map

Do not start with Map, even though it looks like the natural first step. Start with two Govern outcomes: name a single accountable owner for AI risk and write a one-page AI use policy. Then build the system inventory. Teams that inventory first, without an owner, produce a spreadsheet that goes stale within a quarter.

AI RMF Profiles Explained

Profiles are implementations of the framework’s functions, categories, and subcategories tailored to a specific setting. The framework describes three kinds.

Use-Case Profiles

A use-case profile applies the framework to a particular application or sector, such as hiring, lending, or fraud detection. The most significant published example is the Generative AI Profile (NIST AI 600-1), released in July 2024, which identifies twelve risks unique to or amplified by generative AI — including confabulation, data privacy leakage, and harmful content generation — and maps suggested actions to the Core’s subcategories. In April 2026, NIST also released a concept note for a profile on trustworthy AI in critical infrastructure.

Cross-Sectoral Profiles

Cross-sectoral profiles address risks from activities or technologies that cut across industries, such as large language models or cloud-based AI services, rather than a single vertical application. They help organizations govern shared infrastructure consistently across many use cases.

Temporal Profiles

Temporal profiles describe state over time. A current profile documents how an organization manages AI risk today; a target profile describes the desired end state. The gap between the two becomes the AI governance roadmap — the same gap-analysis pattern familiar from the NIST Cybersecurity Framework and ISO 27001 implementations.

 

AI RMF Categories and Subcategories Overview

Beneath the four functions sit 19 categories and 72 subcategories. Govern is the largest function with six categories spanning policy, accountability, culture, and third-party oversight. Map contains five categories covering context, system categorization, capabilities, component risks, and impact characterization. Measure has four categories on metrics, trustworthiness evaluation, risk tracking, and feedback on measurement effectiveness. Manage has four categories on risk prioritization, treatment strategy, third-party risk management, and response and recovery. Each subcategory is an outcome statement, not a control. The framework tells you what good looks like and leaves the how to you, which is precisely where the Playbook comes in.

 

The AI RMF Playbook: Companion Resource Explained

The AI RMF Playbook is the framework’s practical companion, hosted in NIST’s Trustworthy and Responsible AI Resource Center. For every subcategory, it provides suggested actions, documentation guidance, and references. NIST is explicit that the Playbook is neither a checklist nor an ordered list of steps; organizations borrow what applies to their context. It is also updated more frequently than the framework itself, making it the best place to track NIST’s evolving thinking between formal revisions. For teams staring at 72 outcome statements and wondering where to begin, the Playbook is the difference between a framework and an implementation plan.

Key Benefits of the NIST AI RMF 1.0

The framework’s flexibility is its biggest practical advantage. Because it is technology-neutral and scales to organization size, a 50-person SaaS company and a global bank can both use it without absurd overhead on one end or insufficient rigor on the other. Its structure also plugs neatly into existing governance: the function-category-subcategory model mirrors the NIST Cybersecurity Framework, so security and compliance teams can extend processes they already run rather than building a parallel program. It improves stakeholder communication by giving boards, engineers, and auditors a shared vocabulary. And alignment with it strengthens regulatory positioning: demonstrating AI RMF-based governance is increasingly treated as evidence of reasonable care, and it provides a head start on overlapping requirements in ISO/IEC 42001 and the EU AI Act.

 

Limitations of the NIST AI RMF 1.0

The flexibility cuts both ways. The framework specifies outcomes, not controls, so two organizations can both claim alignment while doing very different amounts of actual risk management. There is no certification, which means no independent verification and no simple artifact to hand a customer. It offers limited prescriptive guidance on emerging issues like agentic AI, and its risk measurement guidance acknowledges — honestly but unhelpfully — that reliable metrics for many AI risks do not yet exist. Finally, it is a living document: the AI RMF 1.0 is currently under revision, per NIST and the 2025 U.S. AI Action Plan, so organizations building programs on it today should design for change rather than treating the 2023 text as final.

Worth Knowing: NIST uses a Two-number Versioning System

NIST uses a two-number versioning system: major revisions increment the generation (1.0 to 2.0) and minor updates add a decimal (1.1). The pending revision will be the first test of how disruptive a framework update is in practice. Organizations that mapped their controls to subcategory IDs, rather than copying text into policies, will absorb the change with far less rework.

How the NIST AI RMF 1.0 Compares to Other Frameworks

NIST AI RMF vs. ISO/IEC 42001

ISO/IEC 42001, published in December 2023, is the international standard for AI management systems (AIMS), and the comparison with the AI RMF comes down to one word: certification. ISO/IEC 42001 is auditable and certifiable; the AI RMF is not. The two are complementary rather than competing. Many organizations use the AI RMF to structure their risk thinking and ISO/IEC 42001 to formalize and certify the resulting management system, much as the NIST Cybersecurity Framework and ISO 27001 coexist in security programs.

NIST AI RMF vs. EU AI Act

The EU AI Act is the comparison that matters most for any organization selling into Europe, and it is a category difference: the EU AI Act is binding law with penalties, while the AI RMF is guidance. The Act entered into force in August 2024 and applies in phases; prohibited practices took effect in February 2025 and obligations for general-purpose AI models in August 2025. In May 2026, EU lawmakers reached provisional agreement under the Digital Omnibus to defer the main high-risk system obligations to December 2027, a 16-month delay reflecting how unprepared the supporting standards ecosystem was. The frameworks are philosophically aligned on risk-based thinking, and AI RMF implementation builds much of the documentation, risk assessment, and human oversight machinery the Act requires. But alignment with the AI RMF does not constitute EU AI Act compliance, and treating it as such is a genuine legal exposure.

Important: A common and costly misconception: “we follow NIST, so we are covered for the EU AI Act.” The AI RMF has no concept of prohibited practices, conformity assessment, or CE marking. If you deploy high-risk systems in the EU, the AI RMF is a strong foundation, not a substitute. Run a separate gap analysis against the Act’s specific articles.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Conclusion

The NIST AI RMF 1.0 earned its position the hard way: by being useful. It gave organizations a shared definition of AI risk, a workable structure in Govern, Map, Measure, and Manage, and the flexibility to scale from a single chatbot deployment to an enterprise AI portfolio — all without licensing fees or audit gatekeeping. Its voluntary status is a feature and a limitation at once, which is why mature AI governance programs rarely use it alone, pairing it instead with ISO/IEC 42001 for assurance and EU AI Act mapping for legal compliance. For organizations starting their AI governance journey, it remains the most sensible first framework to adopt, with the official NIST AI RMF resources as the starting point.

Frequently Asked Questions

Is the NIST AI RMF 1.0 mandatory?

No. It is voluntary guidance with no certification or enforcement mechanism. In practice, U.S. regulators reference it as a benchmark for reasonable care, federal procurement increasingly expects alignment, and enterprise customers ask about it in vendor assessments — so for many organizations it is voluntary in name only.

Any organization that designs, develops, deploys, procures, or uses AI systems. The framework deliberately addresses all AI actors across the lifecycle, from data engineers to risk and compliance teams to executives. It scales to organization size, so it is as relevant to a startup embedding an LLM in its product as it is to a regulated enterprise.

NIST uses a two-number versioning system: major revisions change the generation number and minor updates are tracked as point releases. Version 1.0 was published in January 2023 and is currently being revised under the U.S. AI Action Plan. The companion AI RMF Playbook is updated more frequently than the framework itself.

Yes, through the Generative AI Profile (NIST AI 600-1), released in July 2024. It identifies twelve risks unique to or amplified by generative AI — including confabulation, information security weaknesses, and harmful content — and maps several hundred suggested actions back to the framework’s core subcategories.

There is no certification deadline, so adoption is a maturity curve rather than a project with an end date. Most organizations can stand up the essentials — a named owner, an AI use policy, a system inventory, and an initial risk assessment — within one to three months. Building out measurement, monitoring, and third-party risk processes across all four functions typically takes six to twelve months, and the framework itself frames risk management as a continuous activity thereafter.

Axipro Author

Picture of Pedro Dias

Pedro Dias

Pedro has been writing online for over 10 years. With experience in all things programming, cyber security, and compliance, he is our editor-in-chief at Axipro.

Blog Highlights

Explore More Articles

For the past two years, enterprise AI risk conversations have centered on a familiar set of concerns: model bias, hallucination, data privacy, and dependency on third-party models. These are real risks, and most organizations now run some version of a governance program to manage them. But something has shifted. Organizations are no longer just deploying AI that generates content for a human to review. They’re deploying AI that acts. Agents now plan multi-step tasks, call APIs, move data between systems, execute transactions, and coordinate with other agents, often with no human checkpoint in the loop. That shift deserves more than a footnote in the existing AI risk category. It deserves its own line in the risk register: Agentic Autonomy Risk. What Is Agentic AI Risk Management? Agentic AI risk management is the practice of identifying, assessing, and controlling the risks created when AI systems take autonomous action on an organization’s behalf. Where traditional AI governance evaluates outputs (accuracy, bias, privacy), agentic AI risk management governs what agents actually do: the tools they call, the permissions they inherit, and the downstream consequences of their actions. That distinction is the reason existing risk registers struggle with agents, and it’s worth unpacking properly. What Agentic AI Actually Changes Traditional AI systems, even generative ones, are advisory. They produce an output such as a summary, a prediction, a draft email, or a classification, and a human remains the last checkpoint before anything happens in the real world. Agentic AI removes that checkpoint. An agentic system doesn’t just produce an answer. It pursues a goal. It decides which tools to call and in what order, then executes those actions directly against live systems: submitting a purchase order, modifying a database record, sending an external communication, or orchestrating a set of sub-agents to complete a broader workflow. Agentic autonomy is the degree to which a system can plan and execute actions without a human explicitly authorizing each step. It’s a spectrum rather than a binary. At one end, the AI drafts and a human approves every action. At the other, the AI operates within broad guardrails and only escalates exceptions. The further an organization moves along that spectrum, the less its exposure looks like software risk and the more it looks like delegated authority risk, the kind normally reserved for employees, contractors, and automated financial systems. Why Existing Risk Registers Miss Agentic AI Risks Most enterprise risk registers were built on a reasonably safe assumption: a human initiates consequential actions, and the technology around that human behaves deterministically. Agentic AI breaks both halves of that assumption at once. A few specific gaps show up quickly when organizations try to map agentic deployments onto existing categories. Operational risk registers assume process failures come from human error or system outages, not from a system independently choosing an unanticipated path to a stated goal. Cybersecurity risk registers are built around unauthorized external access, while an agent problem usually involves an authorized system taking unauthorized internal actions with its own legitimate credentials. Model risk frameworks, borrowed largely from financial services, evaluate output accuracy rather than action consequences, which matters most when those actions can’t be reversed. And third-party risk assessments treat vendors as static entities, not as autonomous agents that might invoke other vendors’ agents on your behalf. See our guide to the NIST AI Risk Management Framework for how output-focused frameworks are structured. The result is a governance blind spot. An organization can be compliant against its AI policy, its cybersecurity policy, and its vendor risk policy, and still have nobody accountable for the specific risk of a system initiating a harmful sequence of actions before anyone notices. Defining Agentic Autonomy Risk Agentic Autonomy Risk is the risk that an AI system, operating with delegated decision-making and execution authority, takes actions that are harmful, non-compliant, or misaligned with organizational intent before adequate human oversight can intervene. Those actions might happen independently or in coordination with other agents. It deserves standing as a named category alongside cybersecurity, operational, legal, financial, and third-party risk because the loss event itself is different. The harm is a completed action in a live system, and it may be difficult or impossible to reverse. The accountability structure is different too: when an orchestrating agent delegates to sub-agents, responsibility for the outcome gets distributed in ways existing ownership models don’t cleanly capture. So is the detection window. Traditional controls assume a human is positioned to catch an error before it compounds, but an agent can execute dozens of dependent actions faster than any human review cycle. 7 Agentic AI Risk Scenarios to Put on Your Register 1. Unauthorized autonomous decision-making. An agent takes an action within its technical permissions but outside its intended business mandate. It adjusts pricing, approves a refund, or modifies a customer record, and no policy ever explicitly authorized that scenario. 2. Goal misalignment. The agent optimizes for a literal interpretation of its objective in a way that diverges from actual business intent, particularly under ambiguous or adversarial inputs. 3. Multi-agent interactions and cascading failures. One agent’s flawed output becomes another agent’s trusted input. A single error can propagate across a chain of agents faster than anyone can detect it, amplifying the original mistake instead of containing it. 4. Excessive tool or system permissions. Agents get provisioned with broad, standing access “to be safe” rather than scoped, least-privilege access tied to specific tasks. A productivity tool quietly becomes a privilege-escalation path. 5. Regulatory non-compliance. Autonomous actions trigger obligations under data protection, financial services, employment, or sector-specific regulation, and they execute without the compliance review a human-initiated process would normally receive. 6. Explainability and accountability gaps. An autonomous action causes harm and the organization can’t clearly reconstruct why the agent chose that path, or establish whether the business owner, the AI governance function, or the vendor is accountable for the outcome. 7. Autonomous third-party actions. A vendor’s agent, integrated into your environment, takes action on your behalf, or your agent acts against a

A SOC 2 penetration test costs between $1,000 and $30,000 for most companies. A typical SaaS scope, meaning one web application, its API layer, and the cloud infrastructure behind it, usually lands between $2,000 and $20,000. Early-stage startups with a narrow scope can get an auditor-accepted test for $1,000 to $8,000, while enterprises with multiple products and hybrid infrastructure regularly spend $20,000 to $50,000 or more. The spread is wide because “penetration test” covers everything from an automated scan with a cover page to weeks of manual testing by senior engineers. Auditors know the difference, and so do the enterprise customers who asked for your SOC 2 report in the first place. This guide breaks down what drives the price, where the hidden costs sit, and how to buy a test that holds up in fieldwork without overpaying for it. What Is SOC 2 Penetration Testing?​ A SOC 2 penetration test is a simulated attack on your systems, performed by a qualified security professional, scoped to the environment covered by your SOC 2 report. The tester tries to exploit real weaknesses the way an attacker would: broken access controls, injection flaws, misconfigured cloud services, exposed credentials. The output is a report your auditor reads as evidence that your security controls work in practice, not only on paper. That last part matters. A pentest bought for SOC 2 has a second audience beyond your security team. If the report doesn’t map findings to your audit scope, document its methodology, and show remediation, it fails the job you bought it for. We cover the full deliverable in our guide to what a SOC 2-ready VAPT report includes. How Penetration Testing Fits Into SOC 2 Compliance​ SOC 2 is built on the AICPA’s Trust Services Criteria, and the Security category (the Common Criteria) applies to every report. Penetration testing is the standard way to satisfy CC7.1, which expects you to detect and monitor for new vulnerabilities, and it supports CC4.1, which covers ongoing evaluations of whether controls actually function. The AICPA’s points of focus explicitly mention vulnerability scanning and penetration testing as examples of how companies meet these criteria. In practice, the test slots into your audit timeline as an evidence item. Your auditor will ask for the report, check the test date against the audit period, and review how you handled the findings. Remediation is often scrutinized harder than the test itself, because it shows whether your vulnerability management process runs or merely exists. Is Penetration Testing Required for SOC 2?​ Strictly speaking, no. The Trust Services Criteria never use the word “mandatory” about penetration testing. You could theoretically satisfy CC7.1 with vulnerability scanning and strong monitoring alone. In reality, almost every auditor expects one, and skipping it invites two problems. First, your auditor may push back during fieldwork or add exceptions to the report. Second, the enterprise buyers reviewing your SOC 2 report increasingly look for pentest evidence specifically, and a report without it raises questions during procurement. Treat the test as effectively required and budget for it from the start of your SOC 2 compliance checklist. How Much Does SOC 2 Penetration Testing Cost? Typical Price Range for SOC 2 Pen Testing Most companies pay $1,000 to $30,000, with the median engagement for a SaaS business sitting around $12,000 to $15,000. Compliance-focused tests at the lower end of the market start around $1,000 to $5,000. Deep manual testing from established firms runs $10,000 to $30,000. Anything quoted below roughly $3,000 is almost certainly automated scanning packaged as a pentest, which auditors are getting better at spotting. Cost by Company Size (Startup, SMB, Enterprise) Company size is a proxy, not the driver. A 15-person company with three products and a legacy on-prem component will pay more than a 200-person company with one tightly scoped SaaS platform. Testers price effort, and effort follows scope. Cost by Test Type (Network, Web App, API, Cloud, Internal/External) Most SOC 2 engagements bundle two or three of these. The common package for a cloud-native SaaS company is web app plus API plus cloud configuration, which is why the $1,000 to $20,000 band comes up so often. Companies with office networks and internal systems in their audit scope add internal network testing, and the price climbs accordingly. Factors That Influence SOC 2 Penetration Testing Cost Scope and Number of Assets Tested Scope is the single biggest cost driver. Every additional application, API endpoint group, cloud account, or network segment adds testing hours. A pentest priced without a scoping call is a pentest priced on guesswork, and the guess usually favors the vendor. Complexity of Application or Infrastructure​ A simple CRUD app with two user roles tests quickly. A multi-tenant platform with role hierarchies, workflow engines, file processing, and third-party integrations takes far longer, because each of those features creates attack surface a tester has to work through manually. Authentication tiers matter especially: every distinct role needs testing for privilege escalation and cross-tenant data access. Testing Methodology (Black Box, Grey Box, White Box) Black box testing gives the tester nothing but a URL, grey box adds credentials and documentation, and white box adds source code and architecture diagrams. Grey box is the default for SOC 2 and usually the best value, since the tester spends time exploiting rather than discovering. White box costs more upfront but finds deeper issues. Black box sounds rigorous but often wastes paid hours on reconnaissance an attacker would run for free. Depth of Testing and Manual vs. Automated Approaches Automated scanning finds known vulnerability patterns. Manual testing finds business logic flaws, chained exploits, and authorization gaps that no scanner catches, and it’s the part auditors and security-literate customers actually value. The ratio of manual work to automation is the honest explanation for most price differences between two quotes covering the same scope. Tester Credentials and Firm Reputation Senior testers holding OSCP, GPEN, or CREST credentials bill higher rates, and firms with recognized methodologies charge a premium for the credibility their letterhead carries

Two compromised versions of LiteLLM sat on PyPI for roughly 40 minutes on the morning of March 24, 2026. That window was enough to capture secrets from around 434,000 CI/CD pipeline runs across nearly 2,500 organizations, including AWS, Samsung, Cisco, Salesforce, Siemens, and Deloitte. In August, researchers at CloudSEK and Hudson Rock confirmed they had obtained the raw exfiltrated data: a 153GB archive containing 433,909 files of environment variables, cloud keys, Kubernetes secrets, and API tokens harvested live from running pipelines, as covered by Help Net Security’s reporting on the credential archive. If LiteLLM runs anywhere in your stack, or you touch any AI proxy infrastructure at all, you need answers to three things: whether you were exposed, what to rotate first, and whether the rotation you did back in March actually held. That last one matters more than it sounds, because “we rotated everything” has already burned at least one very large company. How the Breach Happened The attack didn’t start with LiteLLM. On March 19, 2026, a threat group called TeamPCP compromised the build pipeline of Trivy, a vulnerability scanner half the industry runs, and pushed a poisoned release. LiteLLM’s own CI pipeline ran Trivy, so the poisoned scanner had legitimate read access to the project’s runner environment. The attackers used that to steal LiteLLM’s PyPI publishing tokens and ship two malicious releases of their own: versions 1.82.7 and 1.82.8. KICS and the Telnyx Python SDK got hit in the same campaign. The payload design is the part worth studying. The malicious package dropped a .pth startup hook into site-packages, so the code ran the moment any Python interpreter started on the machine, whether or not anything imported LiteLLM. From there it harvested environment variables, read local credential files like .aws/credentials and .kube/config, tried to move laterally across Kubernetes clusters, and installed a systemd backdoor dressed up as a generic telemetry service. InfoQ’s coverage of the PyPI compromise put downloads of the compromised release above 40,000. For scale, LiteLLM normally gets downloaded around 3 million times a day. The exfiltration had a nasty fallback, too. According to CloudSEK, stolen data was encrypted and sent to a typosquatted domain, and when that failed, the malware created a public repository inside the victim’s own GitHub account and uploaded the loot as a release asset. Some companies were publishing their own secrets to the open internet and had no idea. Worth Knowing: The malicious code only existed in the PyPI artifacts. The GitHub source repository stayed clean the whole time, so a developer reviewing the code on GitHub saw nothing wrong. Source review isn’t artifact verification. If you don’t check that what the registry serves matches the upstream source, this class of attack is invisible to you. How to Check If You Were Exposed Three checks, from quickest to most involved. 1. Confirm whether the compromised versions ever ran The malicious versions went live on PyPI at 10:39 UTC on March 24, 2026 and got quarantined about 40 minutes later. The project’s advice: treat any install from that day before 16:00 UTC as suspect. Search your lockfiles, pip caches, SBOMs, and container image histories for 1.82.7 and 1.82.8. And check your internal artifact mirrors. An Artifactory or Nexus proxy that cached the bad release in March can keep serving it internally long after PyPI pulled it. Keep the .pth mechanism in mind when you scope this. The question isn’t “which applications import LiteLLM,” it’s “which machines had the package installed at all,” because every Python process on an infected machine triggered the payload. 2. Hunt for persistence Rotation is pointless if the attacker still has a foothold. Check developer machines, CI runners, and containers for unauthorized .pth files in site-packages and for suspicious systemd units, especially anything posing as a system telemetry service. And review activity from March 24 onward, not just the 40-minute window. Persistence is there so the access outlives the infection. Pro Tip: Don’t limit the persistence hunt to live machines. Base container images rebuilt in late March may have baked the payload into every image derived from them since. Scan your image registry for the affected LiteLLM versions and for unexpected .pth files, then trace which running workloads came from flagged images. 3. Check whether your secrets are in the dump Hudson Rock has published a domain lookup tool and is running ethical disclosures for affected organizations, and CloudSEK maintains a high-confidence victim list. Use them, but know their limits. Attribution in this dataset is genuinely hard. One dump with a siriusxm.com committer email actually traced, through its self-hosted GitLab endpoints, to AdsWizz, a SiriusXM subsidiary. And a large share of the dumps are generic pipeline configurations with no identifying domain, email, or server name at all. Absence from a victim list is not evidence of absence. If your pipelines ran the compromised versions, assume exposure no matter what a lookup tool tells you. What to Rotate, in What Order The guidance from both research teams is blunt: treat every secret the LiteLLM environment could reach as compromised. That covers secrets on disk, in memory, injected into CI jobs, and anything retrievable through instance metadata services. Work down by blast radius: Priority Credential type Why it comes first 1 Cloud IAM keys (AWS, GCP, Azure) Direct control of infrastructure, data stores, and billing. This is where attackers monetize fastest. 2 GitHub and GitLab PATs, package publishing tokens These let an attacker poison your releases and turn your company into the next link in the supply chain. 3 Kubernetes service account tokens and kubeconfigs Lateral movement across clusters was built into the payload, not a theoretical risk. 4 Database passwords and third-party API keys Dumped in plain text in the archive, often with no attribution, so nobody will warn you they leaked. 5 AI provider API keys Billing abuse, quota theft, and access to whatever data flows through your LLM routing layer. One word matters more than the rest of this article: revoke, don’t just rotate. That