AI security controls checklist
- Organizations should implement a risk-based AI security control program spanning identity and least-privilege access, AI inventory and governance, data protection and privacy, secure AI development and model provenance, API and runtime protections, adversarial testing, continuous logging and monitoring, human oversight for high-risk decisions, and AI-specific incident response. These controls should be mapped to recognized guidance such as the SANS Critical AI Security Guidelines, NIST AI RMF, and ISO/IEC 42001, then prioritized according to the organization’s use cases, data, threats, and regulatory requirements.
- Create an enterprise AI inventory and risk classification process.
- Establish centralized identity, access, and secrets management for users, models, agents, APIs, and service accounts.
- Deploy data-loss-prevention, classification, masking, retention, and vendor contractual controls.
- Implement secure AI application architecture with isolated environments, validated retrieval, tool permissions, and endpoint protection.
Organizations should implement a risk-based AI security control program covering identity, inventory, data protection, secure development, runtime security, testing, monitoring, human oversight, and incident response. Map it to recognized guidance and prioritize controls by use case, data, threats, and obligations.
The core AI security controls every organization should implement
AI security controls must protect more than a model. They should cover third-party SaaS copilots, internal LLMs, retrieval-augmented applications, autonomous agents, APIs, data, infrastructure, workflows, and connected systems. The required control depth depends on the deployment model, industry, data sensitivity, threat environment, and regulatory or contractual requirements.
Executive checklist: baseline and enhanced controls
Use this framework as the starting point for an enterprise AI security program. Baseline controls apply broadly to organizations deploying AI. Enhanced controls are appropriate when systems are high-risk, regulated, highly autonomous, or connected to sensitive data and critical systems.
| Control area | What it manages | Practical implementation action | Level |
|---|---|---|---|
| AI inventory and risk classification | Approved and unauthorized tools, models, agents, data, and integrations | Maintain an inventory with owners, data flows, connected systems, and use-case risk ratings. | Baseline |
| Identity and least privilege | Users, applications, models, agents, service accounts, APIs, tools, and actions | Use strong authentication, RBAC or ABAC, centralized secrets management, access reviews, and narrowly scoped permissions. | Baseline |
| Data protection and privacy | Sensitive information in prompts, training data, retrieval systems, and outputs | Classify and minimize data, then apply masking, tokenization, retention, DLP, and access controls where appropriate. | Baseline |
| Secure development and provenance | Models, datasets, applications, pipelines, configurations, and dependencies | Require provenance, versioning, validation, supply-chain review, production-readiness checks, and change control. | Baseline |
| Runtime and API security | Endpoints, plugins, tools, agent actions, inputs, and outputs | Apply authentication, authorization, validation, rate limiting, isolation, constrained permissions, and input/output safeguards. | Baseline |
| Testing and approval gates | Predeployment security, safety, access, and performance risks | Perform threat modeling, security assessments, adversarial testing, red-team exercises, and documented release reviews. | Baseline |
| Monitoring and detection | Access, prompts, responses, tool calls, drift, anomalies, and violations | Centralize privacy-aware telemetry and define detection and audit requirements. | Baseline |
| Governance and human oversight | Accountability and consequential or autonomous decisions | Set approved-use rules, ownership, reporting procedures, and human approval boundaries. | Baseline |
| AI incident response | Control failures, misuse, security incidents, containment, and recovery | Create AI-specific response, remediation, recovery, and lessons-learned processes. | Baseline |
Enhanced controls for high-risk, regulated, or autonomous AI
- Require formal approval before deployment and material changes.
- Use stricter human review for regulated or high-impact decisions and autonomous actions.
- Expand adversarial testing, red-team exercises, model evaluations, access reviews, and documented safety checks.
- Apply tighter isolation and narrower tool permissions to agents and service accounts.
- Increase control testing, monitoring, assurance activities, and evidence collection according to risk.
1. Build an AI inventory and classify risk
Discover approved and unauthorized AI use
Maintain an inventory of AI tools, models, agents, datasets, prompts, pipelines, owners, plugins, and connected systems. Include approved platforms and unauthorized or previously unreported use, including workplace SaaS copilots and AI features embedded in existing applications.
Record how each system receives data, which systems it can reach, which users or services operate it, and who owns the use case. This inventory provides the basis for finding shadow AI and applying consistent controls.
Classify use cases and deployment context
Assess each use case by purpose, data sensitivity, connected systems, threat environment, deployment model, industry, and applicable obligations. An internal assistant that summarizes low-sensitivity material may require less control depth than an autonomous agent that can take actions or support a regulated decision.
2. Enforce identity, authentication, and least privilege
Protect users, models, agents, and service accounts
Use strong authentication and centralized identity management for users, applications, models, agents, APIs, and service accounts. Treat agents and service accounts as distinct digital identities where relevant, and protect them with appropriately strong authentication controls.
Apply role-based access control (RBAC) or attribute-based access control (ABAC), manage secrets centrally, and review access periodically. Remove broad, outdated, or role-mismatched permissions instead of allowing them to persist.
Restrict data, APIs, tools, systems, and actions
Least privilege should limit every AI identity to the data, APIs, backend systems, tools, and actions it needs. For an agent, define which tools it may call, which records it may access, and which actions require human approval.
3. Establish approved use and accountability
Define permitted and prohibited use
Publish approved AI platforms, permitted use cases, prohibited data, usage expectations, and reporting procedures. Make clear that credentials, API keys, unnecessary customer data, financial information, security details, and confidential records must not enter unauthorized AI tools or pipelines.
Apply these rules to third-party SaaS copilots, internal LLMs, retrieval-augmented applications, and autonomous agents without assuming that every deployment model has the same risk.
Assign cross-functional ownership
Accountability should include the appropriate security, privacy, governance, compliance, IT, platform, development, legal, and business stakeholders. A technical team should not be the only owner of decisions affecting privacy, customers, employees, or regulated operations.
4. Protect data and privacy across the AI lifecycle
Classify and minimize data
Classify information before it enters prompts, training data, retrieval systems, or outputs. Minimize collection to what the use case needs, and define handling rules for sensitive and confidential records.
Use masking, tokenization, retention limits, access controls, and data-loss-prevention measures where appropriate. Cover both managed AI pipelines and unsanctioned workplace use.
Protect prompts, training data, retrieval systems, and outputs
Protect credentials, API keys, customer information, financial information, security details, and confidential records from unauthorized disclosure. Review how prompts and outputs are stored, who can access them, and how long operational or audit records are retained. For detailed prevention measures, see the guide to preventing LLM data leakage.
Privacy-aware logging should preserve enough evidence to investigate misuse and control failures without collecting or retaining sensitive content unnecessarily.
5. Secure AI development, deployment, and provenance
Track data and model provenance
Apply security and administrative controls throughout the AI lifecycle. Track the origin and version of models, datasets, prompts, applications, pipelines, configurations, and supporting dependencies. Validate inputs and releases, and review the relevant supply chain before production use.
Apply release and change controls
Use secure configuration, production-readiness checks, documented approvals, and change control for models, data, applications, and infrastructure. Reassess risk when a system gains new data access, tools, integrations, autonomy, or decision-making responsibilities.
6. Secure APIs, applications, and runtime actions
Protect endpoints, plugins, tools, and agents
Protect model endpoints, APIs, plugins, tools, and agent actions with authentication, authorization, input validation, rate limiting, and appropriate isolation. Constrain tool permissions and separate environments where appropriate.
The goal is to prevent an application or agent from turning a limited request into unauthorized access or action. Requirements should reflect the system’s architecture and risk rather than a generic API checklist.
Apply input and output safeguards
Use input and output safeguards against prompt injection, jailbreaks, unsafe content, data leakage, and unauthorized actions. Test safeguards in the context of the application and its connected systems.
Guardrails reduce risk; they do not eliminate prompt injection, unsafe outputs, data exposure, or other AI security threats. Runtime safeguards must operate alongside access control, isolation, testing, and monitoring.
7. Test before deployment and require approval gates
Use threat modeling and adversarial testing
Before release, conduct a security assessment and threat model for the AI application and surrounding systems. Use adversarial or prompt-injection testing, red-team exercises, model evaluations, access reviews, and documented performance or safety checks.
Test relevant risks such as poisoning, evasion, extraction, manipulation, misuse, unsafe outputs, and excessive permissions without relying on a single evaluation or test result.
Document release decisions
Record the assessed use case, data and system access, identified risks, mitigations, test results, approval decision, and remaining limitations. High-risk or autonomous deployments should have stronger approval gates and defined escalation paths.
8. Monitor continuously and retain privacy-aware evidence
Monitor behavior and access
Continuously monitor for unusual access, policy violations, unsafe outputs, model or data drift, anomalies, excessive permissions, and attempted attacks. Depending on the application, telemetry can include access events, prompts, responses, tool calls, configuration changes, and policy decisions.
Monitoring should help security and operations teams identify misuse, changing behavior, and control failures—not merely confirm that an endpoint is available.
Define logging and review practices
Set log retention based on investigation needs, privacy requirements, data sensitivity, and applicable obligations. Limit access to logs and protect them from unauthorized alteration. Do not assume that every prompt or response must be retained in full; establish documented, risk-based logging requirements instead.
9. Require human oversight for consequential AI use
Set approval boundaries
Require human review for high-risk, regulated, or automated decisions and for autonomous actions with consequential effects. Define which actions an AI system may complete independently, which require approval, and when it must stop and escalate.
Organizational accountability remains in place even when a model or agent performs the immediate task.
Apply fairness and explainability where relevant
For use cases affecting people or regulated outcomes, include fairness testing and mitigation where relevant. Use explainability methods when operators, reviewers, or audit teams need to understand how a system reached or supported a decision.
10. Maintain an AI-specific incident response process
Contain, remediate, and recover
Maintain an AI incident-response plan covering detection, triage, containment, remediation, recovery, communications, and lessons learned. Address failures in identity, data protection, model or application behavior, tool permissions, monitoring, and governance.
Define how to suspend an affected application or agent, revoke credentials and permissions, preserve relevant evidence, assess impact, and approve a return to service. Tailor recovery procedures to the organization’s systems and obligations.
Improve controls after incidents and material changes
After an incident, near miss, failed test, or material system change, reassess the threat model and control effectiveness. Update policies, permissions, tests, monitoring, and approval criteria as needed.
How to prioritize and roll out AI security controls
- Discover: build the AI inventory, identify unauthorized use, map data flows, and assign owners.
- Classify: assess use cases by data sensitivity, connected systems, autonomy, threats, deployment model, and obligations.
- Establish foundations: implement strong authentication, least privilege, access reviews, secrets management, approved-use rules, governance, and data protection.
- Secure the lifecycle: add provenance, versioning, validation, supply-chain review, secure configuration, release gates, and change control.
- Protect runtime operation: secure APIs and tools, constrain agent actions, apply input/output safeguards, and isolate where appropriate.
- Assure and improve: perform threat modeling, adversarial testing, red-team exercises, centralize privacy-aware monitoring, prepare incident playbooks, and add enhanced controls for high-risk, regulated, or autonomous systems.
For each major control, assign an owner, define the expected outcome, set a risk-based review or testing cadence, and retain evidence such as inventory records, access reviews, approval decisions, test results, monitoring records, and incident actions. Tailor metrics and evidence to the organization’s risk profile rather than treating them as universal benchmarks. For guidance on measuring program performance, see AI security metrics and KPIs.
Align the program with recognized guidance
Organizations can align their program with the SANS Critical AI Security Guidelines, the NIST AI Risk Management Framework, and ISO/IEC 42001.
These references help structure risk management, governance, and assurance. They are alignment tools, not mandates for one identical checklist. Map the controls to applicable legal, contractual, industry, and organizational requirements, then adjust priorities as use cases, threats, data, and system capabilities change.
Conclusion
The essential AI security controls are enterprise controls as well as model controls. Start with inventory, risk classification, identity, least privilege, approved use, governance, and data protection. Then expand into secure lifecycle management, runtime safeguards, testing, monitoring, human oversight, incident response, and enhanced assurance according to risk.
A program aligned with the SANS Critical AI Security Guidelines, NIST AI RMF, and ISO/IEC 42001 provides useful structure while allowing controls to be tailored to each AI deployment.
