Enterprise AI security is often discussed as if it were a property of the model: a safety toggle, a content filter, a “responsible AI” checklist on the vendor’s website. That framing does not survive an audit. Security for AI systems is the same work as security for any production system that handles identity and data — plus a set of AI-specific risks that now have public frameworks you can map to.
Three public references are enough to structure the program: NIST’s AI Risk Management Framework, ISO/IEC 42001 as a certifiable management system, and NIST’s emerging SP 800-53 overlays for securing AI systems (COSAiS).
NIST AI RMF: Govern, Map, Measure, Manage
The NIST AI Risk Management Framework (AI RMF 1.0) is voluntary and sector-agnostic. Its four functions are the operating language most U.S. boards will recognize:
- Govern — policies, roles, and culture that run through the other functions
- Map — context, intended use, and who is affected
- Measure — tests, metrics, and evidence
- Manage — prioritize, respond, and improve
NIST later published a generative-AI profile (NIST AI 600-1) for risks that are specific to GenAI, and in 2026 opened work on a profile for trustworthy AI in critical infrastructure. None of these replace your existing security program. They tell you what extra questions to ask when the system is a model that can generate, retrieve, or act.
ISO/IEC 42001: the auditable management system
ISO/IEC 42001:2023 specifies an Artificial Intelligence Management System (AIMS). It uses the same high-level structure as ISO 27001, which is why organizations that already run certified management systems can layer it. NIST AI RMF is strong on risk taxonomy and trustworthy-AI characteristics. ISO 42001 is strong on the management-system architecture a third party can attest. They are complementary: use NIST to name and measure the risks; use 42001 when customers, regulators, or insurers ask for a certifiable system.
Controls that actually sit on the system
Frameworks do not configure IAM. NIST’s Control Overlays for Securing AI Systems (COSAiS) project is writing SP 800-53 overlays for concrete use cases: adapting and using generative AI / LLMs, fine-tuning predictive AI, single-agent and multi-agent systems, and controls for AI developers. That is the implementation layer: confidentiality, integrity, and availability of training data, weights, prompts, and tool access — not a slogan on a slide.
In practice the controls look familiar to anyone who has run identity and access work:
- Inventory of models, tools, and data stores the system can touch
- Enterprise identity on the platform (who may invoke the agent, against which data)
- Data residency and isolation for content that cannot leave the network
- Prompt, retrieval, and tool logs that an examiner can reconstruct
- Evaluation and monitoring after go-live, not only at the demo
Those are the same themes as Meruksha’s Risk & Governance and AI Platform Setup services: governance that can pass a review, and platforms (Bedrock, Azure AI Foundry, Copilot Studio) built on identity rather than bolted on before an audit.
If a vendor cannot show how their system maps to Govern/Map/Measure/Manage, which 42001 clauses they claim, and which access and logging controls sit on the runtime, you do not have an AI security program. You have a model with a marketing page.
Sources: NIST AI RMF; NIST.AI.100-1; ISO/IEC 42001:2023; NIST COSAiS.