AI security checklist for businesses: 40 controls

By Michael Obraitis, Managing Partner, and Michael Dale, CEO · Published August 28, 2026 · Last reviewed August 2026 · ADAM Pulse Knowledge Base

Short answer

You do not need an enterprise AI platform to start governing AI. You need an owner, a written rule for what may go into a tool, an inventory of what is already in use, and a short list of controls that match how your people actually work.

This page is that list: 40 numbered controls in eight groups. It is a risk-management starting point, not a compliance certificate. Completing it does not make you CMMC Level 2 certified, FedRAMP authorized, or EU AI Act conformant. Those are separate programs with their own assessors, evidence and scopes. If a vendor or questionnaire treats this checklist as a certificate, they are wrong.

The controls are grouped so a CIO can assign them: AI Governance (1–5), Application Discovery (6–10), Data Security (11–15), Identity and Access (16–20), Agent Controls (21–26), Monitoring (27–32), Human Oversight (33–35), Incident Response (36–40). Five questions at the end tell you whether the program is real.

Sources, not slogans: NIST AI 600-1 (Generative AI Profile, July 2024), NIST CSF 2.0 (February 2024), the OWASP AI Agent Security Cheat Sheet, and Microsoft’s Secure autonomous agentic AI systems guidance. This list is a practical grouping. It is not a one-for-one copy of any of them.

AI Governance (controls 1–5)

NIST CSF 2.0 added Govern as a sixth function: strategy, expectations and policy are established, communicated and monitored. NIST AI RMF does the same job for AI specifically (Govern, Map, Measure, Manage). If nobody owns AI risk, the rest of this list is a document on a shelf.

1. Name an accountable owner. One executive, named in writing, for AI risk — not “IT will handle it” and not a committee with no decision rights. The owner can delegate work. They cannot delegate the “we did not know” answer.
2. Publish a short acceptable-use policy. Purpose, scope, approved tools, prohibited data mapped to the classification you already have, human verification, labeling, agents, integrations, Shadow AI, IP, security and training. The companion article How to create a corporate AI acceptable use policy is the document this control assumes exists.
3. Classify every AI system by job, data and autonomy. At minimum: chatbot (answers), embedded feature (inside software you already pay for), coding assistant, and agent (plans and acts). Microsoft’s agent-adoption guidance classifies agents by purpose, criticality and autonomy. If you cannot say which bucket a tool is in, you cannot pick the right controls.
4. Keep a living inventory: approved, restricted, blocked. Name, owner, data classes allowed, whether it can act, and the review date. An inventory that is not dated is a wish list. CSF 2.0 Identify is this job for the rest of the estate; AI is not exempt.
5. State, in the program charter, that this is risk management — not a certificate. Write it down so a sales deck cannot promote the opposite. USA Telecom is not CMMC Level 2 certified and not FedRAMP authorized; completing this checklist does not change that for you either. If you handle Controlled Unclassified Information, existing contract and NIST SP 800-171 obligations follow the data into the tool. That is a scoping problem, not an AI badge.

Application Discovery (controls 6–10)

You cannot govern what you have not found. Gartner’s 2025 cybersecurity-leader survey is the figure we already cite in AI data governance in 2026: most organizations suspect or have confirmed prohibited GenAI use. Discovery is five places, not one scan.

6. Inventory browser and consumer AI. Public ChatGPT, Claude, Gemini, Copilot on the web, Perplexity, and the next tool that shows up in DNS. Personal accounts on work machines count.
7. Inventory AI features inside software you already license. Meeting notetakers, CRM copilots, help-desk suggest, Zoom AI, Microsoft 365 Copilot, Google Gemini in Workspace. “We don’t use AI” is often “it shipped inside the suite.”
8. Inventory coding assistants and local models. GitHub Copilot, Cursor, Claude Code, local LLMs, IDE plugins. Source code leaving the building is a data-transfer event, same as a contract paste.
9. Inventory agents, bots and tool connections. Anything that can send mail, write to a system of record, call an API, or use Model Context Protocol (MCP) tools. Microsoft now documents Shadow AI agents as unsanctioned local agents on managed endpoints — a narrower term than employee chatbots, and current as of this review.
10. Interview departments. Sales, finance, operations, legal, and whoever answers the phone. Technical discovery misses the tool someone paid for on a personal card. How to run that intake is in What is Shadow AI and how do you find it?

If you want a structured first pass before the interviews, use the Shadow AI Risk Assessment. It runs in the browser, sends nothing, and does not replace discovery. It tells you which questions you cannot yet answer.

Data Security (controls 11–15)

NIST AI 600-1 lists data privacy and information security among the risks unique to or exacerbated by generative AI. The operational rule is older than the framework: if the data would not go to an unmanaged file share, it does not go into an unmanaged model.

11. Map AI channels to the classification you already have. Do not invent a parallel AI taxonomy. Public, Internal, Confidential, and CUI (if you have it) are enough. Each approved tool gets a written list of classes it may receive.
12. Prohibit sending restricted classes to unapproved tools. Customer lists, contracts, credentials, source code, and CUI stay out of public chatbots. This article does not use health-record examples; if you are a covered entity, your existing HIPAA program owns that mapping — do not paste it here as a novel AI rule.
13. Treat every prompt as a data transfer. Paste is egress. So is a file uploaded for “summarize this,” a meeting bot that records a call, and a coding assistant that indexes a repo. The companion argument is in the data-governance article.
14. Review vendor training and retention settings in writing. What is used to train, what is retained, where it lives, and how you turn training off. Zoom’s public terms are one documented case; do not assume the same promise from a consumer chatbot. See Does Zoom use your meetings to train AI?
15. Put sensitivity labels or DLP in the path of likely paste. Microsoft Purview and equivalent Google/Workspace controls will not catch a personal phone, which is why discovery and policy still matter. They will catch a lot of well-intentioned desktop use.

Identity and Access (controls 16–20)

Microsoft’s least-privilege guidance for AI agents names identity ambiguity, permission creep, over-broad tool access, weak audit trails, and slow revocation as the failure modes. Those apply to human users of AI tools as well.

16. Require SSO and phishing-resistant MFA on every approved AI tool that supports it. Consumer logins with a personal mailbox are not an enterprise control. Related baseline: five inexpensive cybersecurity improvements.
17. Ban shared AI accounts. One login used by a team destroys attribution. You will not be able to answer “who pasted that contract.”
18. Give agents their own identity. Microsoft Entra Agent ID is the documented pattern: agents as first-class principals, not a shared secret and not “whatever the human was logged in as.” If the platform cannot do that, do not give the agent write access.
19. Least privilege on tools the agent can call. OWASP: minimum tools, per-tool scoping (read vs write, specific paths), separate tool sets by trust level. An unrestricted shell is not a feature.
20. Review OAuth grants and third-party AI apps quarterly. Meeting bots, calendar assistants and “summarize my inbox” apps are identity events. Revoke what nobody can name an owner for.

Agent Controls (controls 21–26)

OWASP’s cheat sheet and Microsoft’s secure-agentic pattern agree on the shape: tool abuse, prompt injection, excessive autonomy, and high-impact actions without independent validation. A demo that can do the task is not production. That gap is spelled out in what separates production-ready agents from demos.

21. Allowlist tools. Do not open the shell. OWASP’s good/bad MCP examples are the right picture: restricted paths and operations, not allowed_commands: "*".
22. Require deterministic human approval for irreversible or high-impact actions. Microsoft: human-in-the-loop enforced in orchestrator logic, not in the prompt. OWASP: explicit approval for financial, administrative, or externally visible operations. Sending mail, changing a record, paying a vendor, and deleting data are the usual four.
23. Treat retrieved content as untrusted. Documents, emails, web pages and tool output can contain instructions. Prompt injection is worse for agents than chatbots because a bad answer is text; a bad action is an action. Filter inputs and outputs; do not ask the model to “be careful.”
24. Isolate memory and keep secrets out of it. OWASP: sanitize before persist, isolate by user/session, expire, and audit. Credentials, API keys and customer files do not belong in long-term agent memory.
25. Cap cost and loop length. OWASP names denial-of-wallet: unbounded agent loops that spend your API budget. Token caps, rate limits, and a maximum number of tool calls per job are the control, not a monthly invoice surprise.
26. Maintain a tested kill switch. Microsoft measures mean time to revoke or disable an agent identity, including token invalidation. An untested stop button is a belief. Pause, revoke, and confirm the agent cannot still call tools with a cached token.

Monitoring (controls 27–32)

CSF 2.0 Detect is “anomalies and events are discovered.” For AI, the usual gap Microsoft calls out is logs that capture the chat reply and miss the tool call, the scope and the authorization decision.

27. Log which human used which approved AI tool, when. Identity logs from SSO beat a screenshot of a chat.
28. Log agent tool calls, not only transcripts. Request, retrieved context, model, every tool and result, decision, cost, and failure point. If you cannot reconstruct Tuesday, you cannot investigate Tuesday.
29. Watch DNS, proxy and firewall for AI destinations. Consumer chatbot domains, API endpoints, and new SaaS. This is how you find what interviews miss. Method in the Shadow AI article.
30. Alert on new OAuth applications and high-privilege grants. A meeting bot that joined ten calendars last night is an identity event, not an IT anecdote.
31. Review unsanctioned local agents on managed endpoints. Microsoft’s Shadow AI (Frontier) page in the Microsoft 365 admin center is the current product language for this on Intune-enrolled Windows devices. It is not a complete inventory of Shadow AI. It is one feed. Use it if you have the license; do not pretend it sees personal phones.
32. Put agent traffic through a path you can see. Microsoft recommends a managed gateway as a single control point for logging, throttling and access. If agents talk to models, APIs and each other across the WAN, network monitoring is part of AI monitoring. That is the NOC vantage we already run.

Human Oversight (controls 33–35)

33. A human verifies AI output that commits the company. Prices, legal positions, customer-facing decisions, financial postings, and anything irreversible. Approval proportional to consequence — not a human rubber-stamping every draft email.
34. Label AI-generated content that goes outside the company when you are in scope, and as policy when you are not. EU AI Act Article 50 transparency obligations have applied since 2 August 2026 (European Commission FAQ on Article 50; Regulation (EU) 2024/1689). They cover, among other things, making people aware they are interacting with an AI system unless it is obvious, and marking certain synthetic content. A limited grace period to 2 December 2026 applies only to machine-readable marking for generative systems already on the market before 2 August 2026. This does not automatically bind a US company with no EU nexus. Do not invent a US labeling statute from Article 50. Labeling customer-facing AI output is still good practice.
35. Train the people who operate the tools. EU AI Act Article 4 (AI literacy) has applied since 2 February 2025 — not 2 August 2026. Regulation (EU) 2026/1744, in force 27 July 2026, restated the duty as measures that support the development of AI literacy, not a guaranteed proficiency level. Again: EU providers and deployers, not every US employer. For everyone else, literacy is still how you stop well-intentioned pastes. Put it in onboarding and in the acceptable-use policy.

Incident Response (controls 36–40)

CSF 2.0 Respond and Recover. Fold AI into the incident process you already have. Do not stand up a parallel “AI CSIRT” that nobody will call at 2 a.m.

36. Define an AI incident in the existing playbook. Examples: restricted data in an unapproved tool; an agent that acted outside policy; a compromised AI account; prompt-injection that caused an external action. If it is not named, it will be filed as “weird email.”
37. Contain with identity and path, not a stern Slack message. Revoke the user or agent identity, invalidate tokens, disable the tool, block the destination. Microsoft’s kill-switch metric is the test of whether this is real.
38. Notify under the rules you already have. Customer contracts, state breach statutes, CUI reporting if you are in that scope. This checklist does not create a new legal notification duty. It says: use the ones you already have, and do not skip them because “it was only a chatbot.”
39. Preserve prompts, tool-call logs, identity logs and network records. Rebooting the laptop or wiping the chat history is how you destroy the only evidence you will be asked for.
40. Feed the outcome back into inventory and policy. Add the tool to approved/restricted/blocked, tighten the data class, and update the acceptable-use examples so the next person does not repeat it.

Five questions a CIO should be able to answer

If you cannot answer these in a sentence each, the program is still a slide.

1. If an employee pasted a customer contract into a public chatbot last Tuesday, would we know?
2. If an agent sent an email or changed a record, can we prove which agent, acting for whom, under what instruction?
3. Which data classes are allowed in which AI tools — in writing, mapped to the classification we already use?
4. What is the tested way to stop an agent that is misbehaving, including cached tokens?
5. Who is accountable for saying no, and have they actually said no?

Question 1 is a Shadow AI and monitoring question. Question 2 is identity and logging. Question 3 is data plus the acceptable-use policy. Question 4 is the kill switch. Question 5 is governance. None of them is a product SKU.

Frequently asked questions

Related articles

• AI agent security for business: 12 safeguards — the agent-access pillar this checklist expands; identity, allowlists and a tested stop before write.
• AI agent permissions and least privilege explained — OWASP and read-before-write behind controls 19–22.
• AI incident response plan — controls 36–40 as a playbook, not a parallel CSIRT.
• How to create a corporate AI acceptable use policy — the document control 2 asks you to publish, with a sample policy block.
• What is Shadow AI and how do you find it? — discovery methods behind controls 6–10, and the intake process.
• Shadow AI Risk Assessment — a free, private first pass. It does not scan your network and it is not this checklist.
• What separates AI agents that ship to production from the ones that stay demos? — the production architecture behind controls 21–26.
• What does AI data governance actually require in 2026? — the four problems this checklist is built to close.
• ChatGPT can now read and send your Apple Messages — a concrete agent-action decision, including standing send approval.
• Five inexpensive cybersecurity improvements — MFA, backups and identity hygiene the AI program sits on.

References

Primary sources only. Where a rule is EU-specific or contract-specific, the article says so rather than turning it into a universal US obligation. This checklist is not an official NIST, OWASP, Microsoft, CMMC or FedRAMP control set.

1. NIST AI 600-1 — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (July 2024)— companion profile to AI RMF 1.0. Voluntary. Source for generative-AI-specific risks including data privacy, information security, human-AI configuration and value-chain integration, and for suggested actions under Govern, Map, Measure and Manage.
2. NIST CSWP 29 — The NIST Cybersecurity Framework (CSF) 2.0 (26 February 2024)— six functions including Govern. Source for treating AI risk as part of cybersecurity governance rather than a side policy. Not a certification scheme.
3. OWASP Cheat Sheet Series — AI Agent Security— tool least privilege, prompt-injection defense, memory isolation, human-in-the-loop for high-impact actions, monitoring, and denial-of-wallet. Maintained sheet; retrieved August 2026.
4. Microsoft Learn — Secure autonomous agentic AI systems (updated March 2026)— defense-in-depth across model, safety, application and positioning layers; deterministic HITL; least privilege; disclosure.
5. Microsoft Learn — Least privilege for AI agents— identity ambiguity, permission creep, over-broad tools, weak audit, slow revocation; kill-switch measured as time to revoke including tokens.
6. Microsoft Learn — Shadow AI in the Microsoft 365 admin center— current Microsoft language for unsanctioned local AI agents on Intune-managed Windows devices. Not a complete Shadow AI inventory.
7. Regulation (EU) 2024/1689 — EU Artificial Intelligence Act— Article 4 AI literacy (applied 2 February 2025); Article 50 transparency; Article 113 application dates. Amended in part by Regulation (EU) 2026/1744.
8. European Commission — Transparency obligations under Article 50 of the AI Act— Article 50 applies from 2 August 2026; limited grace to 2 December 2026 for Article 50(2) machine-readable marking of generative systems already on the market before that date.