AI Security Framework: How to Build One That Works

Standards bodies give security teams a shared vocabulary for AI risk. They don't give you a Monday morning checklist. They don't tell you which AI tools employees opened this week, which agent can read the customer database or what left through a prompt yesterday. That gap is where sensitive data walks out.

The numbers show how wide it is. IBM's 2026 report found that shadow AI incidents more than doubled, from 20% to 43% of the breached organizations it studied, and those incidents averaged $5.39 million. Verizon's 2026 DBIR reports that 45% of employees are now regular AI users on corporate devices (defined as access at least once every 15 days), up from 15% in the prior report.

This guide builds an AI security framework around the one thing every AI system touches: your data. It follows Forcepoint's Know, Adapt, Protect model, puts one concrete step under each pillar and shows how the result lines up with NIST AI RMF and ISO/IEC 42001. The goal is a framework you can run, repeat and prove.

What Is an AI Security Framework?

An AI security framework is a repeatable set of steps that finds where AI touches your organization, sets rules for that contact and enforces those rules with evidence. The most useful ones cover three surfaces: sanctioned AI tools, shadow AI and autonomous agents.

Most published AI security frameworks catalog risks. A working framework adds sequence: what to do first, what to measure and where to enforce. Sequence matters because AI security starts as data security. Employees paste sensitive files into prompts. Assistants inherit permissions no one reviewed. Agents act on credentials no one scoped. In every case, the control that counts sits where AI meets data. That is the practical layer of an AI security program.

Where NIST AI RMF, ISO 42001 and OWASP Fit

Three references anchor most enterprise AI programs. Each answers a different question, and each leaves a gap.

NIST says it is revising AI RMF 1.0 as part of the White House AI Action Plan. Controls tied to your data hold up through that kind of change better than controls tied to document language. For the governance side in depth, see our guide to AI governance. The framework below borrows from all three references without trying to replace any of them.

The Know, Adapt, Protect AI Security Framework

The framework runs in three pillars: Know, Adapt and Protect. Each carries one step and one proof point. The sequence is the one behind Forcepoint AI Data Security, though the steps work with whatever tools you already run.

The NIST column is our reading of how the pieces line up. NIST doesn't define Know, Adapt or Protect.

Know: Map Every AI Touchpoint to Its Data

Step 1: Build one inventory across three surfaces

You can't secure AI you can't see, and you can't rank AI you haven't tied to data. Start with a single inventory that covers every surface:

• Sanctioned AI: approved assistants such as Microsoft 365 Copilot, ChatGPT Enterprise and Claude for Enterprise. Record the tenant, the connectors and the data stores each one can reach.
• Shadow AI: unapproved chatbots, browser extensions, personal accounts and coding tools. Record who uses them, how often and with what data.
• Agents: custom agents built on platforms such as AWS Bedrock, plus agents running on endpoints. Record the owner, the tools each agent can call and the identity it uses.

Keep the inventory current with AI usage monitoring rather than a quarterly spreadsheet. The inventory is rarely small. In Verizon's data loss prevention dataset, shadow AI is now the third most common non-malicious insider action, a fourfold increase in share from the prior year. Source code was the most common data type sent to external generative AI models, and 67% of users reach AI services on corporate devices through non-corporate accounts.

A tool list without data context can't set priorities. A note-taking assistant and a code assistant look alike until you see what each can reach. Forcepoint DSPM discovers and classifies sensitive data with AI automation, so every inventory entry carries a sensitivity rating before anyone writes policy.

The proof point for Know is a current inventory, owned by a named person, that maps each AI touchpoint to the data classes it can reach.

Adapt: Set Policy That Moves With Risk

Know tells you what exists. Adapt decides what each thing may do and keeps deciding as conditions change.

Step 2: Write policy by data sensitivity and identity

Start with three tiers that map to actions:

• Never allowed: credentials, regulated identifiers and unreleased financials
• Approved tenants only: customer records and internal documents
• Allowed with logging: public and low-sensitivity content

Then add identity. "Approved" is not a control until it names a tenant, so allow the corporate account and block the personal account on the same tool. Treat three actors differently: a person, an agent acting for a person and an autonomous agent with no human in the loop. Give each agent the narrowest scope that completes its task, not the full permissions of whoever built it.

Access is where programs fail first. IBM's 2026 report found that among organizations with an AI-related breach, 92% lacked proper AI access controls. Fix exposure before AI finds it with data access governance. If a user can open a file, the assistant working for that user can summarize it, so tighten sharing defaults, remove stale access and label what is unlabeled before you turn assistants loose.

Static rules age fast, so tie enforcement to risk. A first-time, low-risk event can draw a coaching prompt. Restricted data headed to an unapproved tool gets blocked. A sudden shift in behavior escalates for review. Graduated responses like these anchor insider risk best practices. Forcepoint Risk-Adaptive Protection applies adaptive risk scoring and user coaching so enforcement tracks behavior.

The proof point for Adapt is a documented set of policy tiers and risk signals that visibly change what the system allows.

Protect: Enforce Where AI Touches Data

Visibility without enforcement produces a report. Protect places a control at each of the three points where AI meets data.

Step 3: Enforce at the prompt, the access layer and the agent action

At the prompt

Every prompt is a data transfer. Inspect prompts, responses and file uploads with the same classifications that already govern email, web and endpoint traffic. Forcepoint DLP extends those policies to AI interactions, so teams reuse the taxonomy they built instead of starting over. Match the action to the risk: audit, coach, redact or block.

At the access layer

Classification decides what an assistant may retrieve, summarize or return. Connect sanctioned platforms through their APIs, log each session and revoke access to overshared files before an assistant ingests them.

At the agent action

Most agents run on shared service accounts, so identity checks alone can't tell one agent's action from another's. Forcepoint AI Agent Gateway sits between agents and the business applications they call. It registers each agent with an owner and approved tools, brokers temporary credentials, inspects responses at the field level and holds high-risk operations for human approval. Every transaction lands in an audit record. A manipulated agent still can't act outside its registered scope.

Model-level threats such as jailbreaks call for runtime guardrails and red teaming alongside this data layer. The framework above covers the data those threats try to reach.

The proof point for Protect is a log that shows who or what acted, on whose behalf, on which data and what policy decided. That record also supports compliance readiness for NIST AI RMF and ISO/IEC 42001 reviews.

Pressure Test Your AI Security Framework

Run these six questions. A good answer names a log, a policy or a dashboard, not an intention. Score each one yes, partly or no. A no in Know undermines everything after it.

Start With the Data

The standards will keep changing. NIST is revising its framework, and new rules keep arriving. The data your AI tools touch is the constant. Inventory it, set policy around it and enforce where AI meets it, and you have a framework that survives each revision. For control-level detail, see the AI security best practices checklist. For a deeper look at all three surfaces, read the enterprise AI data security guide.

AI Security Framework FAQs

What are the main AI security frameworks?

The most cited are NIST AI RMF for risk governance, ISO/IEC 42001 for AI management systems and the OWASP Top 10 for LLM applications for application risks. Google SAIF and MITRE ATLAS add design guidance and attack techniques. No single one covers every layer, so teams pair them with an operating model that turns each into controls.

How is an AI security framework different from AI governance?

AI governance sets accountability, policy and oversight. An AI security framework puts controls behind that policy: inventory, classification, enforcement and logging. Governance without enforcement leaves a policy no one can prove.

Does an AI security framework cover agents?

It has to. Agents act on business systems with real credentials and no person reviewing each step. Give every agent an owner, a narrow scope and brokered credentials, and log each action it takes.

Where should a team start?

Start with Know. Build the inventory, then classify the data each entry can reach. Policy and enforcement both depend on that work.