AI Security Governance: The 2026 Controls That Hold

Every AI system in production should have a record of how it was approved. AI security governance is the set of controls behind that approval.

To see which of those controls work in practice, I went through five frameworks (NIST AI RMF, ISO/IEC 42001, the EU AI Act, the OWASP LLM Top 10, and MITRE ATLAS). My recommendation is to enforce checks in the pipeline first and form the committee after that.

What is AI security governance?

AI security governance applies security safeguards to AI systems through policy, named ownership, and enforcement coded into the tooling, so each one is reviewed against the same written criteria.

Those criteria settle who can develop with AI, what data those tools can reach, what actions they can take without a person involved, and what gets logged when they act.

Broader AI governance, which operates at a higher level, decides whether a project should exist at all. AI security governance then checks whether that project is safe to run once it's live.

The control layers of an AI security governance program

The program works across four layers, and one that covers only one or two of them leaves the others exposed.

• Model layer. The inputs that can steer the model. Prompt injection belongs to this layer, and so do jailbreak attempts.
• Data layer. Everything the model can reach. A model with read access to a shared drive can see the files stored there, including sensitive ones that happen to sit in that drive.
• Identity and permission layer. What the system is allowed to do once it acts. At this layer, a bad output can lead to a deleted record.
• Evidence layer. The record left after each interaction. Without a way to reconstruct who triggered what, you have little evidence that the other three layers work.

The evidence layer also carries legal weight. For high-risk AI, Article 12 of the EU AI Act requires the AI to record event logs over its lifetime.

Article 26 then requires deployers to keep those logs for at least six months, so this layer needs planning before launch.

How does AI security governance work?

It works by pairing each way an AI system can cause harm with a control, and each control with an artifact. When an auditor asks to see a control in action, that artifact is what you show them.

In practice, the work starts with an inventory of every AI system. From there, you classify each one by what it can damage, assign an owner, enforce the rules in the deployment pipeline, and log the result where an auditor can read it.

The AI attack surface it has to cover

The attacks these controls address are already happening. In March 2026, Unit 42 documented indirect prompt injection in the wild and cataloged 22 distinct payload techniques used against live AI agents.

The report also shows where attackers placed those payloads. Roughly 38% appeared in visible plaintext on the page, and another 17% were concealed in CSS that suppressed rendering, so a human reviewer wouldn't see them.

Industry frameworks track these risks in detail. OWASP ranks the model-layer risks in its Top 10 for LLM Applications 2026, placing prompt injection (LLM01:2026) first and excessive agency (LLM03:2026) among the highest-impact risks.

MITRE ATLAS covers the attacker's side of the same problem. Its v2026.08 release lists 16 tactics, 114 techniques, and 83 sub-techniques aimed at AI systems.

Our guide to enterprise LLM security explains each framework in turn. Governance adds one step on top by tying every threat to a control that a specific person owns.

Shadow AI adds to the attack surface as well. Verizon's 2026 Data Breach Investigations Report (DBIR) found that 45% of employees now use AI regularly on corporate devices, authorized or not, up from 15% a year earlier.

The same report found that 67% access AI services through non-corporate accounts. Your controls have little reach into those accounts, which is why shadow AI security belongs in the governance program.

Mapping threats to controls to evidence

The table below lines up each common threat with what stops it and what proves it. Assign an owner to every row.

Without a table like this, each team needs to create its own mapping between OWASP risks and NIST AI RMF functions.

A typical failure

Take a hypothetical case. A team ships a useful internal app, connects it to a database with credentials someone already had, and shares the link in a Slack channel.

For months, the problem goes unnoticed. Then the model answers a question by retrieving a row it shouldn't have accessed, a customer reports it, and legal asks for an access log that doesn't exist.

The pattern shows up in IBM's data. Its Cost of a Data Breach Report 2026 found that 92% of organizations that had an AI-related security incident lacked proper AI access controls.

How does AI security governance differ from AI governance?

The two differ in scope and in what triggers each one. AI governance is the wider program covering ethics, bias, business risk, and legal exposure. AI security governance is the security part of it, and it responds to threats and access questions.

Both programs rely on the same audit trail, so the handoff between them needs clear rules. Permissions in particular need a single named owner, and NIST AI RMF GOVERN 2.1 backs this by requiring documented roles and responsibilities for managing AI risk.

Choosing a starting point

If you already run AI in production, secure it first, because GDPR Article 32 requires appropriate security measures whenever personal data is processed. This also applies when leadership still calls a live deployment a pilot, since the data exposure is identical.

Teams still in pilots, with nothing touching customer data, should settle the wider program first, since that decides which prototypes need security work.

Strengths and weak spots of AI security governance

Strengths

Enforcement in the deployment pipeline. Code-based checks run as part of each deploy, while a rule kept in a document depends on people remembering to apply it. If your policy requires a permission review before production, make it a mandatory step in the deployment.

Classification by impact level. Rank each deployment by the damage it could do. The EU AI Act takes a similar approach, since Annex III defines high-risk systems by use case.

One named owner per system. Name one person a regulator could contact. For high-risk systems, this is also a legal expectation, since Article 26 of the EU AI Act requires deployers to assign human oversight to natural persons with the necessary competence, training, and authority.

Evidence captured by the platform. Audits need logs from everything in scope. When the platform writes them, developers have one less manual step to forget. Our breakdown of what belongs in an AI audit trail lists the specific fields, and governance should make the core ones mandatory.

Weak spots

Agent coverage in the frameworks. NIST AI RMF 1.0 was released in January 2023 and ISO/IEC 42001 in December 2023. NIST has also said the RMF is being revised under the White House AI Action Plan.

OWASP added agent-specific guidance on December 9, 2025, when it published its Top 10 for Agentic Applications and named agent goal hijack, tool misuse, and rogue agents as separate risks.

Company plans are moving quickly as well. In Cisco's State of AI Security 2026 report, 83% of organizations planned agentic deployments.

Only 29% felt ready to run them securely, which leaves a 54-point difference between what companies plan to deploy and what they feel ready to secure.

Approval friction. An engineer who files a request waits for approval, while a colleague using a personal account skips that wait. With a two-week turnaround, the process can end up penalizing the people who follow the rules.

Program metrics. An inventory count tells you how many AI systems exist. NIST AI RMF GOVERN 1.5 asks for more, calling for ongoing monitoring on a defined schedule, and coverage percentages and mean time to revoke access are how you measure it.

Do you need AI security governance?

If AI touches anything a customer or regulator cares about, you need it now, because the EU deadlines are set in law.

The Digital Omnibus on AI (Regulation (EU) 2026/1744) postponed the AI Act's high-risk obligations. Chapter III now applies to Annex III systems from December 2, 2027, and to Annex I systems from August 2, 2028.

The postponement changes the timeline. For prohibited practices, Article 99 sets fines of up to €35 million or 7% of worldwide annual turnover.

When you need it now

• Any AI system has write access. OWASP LLM03:2026 recommends human approval for high-impact actions, such as deletions, before they run.
• You're in a regulated sector. In healthcare, the HIPAA Security Rule protects electronic health information that a covered entity or business associate creates, receives, uses, or maintains. A pilot that handles that data falls under the rule too.
• Employees run AI you didn't approve. Gartner expects more than 40% of enterprises to experience a security or compliance incident linked to unauthorized shadow AI by 2030, and 69% of organizations suspect or have evidence that employees use prohibited public GenAI.
• You're deploying agents. OWASP LLM03:2026 names excessive autonomy as a direct cause of damaging actions.

When you can scale it down

• You're a small team on public or synthetic data. With no live deployments yet, run a lightweight version with an inventory sheet, one owner, and a review before anything connects to a production datastore.
  
  That covers the inventory mechanism described in NIST AI RMF GOVERN 1.6, and you can expand on it before anything goes live.

• You're piloting on a certified vendor platform. Request the vendor's SOC 2 Type 2 report and document the controls it covers. Then focus your own work on the integration points.

How to implement AI security governance in 7 steps

1. Inventory every AI system, including undocumented ones

Start with the ones on record, then search for the unregistered ones. Pull the list from expense reports, SSO logs, browser telemetry, and the API keys issued in the last year.

Add every generative AI tool you find to the inventory, as NIST AI 600-1 action GV-1.6-001 recommends. Any tool that wasn't on the official list becomes the first issue on record.

2. Classify every system by impact level

Score each one on the data it can read and the actions it's allowed to take, then note whether a human reviews the output before anything happens.

Those scores set the classification. An assistant that reads customer records and can send email belongs in the high-risk tier, and a summarizer for public documentation goes in the low-risk one, regardless of the underlying model.

To keep those calls consistent, write the rubric down so two people classify the same system the same way.

3. Assign a named owner to every system

The owner is one person who answers for the system's behavior and has the authority to disable it. NIST AI RMF MANAGE 2.4 asks for the same kind of assigned responsibility. Security sets the control standard, and the team that shipped the app owns it.

Decide early who arbitrates between the CISO and the AI strategy lead, and put that decision in writing before the first incident, while there's still time to negotiate.

4. Choose one primary framework

NIST AI RMF 1.0 is the base in this guide. Its four functions (GOVERN, MAP, MEASURE, and MANAGE) structure the work, and the Generative AI Profile (NIST AI 600-1), published in July 2024, adds guidance for model-specific risk.

The other two frameworks play different roles. If procurement asks for a certificate, ISO/IEC 42001 is a certifiable management system standard, and ANAB accredits the bodies that certify against it. The EU AI Act sets obligations you have to meet whichever framework you choose.

For the security layer, add the OWASP LLM Top 10 and MITRE ATLAS as supporting references. NIST's AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, helps when you need shared vocabulary with your red team.

Give yourself a deadline to choose, such as one week, and spend the rest of the time writing controls.

5. Write the rules into a policy people will follow

The policy should let someone who wasn't in the original discussion reach the same decision. To get there, map data classification levels to AI tool tiers, publish an approval path, and add an exception process for cases outside that map.

Keep the document short, and state the approval turnaround in business days. We cover the drafting process and sample language in our guide to writing an AI governance policy.

6. Instrument the evidence before you need it

Decide what every AI system should log, then have your tooling record it for the whole organization. At minimum, capture the model and version, the prompt and its context, the output, the identity of the requester, the data sources touched, and any human approval or override.

Send those logs to your SIEM so your security analysts see them in their daily review.

7. Red-team on a fixed schedule

Write the red-team cadence into the policy, since NIST AI RMF GOVERN 1.5 asks you to define how often reviews happen. This guide recommends quarterly red-teaming for high-risk systems, twice a year for the rest, and an extra round before a deployment gains new permissions.

Each round should cover the attack types NIST AI 600-1 action MS-2.7-007 lists, including prompt injection and data poisoning. Within that scope, work through the attacks in a set order.

Begin with indirect injection hidden in documents the application ingests, then move on to permission escalation through chained tool calls, and finish by testing whether summaries can leak sensitive data. Log every result in its inventory entry so the test history stays with the app.

Metrics that tell you AI security governance is working

These four metrics show whether the steps above are holding. Track them from month one. The thresholds below are starting points this guide recommends, so adjust them to your risk tiers.

AI security governance best practices

Recommended practices

Make the approved path faster than the unapproved one. Microsoft and LinkedIn's 2024 Work Trend Index found that 78% of AI users bring their own tools to work, so the approved option needs to be at least as fast.

Banning those tools, in my view, pushes the demand to personal devices and accounts, where security has limited visibility. An approved tool with a two-day turnaround gives employees a legitimate route that's quick enough to use.

Treat AI systems like production services. Apply the same version control, code review, staged deployment, and rollback plan you use for your backend services.

That consistency also helps at audit time. Keeping AI apps in your existing SDLC lets one change-management record serve both software and AI audits, and NIST AI RMF MANAGE 4.1 lists change management as part of post-deployment monitoring.

Inherit controls where you can. Set up permissions, SSO, and logging once, at the platform level. Each new app then inherits those settings when it's created.

Review permissions on a fixed schedule. Access granted for a pilot stays active until someone revokes it. A quarterly review of what each deployment can still reach keeps outdated access from lasting more than three months.

Costly mistakes

Model-first reviews. A team can spend weeks evaluating a model's safety training and then connect it to a production database with an admin credential. The exposure comes from that credential.

Vague tiers. Loose tier descriptions let each reviewer read them a different way. Tie each tier to observable facts, such as data class touched, write access yes or no, and human in the loop yes or no, so two reviewers scoring the same deployment reach the same result.

Audit trails left to individual teams. IBM's Cost of a Data Breach Report 2026 found that 21% of organizations had a breach involving AI models or applications, up from 13%, and that the share involving shadow AI more than doubled, from 20% to 43%.

Weak logging makes those incidents harder to investigate. When every group has to remember to log its own activity, records go missing right where those breaches happen. And 92% of the affected organizations lacked proper AI access controls in the first place.

My verdict on AI security governance

I'd argue AI security governance becomes urgent once an AI system can act without a human in the loop. Before then, it's good baseline practice. After that, its logs become records that Article 26 of the EU AI Act requires deployers of high-risk systems to keep.

The core work consists of four tasks. Keep an inventory of everything in use, map what each one can reach, give each one an owner, and let the tooling capture the proof. The frameworks add detail on top of those tasks.

I disagree with the usual advice on a single point, the role of the committee. Put the pipeline controls in place first and shape the governance structure around them, bringing in review boards, charters, and maturity models once those checks are running.

Where that enforcement lives matters too. If your AI apps run on a platform that centralizes RBAC and logging, they're set once in its configuration. If a dozen teams assemble their apps ad hoc, you'll repeat the same work for each one.

Govern AI where apps are created

Setting these rules at app creation reduces the need to retrofit existing apps later. Superblocks takes that approach. Its safeguards apply to apps made on the platform, so browser-based AI tools that employees use elsewhere still require your own discovery and DLP.

Superblocks positions its product as a way for business teams to create production software in your AWS private cloud while IT and security control integrations, permissions, auditing, and policy agents. Across those apps, it applies the safeguards below.

• Inherited roles. Superblocks says its RBAC supports custom roles across all resources, and apps inherit them along with row-level permissions.
• Data plane inside your VPC. With a Hybrid or Cloud-Prem deployment, Superblocks runs the data plane in your AWS, GCP, or Azure VPC and handles database queries and code execution there, which also means your staff runs and maintains that infrastructure.
  
  Superblocks describes the agent as open source, and your security team can review its code on GitHub.

• Integration control layer. API and MCP authentication and secrets management sit between AI apps and your business systems. Superblocks presents this layer as the checkpoint between an agent and the systems it calls.
• Audit Logs. According to Superblocks' documentation, every database query and API call is audited centrally, with developer and end-user activity sent to your audit pipeline or SIEM. That gives you an evidence trail for apps on the platform.
• Clark. Superblocks' AI agent generates internal apps from a prompt and uses Clark knowledge to apply your design system and integration permissions.
  
  It also enforces org-wide security policies such as PII masking and audit logging, along with RBAC and ABAC through Okta or Microsoft Entra ID groups.

• SOC 2 Type 2 and HIPAA coverage. Superblocks' AI features are within the scope of its SOC 2 Type 2 report, and HIPAA is listed in its Trust Center.

The point of all that is to keep the controls on while non-specialists build. At Matthews, a marketing manager with no coding background built an app that generates offering memorandums, cutting a 3 to 5 day process down to 12 hours, with governance intact the whole way.

To see how this works in practice, start with the Superblocks docs.

Frequently asked questions

What is the difference between AI governance and AI security?

The main difference between AI governance and AI security is scope. AI governance spans the policies that decide how an organization develops and uses AI, including ethics and business risk. AI security handles the technical defenses that protect that AI from attack and misuse.

Is AI security governance required by law?

Several laws require the controls and records an AI security governance program produces. The EU AI Act mandates risk management, human oversight, record-keeping, and cybersecurity measures for high-risk systems, with those obligations applying from December 2, 2027, for Annex III systems.

Other rules reach AI through the data it handles. GDPR and HIPAA apply as soon as AI touches covered data, and SOC 2, an audit framework, examines many of the same controls. Each of these sets its own requirements, so one set of controls can map to several of them at once.

Which framework should we use for AI security governance?

NIST AI RMF 1.0 is a practical base framework because NIST publishes it at no cost for voluntary use, and it organizes controls into GOVERN, MAP, MEASURE, and MANAGE.

From there, add ISO/IEC 42001 if you need a certificate for procurement, and add the OWASP LLM Top 10 plus MITRE ATLAS for the threat details those two frameworks don't include.

How do you govern AI agents differently from AI models?

You govern agents mainly by controlling the actions they can take. A model needs input filtering and output handling, and an agent needs those same controls plus a few more.

Those additions are scoped tool permissions, a separate identity for the agent, spend and rate limits, and a human approval gate on high-impact or irreversible actions. OWASP's Top 10 for Agentic Applications describes the threat classes specific to agents.

What's the best tool for AI security governance?

One workable setup pairs model monitoring and a SIEM for evidence with an app platform like Superblocks, which applies RBAC and audit logging to the apps on it and can keep execution inside your VPC with a Hybrid or Cloud-Prem deployment.

The app platform matters because it's one place where controls can be enforced in code, and it determines which apps inherit them.