AI Security Frameworks: What Actually Changes Your Build

Short answer: An AI security framework is a governance layer — policy, roles and process — that only becomes real where it is converted into controls you can test: a record with a retention rule, a deployment gate with a numeric threshold, a recurring evaluation cadence with an owner, a human-approval step before consequential actions, and evidence obtained from suppliers. Three frameworks ask for those controls in different languages: the NIST AI Risk Management Framework (voluntary, outcome-based), ISO/IEC 42001 (a certifiable AI management system) and the EU AI Act (law for the systems it classifies as high-risk). This page reads all three for one question: which requirements change how you build, and which stay paper.

Key takeaways

• Frameworks describe outcomes; controls are what you build. The NIST AI RMF names four functions — Govern, Map, Measure, Manage — and leaves the implementation to you, so only a few of its subcategories demand an artefact you can show.
• ISO/IEC 42001 is the one built for an audit. As a management-system standard it requires documented policy, a risk and impact assessment, internal audit, management review and supplier control, which means it creates records by construction.
• The EU AI Act is the only binding text here, and only for high-risk systems. The build-relevant duties are logging with traceability, technical documentation, human oversight and post-market monitoring.
• Five controls carry most of the weight. Log retention, evaluation frequency, a deployment gate, a human review step and supplier evidence — each is testable, and each can be answered differently by the three frameworks.
• Start with the framework that binds you, not the one that sounds best. Map it to those five controls, and write down the cadence and the retention before you buy a tool.

What an AI security framework has to decide

An AI security framework is not a product and not a checklist you finish; it is the governance layer that decides who is accountable for an AI system, which risks are tolerable, and what evidence proves that the decision was made. The vocabulary is deliberately broad, because the frameworks were written for every sector at once. The NIST AI Risk Management Framework is intended for voluntary use and aims to improve the ability to "incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems" (NIST AI RMF). ISO/IEC 42001 is a management-system standard an organisation can be certified against. The EU AI Act is a regulation, not a recommendation.

Those three differences — voluntary, certifiable, legal — decide almost everything about how much work each framework creates. The three also share a vocabulary of properties rather than a set of prescriptions. AI RMF 1.0 lists the characteristics of trustworthy AI as valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. Those characteristics are goals; a control is the mechanism that makes one of them checkable. The same split runs through roles: the Act distinguishes a provider from a deployer, and NIST expects roles and responsibilities to be documented (GOVERN 2.1) precisely because the control that applies depends on who is holding the system. The rest of this page maps each framework onto the same short list of controls, so you can see where the three agree, where only one of them bites, and where a framework is satisfied by a paragraph rather than by a change to your system.

What these frameworks mostly exist to bound is one specific failure: an instruction that reaches the model from an untrusted source and is obeyed. That problem is the subject of the cluster's centre page on what prompt injection is and why an agent changes it; this page stays with the governance layer that tries to make the resulting risk measurable and owned.

The NIST AI RMF: Govern, Map, Measure, Manage

The NIST AI Risk Management Framework, AI RMF 1.0, was released on 26 January 2023 and is intended for voluntary use. Its companion Playbook offers "suggested actions, references, and related guidance to achieve the outcomes for the four functions in the AI RMF: Govern, Map, Measure, and Manage" (NIST AI RMF Playbook). A Generative AI Profile, NIST AI 600-1, was added in July 2024 and restates the same four functions for generative systems (NIST AI 600-1).

The four functions are a division of labour, not a sequence. Govern is cross-cutting: it sets policy, roles and risk tolerance, and is "designed to be a cross-cutting function to inform and be infused throughout the other three functions" (AI RMF 1.0). Map establishes context — the intended purpose, the users, the legal setting. Measure analyses and tracks risk, and the framework states that AI systems "should be tested before their deployment and regularly while in operation". Manage allocates resources to the risks that were mapped and measured, including response and recovery.

What makes the framework useful is also what makes it easy to leave on paper: it prescribes outcomes, not controls. The controls appear only when a subcategory is read closely. GOVERN 1.5 expects that ongoing monitoring and periodic review "are planned and organizational roles and responsibilities clearly defined, including determining the frequency of periodic review". MAP 3.5 expects the "processes for human oversight" to be "defined, assessed, and documented". MEASURE 2.6 expects the system to be "evaluated regularly for safety risks". MANAGE 4.1 expects post-deployment monitoring to cover "appeal and override, decommissioning, incident response, recovery, and change management". None of these names a product; each of them implies a record and a cadence.

The Generative AI Profile is where the abstract functions become a work list. It defines twelve risks unique to or exacerbated by generative AI — among them confabulation, harmful bias, information security (which it describes in terms of prompt injection and data poisoning) and value chain and component integration — and then offers suggested actions tagged to the function and subcategory they serve. The action identifiers carry the mapping: GV for Govern, MP for Map, MS for Measure and MG for Manage, so GV-1.1-001 sits under GOVERN 1.1, "legal and regulatory requirements involving AI are understood, managed, and documented". That tagging is the useful artefact, because it lets a team ask which of the four functions a proposed control is meant to serve, and whether anything in the plan actually serves it.

AI security architecture: where a control can actually sit

Before the mapping, it helps to fix the places a control can physically exist, because a framework requirement only bites where it attaches to something. In an AI system that reaches tools and data, four seats are available: the identity and credential a caller presents, the tool call itself, the data that flows into and out of the model, and the record written afterwards.

Each seat has an owner. The identity seat decides who or what may call — the subject of agent identity and non-human credentials. The tool seat decides what any caller may run, which is also where the model and dependency supply chain enters. The data seat decides what the model may read and emit. The record seat decides what evidence survives the request. A governance framework that does not land on one of those four seats is describing an intention; one that lands on a seat changes configuration, code or retention.

Mapping the frameworks to AI security controls you can test

The three frameworks overlap far more than their vocabularies suggest. Read together, they reduce to six controls, and every one of them can be tested by asking for a specific artefact rather than a policy statement.

Control	NIST AI RMF	ISO/IEC 42001	EU AI Act (high-risk)	How you test it
Records and retention	MANAGE 4.1 monitoring; MEASURE 2.8 traceability	Clause 7.5 documented information	Logging of activity to ensure traceability of results	Ask for one stored call record and the rule that sets its lifetime
Evaluation cadence	MEASURE 2.6 evaluated regularly; action MS-4.2-001 regular cadence	Clause 9.1 monitoring and measurement	Post-market monitoring system	Ask when the last evaluation ran and when the next is scheduled
Deployment gate	MANAGE 1.1 proceed decision; action GV-1.3-002 thresholds	Clause 6.1 risk assessment and risk treatment	Risk assessment and mitigation systems	Ask for the approval record and the threshold that was applied
Human oversight	MAP 3.5 defined oversight processes	Clause 5.3 roles, responsibilities and authorities	Appropriate human oversight measures	Ask which actions require approval and who granted it
Supplier evidence	GOVERN 6.1 third-party entities; MANAGE 3.1 regularly monitored	Management of suppliers, partners and third parties	Role-dependent	Ask for the model or system card and the incident contact
Incident response	MANAGE 2.3 recover; MANAGE 4.3 communicate	Clause 10.2 nonconformity and corrective action	Reporting serious incidents and malfunctioning	Ask for the last post-mortem and the corrective action it produced

Two things stand out in that table. The first is how often the three columns describe the same artefact: a record, a schedule, an approval, or a document a third party supplied. The second is that only one column is law, and only for a defined class of systems. The next sections take each framework in turn, then return to the two controls that most often exist in name only.

ISO/IEC 42001: an AI management system you can be audited against

ISO/IEC 42001:2023, published in December 2023 by ISO/IEC JTC 1/SC 42, is the first international management-system standard for AI. It "specifies the requirements and provides guidance for establishing, implementing, maintaining and continually improving an AI (artificial intelligence) management system within the context of an organization", and it is written to sit alongside the other management-system standards rather than to replace them (ISO/IEC 42001:2023).

The standard is organised the way an auditor expects. Clause 5 requires leadership commitment, an AI policy, and documented roles, responsibilities and authorities. Clause 6 requires an AI risk assessment, risk treatment and an AI system impact assessment. Clause 7 requires documented information, which is the evidence layer. Clause 9 requires monitoring and measurement, an internal audit programme and a management review; clause 10 requires corrective action and continual improvement. Annex A is a normative set of reference control objectives and controls, and Annex B supplies implementation guidance for them. The Introduction calls out one process in particular: the management of "suppliers, partners and third parties that provide or develop AI systems for the organization".

The standard deliberately avoids prescribing management technique. Its Introduction says the organisation "can combine generally accepted frameworks, other International Standards and its own experience" to implement risk management, life-cycle management and data-quality management, and that the management system "should be integrated with the organization's processes and overall management structure". The clauses are harmonized across management-system standards — the same high-level structure used by quality, security and privacy systems — which is why a company that already runs one of those finds the shape familiar. Certification for ISO/IEC 42001 is voluntary, and adopting the standard is a strategic decision rather than a legal duty.

The practical consequence is that ISO/IEC 42001 is the framework that changes what you must produce and keep. A management system is auditable only if the policy, the risk register, the internal-audit record and the management review exist as documents on a schedule. Certification itself is voluntary and is performed by independent bodies, not by ISO. The standard's own framing is the honest one: a conforming organisation "can generate evidence of its responsibility and accountability regarding its role with respect to AI systems". Evidence is the deliverable.

The EU AI Act: the compliance duties that change a build

The EU AI Act, Regulation (EU) 2024/1689, is "the first-ever comprehensive legal framework on AI worldwide" and takes a risk-based approach (European Commission — AI Act, overview). It defines four levels of risk: unacceptable risk, high risk, transparency risk, and minimal or no risk. Most systems in use sit in the last group and attract no specific rules; prohibited practices and AI literacy obligations applied from February 2025.

For systems the Act classifies as high-risk, the obligations are the ones that reach into engineering. The Commission lists them as: adequate risk assessment and mitigation, high-quality datasets, "logging of activity to ensure traceability of results", detailed documentation, clear information to the deployer, "appropriate human oversight measures", and a high level of robustness, cybersecurity and accuracy. After a system is on the market, providers operate a post-market monitoring system and report serious incidents and malfunctioning. Providers of general-purpose AI models carry transparency duties, and those whose models may pose systemic risks must assess and mitigate them; the rules on general-purpose AI applied from August 2025. Transparency duties — telling a user they are interacting with a machine, and making generated content identifiable — apply from August 2026. The high-risk rules for the sensitive areas listed in the Act apply from 2 December 2027, and for high-risk systems embedded in regulated products from 2 August 2028.

The build-relevant subset is narrow and concrete: if you are a provider or deployer of a high-risk system, you must keep logs, keep technical documentation, and provide a human-oversight mechanism. The Act does not fix a number of days for those logs. It requires that the logging exists and that the records are kept and traceable, which makes retention a decision you have to make and defend rather than one the text hands you.

Enforcement is split, and the split is itself a control question. From 2 August 2026 the Commission's AI Office holds enforcement powers over general-purpose AI models and can request technical documentation, evaluate models, require corrective measures and issue fines. For high-risk systems, market surveillance sits with national authorities, while deployers ensure human oversight and monitoring and providers run post-market monitoring. When you assign an owner to each control, that division tells you which one is yours.

Evaluation frequency and human review gates

Two controls deserve their own section because they are the ones that most often exist in name only: how often you evaluate, and where a human must approve before the system acts.

Evaluation frequency is a count you can write down. NIST's MEASURE 2.6 asks whether the system is "evaluated regularly for safety risks", and the Generative AI Profile's suggested action MS-4.2-001 says to "conduct adversarial testing at a regular cadence to map and measure GAI risks". ISO/IEC 42001 puts the same idea in a management-system shape: clause 9.1 requires monitoring, measurement, analysis and evaluation, and clause 9.3 requires a management review at planned intervals. A defensible cadence has three triggers: a full evaluation before any deployment, a fixed interval for the deployed system, and an event-driven re-run after a material change — a new tool, a new model version, a new data source.

A human review gate is a decision about which actions may run unattended. NIST MAP 3.5 expects the processes for human oversight to be defined and documented, and MANAGE 2.4 expects responsibilities for deactivating a system that behaves outside its intended use. The gate becomes real when it names the action classes that require approval — writes, sends, payments, deletions — and when the approval itself is recorded with the actor who gave it. A gate that lives only in a prompt is not a gate: describing a tool as read-only in the system prompt is not the same as removing its write capability.

Supplier evidence and AI security guardrails

Third-party components are where a governance framework meets a procurement conversation. The NIST AI RMF addresses this directly: GOVERN 6.1 expects "policies and procedures ... that address AI risks associated with third-party entities", and MANAGE 3.1 expects that "AI risks and benefits from third-party resources are regularly monitored". ISO/IEC 42001 lists the management of suppliers, partners and third parties among the processes its management system must cover. The Generative AI Profile names the underlying risk — value chain and component integration — as "improper supplier vetting across the AI lifecycle". The evidence to request is unglamorous: a model or system card that states intended use and limitations, a data-provenance summary, evaluation results, a version or digest you can pin, and an incident-notification contact.

Guardrails belong beside that evidence, not in place of it. Filters and classifiers are one input at the measurement layer, and because they are probabilistic they cannot by themselves satisfy a framework requirement: a control that is expected to hold has to be deterministic or gated by a human. Where the guardrail products sit on the request path is the subject of where AI security guardrails sit; the prioritised control list most teams work from is the OWASP Top 10 for LLM Applications, and the method that turns a cadence into evidence is adversarial testing as a red-team routine.

Which of the three actually changes a build

Read as a set, the three frameworks are not equal in force, and it is worth saying so plainly.

Paper by itself. The NIST AI RMF is voluntary and outcome-based: adopting it as a reading exercise changes nothing, because it asks you to document and measure rather than to configure. Crosswalks between frameworks are useful maps and nothing more, and a policy that no one tests is a paragraph rather than a control. For most applications, the AI Act's prohibitions and transparency duties also leave the build alone.

Binding, and therefore build-changing. ISO/IEC 42001 binds the moment an audited customer or a procurement process requires it, because certification demands records, a schedule and supplier control. The EU AI Act binds a provider or deployer of a high-risk system to logging, documentation, human oversight and post-market monitoring, whatever the size of the team.

It is worth walking one system through the three, because the abstract force becomes concrete fast. Take an agent that reads support tickets and drafts replies. It is not a high-risk use case, so the Act's high-risk duties do not attach, though the transparency duty to disclose a machine interaction may. ISO/IEC 42001 would ask a certified company for a policy, a risk assessment, an audit record and supplier control around the agent's model dependency. The NIST AI RMF would ask for GOVERN 6 checks on that supplier, MEASURE 2.6 regular evaluation, and a documented process for human oversight. The work is not three programmes; it is the same four artefacts applied to one system.

The test that separates them. A framework requirement changes a build only when you convert it into one of four things: a record with a retention rule, a gate with a numeric threshold, a cadence with a named owner, or an evidence artefact obtained from a supplier. Anything that does not produce one of those four is documentation, and documentation is worth exactly what the first audit finds in it.

The order of the gates on every request, read from our own middleware

A security framework is a sequence, and the sequence is testable. Ours is stated in one file, read on 2026-10-07 from backend/smartgate/core/auth_middleware.py.

• Authentication is a pure ASGI middleware, and the reason is written down: the framework's own convenience middleware buffers the response body, which breaks streaming to clients that hold a long-lived connection. Transport correctness chose the architecture here, not taste — and that is the kind of decision a security review should land on explicitly, because the same buffering "fixes" a lot of problems while quietly breaking one surface.
• The gates run in a fixed order, and the order is the control: parse the request's settings document, authenticate, resolve the plan's limits, apply rate limiting, bind the request context, handle, audit. Each gate assumes the previous one succeeded, which is why an out-of-order gate is a real defect rather than a style question.
• Rate limiting is checked in two flavours — the REST surface and the MCP surface — against the same plan resolution. Two entry points, one policy: the alternative is a framework whose limits differ depending on how the caller connected.
• Denials are indistinguishable in shape from successes, arriving as the same envelope with a structured error. A refused call still produces an auditable record; if it did not, the most security-interesting events would be the ones missing from your logs.
• The quiet gate is context binding. It grants nothing, and it is what makes every later record attributable. Dropping it does not open a hole in access control — it opens one in accountability, which is harder to notice.

Where SmartGate fits

SmartGate does not make an organisation compliant with any framework, and this page will not claim that it does. What it provides is one of the seats above — the record — and the enforcement point that keeps the record honest. SmartGate is an MCP-native algorithm gateway for token control, traffic shaping and agent audit: a single authenticated endpoint through which an agent reaches its tools, with per-key metering and an audit record written as calls happen. Seven tools are exposed through it — smart_fetch, smart_search, smart_context_gate, smart_dedup, smart_budget_guard, smart_memory and smart_pipe — and each call is counted against the caller's key, which is what makes "who did this" answerable after the fact.

Against the control table above, that is two rows: the retained record and the deployment gate. The audit record is the evidence layer that a management system, an incident review or a regulator asks for, and the surfaces are documented on audit and compliance surfaces. The per-key limits are the enforcement half: a budget or a rate limit is a control that holds regardless of what any detector decides. Plan limits move with the tier — monthly token caps of 2M, 20M, 100M and 200M+, MCP requests per minute per key of 120, 300, 600 and 1200, audit-log retention of 7, 30, 90 or 180 days — so the pricing page is the authoritative table, and a retention requirement longer than 180 days is a reason to talk to sales rather than to assume.

How to get started

1. Identify the framework that binds you. Legal counsel or a customer contract decides this, not preference: a high-risk EU deployment and an ISO/IEC 42001 procurement requirement produce different work, and most systems are governed by neither.
2. Inventory the systems in scope. NIST's GOVERN 1.6 expects an inventory of AI systems, and you cannot map a control onto a system you have not listed.
3. Write the four artefacts. The retention rule, the deployment threshold, the evaluation cadence and the supplier evidence list. Each is one page, and each is testable.
4. Turn one of them into a gate. A deployment approval with a numeric threshold is the cheapest control that changes behaviour, because it blocks rather than documents.
5. Set the cadence and name the owner. An evaluation with no owner and no next date is a one-off, not a control.
6. Route tool calls through a place that records them. Start free and watch a call end to end before trusting a retention claim; the pricing page tells you which tier real volume needs.

Limitations

This page compares three frameworks by the controls they imply; it is not legal advice, and it is not a complete reading of any of them. The AI Act is long, its timelines have been amended, and which duties apply depends on your role and on the risk classification of each system, which only the text and your counsel can settle. ISO/IEC 42001's Annex A controls are normative, but the standard is not free to reproduce here, so this page describes its structure rather than quoting every control.

The mapping table is a reading aid, not an official crosswalk, and it flattens real differences: the three frameworks use different risk vocabularies and were written for different purposes. Where a source describes a requirement without naming a numeric threshold, this page supplies no number. Product facts are limited to the control-plane facts this project records, and SmartGate is described only as the record and the enforcement point, not as a compliance solution.

Sources

• NIST — AI Risk Management Framework and the AI RMF Playbook.

• NIST — AI RMF 1.0 (NIST AI 100-1), for the four functions, the trustworthy AI characteristics and the subcategory list.

• NIST — Generative AI Profile (NIST AI 600-1), for the generative AI risks and the suggested actions mapped to Govern, Map, Measure and Manage.

• ISO/IEC — ISO/IEC 42001:2023 preview, the official IEC preview of the AI management system standard.

• European Commission — AI Act, for the risk levels, the high-risk obligations and the application timeline.

• European Commission — AI Act overview, the Commission's second official landing page for the regulation.

• Canadian Centre for Cyber Security — Top 10 artificial intelligence security actions, an example of a national guidance page that references the NIST AI RMF and ISO/IEC 42001 together.

• The section "The order of the gates on every request, read from our own middleware" is our own implementation, read on 2026-10-07 from backend/smartgate/core/auth_middleware.py (origin/main). It states only what those files state.

Method note

This page carries no code excerpt, and that is a recorded finding rather than an omission. The slice matcher pinned none of this page's seven sections: it returned six no-slice verdicts and one abstention. The one section with a single local hit was the section for ai security guardrails, where rule A matched a symbol named guard — a test fixture — and the confirmation step could not attach an asset to it, so the matcher abstained rather than pinning a fixture as evidence about guardrails. A pinned generic would have given the page the shape of a verified article with none of the substance, so every section but one above is written from external, linkable sources.

The framework statements quoted above are each source's own published wording, read at the URL cited beside them. Product facts were read read-only from the product source at the revision the slice run recorded, and the plan figures were re-checked against the live pricing page. No code, batch fingerprints, auction data or internal hosts are transcribed, so there is nothing here that has to be asserted verbatim.

The slice run for this page recorded 0 of 7 sections pinned, 1 abstention(s) and 6 no-slice verdict(s); BLOCKS is empty because the matcher found no unique symbol it could confirm as section-specific evidence, as the Method note above explains.