For CISOs and security leaders
AI Governance and Security Cheatsheet
What AI security covers, which frameworks and laws apply, and the controls that do most of the work, on one page. It's the governance companion to our AI security reference architectures, which show how to build each control.
- Scope
- Four domains (staff use, AI in SaaS, AI-assisted development, AI in your product), with agents, the AI supply chain and governance cutting across all of them.
- Frameworks
- NIST AI RMF for structure, ISO 42001 to certify, CSA AICM for questionnaires, the OWASP LLM and Agentic Top 10 for engineering, AIUC-1 for agents.
- Next dates
- Dec 2, 2026 for EU AI content marking on systems already on the market; Jan 1, 2027 for California's ADMT rules and Colorado SB 26-189; Dec 2, 2027 for EU AI Act high-risk obligations.
- Start here
- Inventory every AI tool, feature and agent, then cap what agents can do without a human approving it.
Last reviewed October 2026. Dates and legal summaries are for orientation, not legal advice; confirm with counsel. Spot something out of date? Tell us.
1. AI security scope
Four domains, each with its own owner and controls, plus three layers that cut across all of them. Each domain links to the reference architectures that implement it.
2 AI in SaaS
AI features and agents switched on inside the SaaS you already pay for.
Owner: Vendor risk
3 AI-assisted development
Coding assistants, CI bots and autonomous coding agents.
Owner: AppSec + engineering
AgentsAI that acts, not just answers. Treat each agent as a non-human identity with scoped credentials and approval gates. B3T
AI supply chainModel providers, open-weight models, MCP servers, plugins and the vendors in between. A3A4
GovernancePolicy, risk tiering, vendor review, legal obligations and evidence.
Outside-in threatAttackers using AI: faster phishing, deepfaked voices, automated vulnerability discovery. Plan for it; don't govern it as a domain.
- Consume vs build. Domains 1 to 3 govern someone else's model. Domain 4 owns model behavior, the data path and liability to customers.
- Decisions about people. Models in domain 2 or 4 that screen candidates, score credit or flag fraud carry the heaviest legal obligations (EU AI Act Annex III, US state laws). Tag them.
- Agents. AI that acts, not just answers. Treat each agent as a non-human identity with scoped credentials and approval gates.
- Outside-in. Attackers using AI are a threat to plan for, not a domain to govern.
2. Scoping models
Domains set ownership, the AWS scoping matrices set how deep the controls go, and the legal risk tier sets what evidence you need.
| Model | Slices AI by |
|---|---|
| AWS Generative AI Security Scoping Matrix | Ownership: consumer app, enterprise app, pre-trained, fine-tuned or self-trained model |
| AWS Agentic AI Security Scoping Matrix | Autonomy: no agency, prescribed, supervised or full agency (see controls below) |
| CSA 3x3 enhancement | Agency (low, medium, high) crossed with data operations (read, write, both): nine scopes |
| EU AI Act roles | Provider or deployer; prohibited, high, transparency or minimal risk |
| NIST Cyber AI Profile | Secure AI, defend with AI, thwart AI-enabled attacks |
| Lifecycle (NIST AI RMF, ISO 42001) | Design, data, build, deploy, operate, retire |
3. Frameworks and standards
For a mid-market SaaS company: NIST AI RMF for structure, ISO 42001 when customers want a certificate, CSA AICM for vendor and customer questionnaires, the OWASP lists for engineering, and AIUC-1 if you ship agents.
| Framework | What it gives you | Status |
|---|---|---|
| NIST AI RMF 1.0 + Generative AI Profile (AI 600-1) | Govern, Map, Measure, Manage. The language most other frameworks map to. | Final; revision announced |
| ISO/IEC 42001 (+ 42005, 42006) | Certifiable AI management system with 38 Annex A controls. 42005 (May 2025) covers impact assessment; 42006 (July 2025) sets rules for certification bodies. | Final |
| NIST Cyber AI Profile (IR 8596) | AI outcomes mapped to CSF 2.0 across three focus areas: secure, defend, thwart | Preliminary draft, Dec 2025 |
| NIST COSAiS | Planned SP 800-53 control overlays for five AI use cases, including single-agent and multi-agent systems | Concept paper and outline; no draft overlays yet |
| CSA AI Controls Matrix (AICM) v1.1 | 247 control objectives across 18 domains, the AI-CAIQ questionnaire, and STAR for AI (Level 1 self-assessment, Level 2 with ISO 42001) | v1.1, June 2026 |
| AIUC-1 | Standard for AI agents: an accredited third-party audit plus adversarial testing | Quarterly; next Jan 15, 2027 |
| OWASP Top 10 for LLM Applications 2026 | Engineering risks. Top three: prompt injection, sensitive information disclosure, excessive agency. | Aug 2026 |
| OWASP Top 10 for Agentic Applications | Agent risks, from ASI01 agent goal hijack to ASI10 rogue agents | Dec 2025 |
| MITRE ATLAS | Adversary tactics, techniques and case studies for AI systems: 16 tactics and 120 techniques | Living; v2026.09 |
Which framework covers which domain
| Domain | AI RMF | ISO 42001 | CSA AICM | OWASP LLM | OWASP Agentic | AIUC-1 | EU AI Act |
|---|---|---|---|---|---|---|---|
| 1. Staff use | partial | primary | partial | partial | not covered | not covered | partial |
| 2. AI in SaaS | partial | primary | primary | not covered | partial | partial | partial |
| 3. AI-assisted development | partial | partial | partial | partial | primary | partial | not covered |
| 4. AI in your product | primary | primary | primary | primary | partial | primary | primary |
| Agents (all domains) | partial | partial | partial | partial | primary | primary | partial |
| Decisions about people | primary | primary | partial | not covered | not covered | not covered | primary |
● Primary◐ Partial
4. Regulations and requirements
For most mid-market SaaS companies, customer contracts and security questionnaires bite before any regulator does. These are the dated obligations to plan around.
- Feb 2, 2025EU AI Act prohibited practices and AI literacy duty (softened in July 2026)
- Aug 2, 2025EU AI Act duties for general-purpose AI model providers
- Jan 1, 2026Texas TRAIGA, California SB 53 and Illinois HB 3773 in force; California CCPA risk assessments required
- Aug 2, 2026Most of the EU AI Act applies, including transparency duties (Article 50); California AI Transparency Act
- Dec 2, 2026EU AI content marking for systems launched before Aug 2, 2026; new EU bans on non-consensual deepfakes
- Jan 1, 2027California ADMT rules for significant decisions; Colorado SB 26-189, subject to rulemaking and litigation
- Dec 2, 2027EU AI Act high-risk obligations for Annex III uses such as hiring, credit and education
- Apr 1, 2028California risk assessment attestations and the first cybersecurity audit certifications due
- Aug 2, 2028EU AI Act high-risk obligations for AI in regulated products (Annex I)
| Law | Applies to | What to do |
|---|---|---|
| EU AI Act, as amended by the Digital Omnibus (Regulation (EU) 2026/1744) | Providers and deployers serving the EU | Classify use cases by risk tier. Label AI interactions and generated content now (Article 50). Start high-risk evidence for Dec 2027. Smaller companies get simplified documentation. |
| Colorado SB 26-189 | Automated decisions about education, employment, housing, lending, insurance, health care and government services | Notice at the point of interaction, an explanation within 30 days of an adverse outcome, correction and human review. No impact assessment. Enforcement of the 2024 law it replaced is stayed in court, which could delay this one. |
| California CCPA regulations (ADMT, risk assessments, cybersecurity audits) | Businesses covered by California privacy law | Risk assessments before high-risk processing (required since Jan 1, 2026; attestations due Apr 1, 2028). ADMT notices, opt-outs and access for significant decisions from Jan 1, 2027. |
| Illinois HB 3773; NYC Local Law 144 | Employers using AI in hiring and employment decisions | Notice to candidates and employees, no discriminatory use (Illinois). Annual bias audits and notices for automated hiring tools (New York City). |
| Texas TRAIGA; California SB 53 | Prohibited uses; frontier model developers with over $500 million in revenue | Narrow for most SaaS companies. |
| US federal (Executive Order 14365) | No direct obligations for companies | The December 2025 order set up a DOJ task force to challenge state AI laws. There's no federal AI law, so state laws stay enforceable until courts or Congress act. |
Which rules apply to you?
| If your company... | Then |
|---|---|
| Sells into or operates in the EU | EU AI Act transparency duties (since Aug 2, 2026) and AI literacy measures; high-risk evidence by Dec 2, 2027 for Annex III uses. |
| Builds AI into its product | Provider duties, OWASP LLM testing, customer AI disclosures and AI-CAIQ answers. Consider ISO 42001 or AIUC-1. |
| Uses AI for hiring, credit, housing, insurance or education decisions | California ADMT rules and Colorado (Jan 1, 2027), EU Annex III (Dec 2, 2027), plus Illinois and New York City rules for hiring. Notices, human review and, under the EU and California rules, risk or impact assessments. |
| Uses AI on California residents' personal data | CCPA risk assessment before new processing. |
| Runs agents that write or take actions | Agentic scope 2 or higher controls (below), the OWASP Agentic Top 10, and AIUC-1 if customer-facing. |
| Gets AI security questionnaires from customers | AI-CAIQ self-assessment; STAR for AI Level 1. |
5. Maturity and capability models
They answer different questions. Capability models ask whether the organization can support AI, security maturity models ask whether the controls keep up, and the autonomy scope says how far to trust agents. Pair one capability view for the board with one security view for the team.
| Model | Kind | Levels | Structure |
|---|---|---|---|
| MITRE AI Maturity Model | Capability | Initial, Adopted, Defined, Managed, Optimized | 6 pillars, 20 dimensions |
| OWASP AI Maturity Assessment (AIMA) v1.0 | Security maturity | 3 maturity levels | 8 domains, built on OWASP SAMM |
| AWS Agentic AI Security Scoping Matrix | Autonomy | No, prescribed, supervised, full agency | Controls per scope |
| NIST CSF 2.0 tiers | Program rigor | Partial, Risk Informed, Repeatable, Adaptive | CSF functions |
AI security program ladder
- 1VisibleInventory across all four domains, with shadow AI and agent discovery.
- 2GovernedAcceptable use policy, approved tools, risk tiering and AI vendor review.
- 3EngineeredAI gateway, MDM and EDR controls on laptops, agent identities and approvals, evals and red teaming in CI.
- 4AssuredISO 42001 or AIUC-1 evidence, continuous monitoring, and a tested AI incident response.
6. Controls by domain
Each domain has one accountable owner and a short list of controls that do most of the work. The architecture links show how to build them.
| Domain | Owner | Top controls | Anchor | Build it |
|---|---|---|---|---|
| 1. Staff use | CISO + IT | Approved tools on enterprise tiers with no-training terms and SSO; an acceptable use policy; MDM to lock approved AI apps to your org and block the rest; your EDR vendor's AI module to find shadow AI and redact prompts, with a web proxy only to block personal accounts; AI literacy training | OWASP LLM02; EU AI Act literacy duty | A2 |
| 2. AI in SaaS | Vendor risk | An AI addendum in vendor review (training on your data, retention, subprocessors); a notice clause for new AI features; SSPM to catch AI features, agents and OAuth grants switched on | CSA AI-CAIQ; ISO 42001 supplier controls | A2B2 |
| 3. AI-assisted development | AppSec + engineering | Approved coding agents with managed settings pushed by MDM; an MCP server and skill allowlist; sandboxed agent execution; least-privilege, short-lived tokens; SAST and secrets scanning on all code; human PR review | OWASP Agentic Top 10 | B4 |
| 4. AI in your product | Product security | Threat model each LLM feature (untrusted input + private data + outbound action = danger); input and output guardrails; tenant isolation in retrieval; evals and red teaming in CI; an AI incident runbook; customer-facing AI disclosures | OWASP LLM Top 10; MITRE ATLAS; AIUC-1 | C2C1 |
| Decisions about people (tag in 2 and 4) | Legal, HR, risk | Impact assessment before use; human review of adverse outcomes; bias testing; notices and opt-out | ISO 42005; CCPA ADMT; Colorado; EU Annex III |
Agents by autonomy scope
From the AWS Agentic AI Security Scoping Matrix. Move an agent up a scope only after the controls below are proven. B3 Agents You Build shows the build.
| Scope | What the agent can do | Minimum controls |
|---|---|---|
| 1. No agency | Human-started, read-only, fixed workflow | Prompt injection testing, output filtering, logging |
| 2. Prescribed | Can change systems, but a human approves each action | Its own agent identity; scoped, short-lived credentials; an approval screen showing the exact action, sent outside the agent's own channel; audit log |
| 3. Supervised | A human starts the task and the agent acts on its own within it | Per-tool least privilege, action allowlist, spend and rate limits, kill switch, live monitoring |
| 4. Full | Starts its own work and acts without approval | All of the above plus behavioral anomaly detection, memory integrity checks, continuous red teaming and hard containment |
Core control areas across domains
| Area | What goes wrong | Minimum control | Domains |
|---|---|---|---|
| Agent and non-human identity | Agents run on borrowed human credentials; tokens sprawl; nobody owns them | A registered identity per agent with a named human owner; never a person's credentials; scoped, short-lived tokens; review OAuth grants; offboard with the project | All |
| Data access | An agent or retrieval answer returns data the user couldn't see; sensitive data lands in prompts | Retrieval enforces source permissions per user; allowed data classes per tool; least-scope connectors and MCP servers; prompt and log retention limits | All |
| Environments | A coding agent or AI feature holds production credentials; an untested prompt change reaches customers | No production credentials outside production; agents sandboxed with dev-only credentials; separate keys and data per environment; masked or synthetic data in staging | 3, 4 |
| Model and prompt change | A prompt edit or vendor model swap silently changes behavior | Version models, prompts and tool configs as code; eval gates before promotion; pin model versions; tested rollback | 2, 4 |
| Secrets | Keys pasted into prompts, stored in agent configs, echoed in tool output | Secrets manager only; scan prompts, configs and logs; rotate anything exposed | 1, 3, 4 |
| Egress | Injected instructions send data to an attacker's URL | Allowlisted destinations for agents and AI features; block auto-fetched links and images in output; network policy on agent sandboxes | 3, 4 |
| Logging and audit | No record of what an agent did, for whom, or why | Log prompts, responses, tool calls and approvals with identity; treat logs as sensitive data; feed the SIEM and your MDR | All |
| Cost and abuse | Runaway agent loops or abuse drain the budget | Spend and rate caps per user, tenant and agent at your AI gateway (model providers only cap per project or workspace); alerts on spikes | 4 |
| AI incident response | The team can't tell an AI incident from normal behavior | Define AI incidents (injection-driven exfiltration, a retrieval leak across tenants, a rogue agent action, a vendor model change); runbook: disable the feature or agent, revoke its tokens, preserve logs, assess exposure, notify per contract | All |
7. First 90 days and board questions
- 1Days 0 to 30Inventory AI across the four domains, run shadow AI and agent discovery, and publish an acceptable use policy and approved tool list.
- 2Days 31 to 60Add the AI addendum to vendor review, allowlist coding agents and MCP servers, and tier every use case by legal risk.
- 3Days 61 to 90Pick the anchor framework, baseline maturity (AIMA or MITRE) and deliver the first board report.
Questions every board should be able to answer
- How many AI systems and agents do we run, and who owns each?
- Which ones touch customer data or make decisions about people?
- What can our agents do without a human approving it?
- Which vendors may train on our data, and how do we know?
- If an AI feature leaked a tenant's data tomorrow, who runs the response?
For the hands-on version of the first 30 days, see the AI security hardening checklist.
Sources
- EU AI Act as amended, Regulation (EU) 2026/1744 (EUR-Lex)
- Colorado SB 26-189
- California Privacy Protection Agency: ADMT, risk assessment and audit rules approved
- Texas HB 149 (TRAIGA)
- Executive Order 14365
- NIST AI Risk Management Framework
- NIST IR 8596 Cyber AI Profile (preliminary draft)
- NIST COSAiS project
- CSA AI Controls Matrix v1.1
- CSA STAR for AI
- AIUC-1 changelog
- OWASP Top 10 for LLM Applications 2026
- OWASP Top 10 for Agentic Applications
- MITRE ATLAS data release v2026.09
- AWS Generative AI Security Scoping Matrix
- AWS Agentic AI Security Scoping Matrix
- CSA, Enhancing the Agentic AI Security Scoping Matrix
- OWASP AI Maturity Assessment v1.0
- MITRE AI Maturity Model
- NIST CSF 2.0
- AICPA TQA 9561: AI in SOC 1 and SOC 2 examinations
Need an AI governance program that holds up to a customer audit?
Bring your AI tools, your customer questionnaires and the frameworks you're being asked about. In a 30-minute call a CISO tells you which framework to anchor on and what to do first. No sales pitch.
Talk to a CISO