7.3 The security team checklist
A keep-it-by-your-desk checklist across identity, runtime, browser, desktop, supply chain, cloud, data, and audit controls.
Last reviewed: August 18, 2026
What security teams need to know about the AI security checklist
This is the evidence-backed version of the launch checklist. Adapt the required rows to the deployment model, data class, and risk tier in 7.4 The vendor-neutral control matrix. A skipped row needs a documented rationale. An exception needs an owner and expiry date.
Run the checklist again after an incident, a material vendor or architecture change, a new data class, a change in ownership, or an expansion in autonomy.
AI security checklist evidence record
Keep these fields with every control decision:
Applies?
Yes or no, with a reason when the control does not apply
Status
Pass, fail, exception, or not tested
Owner
One accountable person or function
Evidence
Link to an export, policy, log sample, test result, contract term, or other reproducible record
Last tested
Date the control was last verified, not only configured
Exception
Risk owner, compensating controls, approval, and expiry date
Review trigger
Next scheduled review and any event that forces an earlier review
Common AI security checklist failures
The checklist is completed once and never recertified.
Rows are marked as passed without evidence or a recent test.
Chat, coding agents, desktop agents, hosted agents, and API applications are assessed as if they have the same control plane.
A provider-wide setting is assumed to cover every surface and authentication path.
Exceptions have no accountable owner or expiry date.
Incident responders cannot revoke the agent, connector, credential, task, and published output separately.
AI security controls checklist
Governance & rollout
Every AI product, surface, deployment model, authentication path, and environment is in the inventory
AI governance lead
Inventory export or register
7.1, 7.4
Each entry records a business owner, technical owner, risk tier, permitted data classes, and deployment model
AI governance lead
Completed inventory fields
7.1, 7.4
Approved and prohibited uses are documented by cohort, surface, data class, and action type
Security + legal
Approved-use standard and user communication
7.1
The pilot gate verifies the required controls and records a go, hold, or stop decision
Security lead
Pilot test record and sign-off
7.2
Expansion requires evidence that pilot defects are closed or accepted
Security lead + business owner
Remediation tracker and expansion approval
7.2
Security, identity, endpoint, data, platform, legal, procurement, and incident-response responsibilities are assigned
AI governance lead
Current RACI
7.1, 7.3
Exceptions record a risk owner, compensating controls, approval, and expiry date
Security lead
Exception register
7.3
User training covers permitted data, approvals, connectors, output review, and incident reporting before access is granted
AI governance lead + security
Training record and scenario check
7.1, 7.2
A tested exit plan covers stopping work, revoking access, ownership transfer, export, deletion, artifacts, schedules, and billing
AI governance lead + platform
Exit exercise and deletion evidence
7.1, 5.6
Controls are recertified at least quarterly and after incidents, major vendor changes, new data classes, autonomy changes, or ownership changes
Control owners
Review calendar and completed review records
6.7
Identity
Managed user surfaces use SSO where supported; unsupported login paths and exceptions are recorded
Identity lead
IdP configuration and authentication test
1.1
SCIM or a documented joiner, mover, and leaver process removes access within the agreed service level
Identity lead
Provisioning configuration and deprovisioning test
1.1
Roles or groups restrict high-risk capabilities such as code execution, agents, connectors, browser use, publishing, and administration
Identity lead + security
Role export and sampled entitlement review
1.2
Personal-account use is blocked where tenant restrictions are supported; other surfaces have a tested detection and remediation path
IT + network security
Restriction configuration or detection test
1.3
Shadow accounts, unmanaged organizations, and accounts on verified domains are discovered and consolidated or removed
Identity lead
Discovery results and remediation log
1.4
Agents and other non-human identities have dedicated identities, named owners, narrow scopes, and revocation paths
Platform engineering
Non-human identity inventory and revocation test
1.5
API keys, service accounts, workspace tokens, and project credentials are inventoried, vaulted, scoped, and rotated
Platform engineering
Credential inventory and rotation record
1.6
Human approval is required before autonomous systems perform actions outside the approved baseline
Security + business owner
Approval policy and sampled allow or denial events
1.7
Supply chain & extensibility
Every enabled connector or app has an intake approval recording owner, scopes, data classes, actions, and connected system
Security + app owner
Intake register entry and scope export
2.1, 2.7
Local and remote MCP servers are inventoried, authenticated where applicable, and reviewed before enablement
Platform engineering
Server inventory and assessment
2.2
An MCP gateway or equivalent managed restrictions enforce the approved server and tool policy
Platform engineering
Gateway or managed-policy export and blocked-server test
2.3
Skills and instruction bundles are reviewed for hidden instructions, tool use, data access, and update behavior
Security
Review record with content hash or version
2.4
Plugins, marketplaces, and extensions are restricted to approved sources and reviewed after material updates
Security + endpoint
Allowlist and versioned review record
2.5
Hooks and lifecycle scripts are inventoried; untrusted, unsigned, or unowned scripts are blocked
Platform engineering
Hook inventory and execution-policy test
2.6
The supply-chain register records the owner, source, version, permissions, review date, and next review trigger
Security
Complete supply-chain register
2.7
Signed packages, trusted distribution channels, version pinning, and update behavior are verified where supported
Endpoint + platform engineering
Signature or provenance check and update test
2.8
SaaS agent builders are reviewed for templates, connections, collaboration, publishing, and agent transfer or deletion
Security + app owner
Builder configuration and publishing test
2.9
Hosted-agent frameworks, SDKs, models, tools, containers, and other dependencies have owners and an advisory and update process
Platform engineering
Dependency inventory and update record
2.10
Runtime, sandbox & autonomy
The isolation model is documented for each local and hosted execution path
Platform engineering
Architecture note and configuration export
3.1
Coding-agent sandbox and approval settings are centrally enforced where the provider supports managed configuration
Platform engineering
Managed configuration and sampled client check
3.1, 3.2
Writes, commands, network actions, credential use, and other high-impact actions require approval beyond the approved baseline
Security
Approval policy and allow or denial events
1.7, 3.2
Network egress is denied or restricted by default according to risk, and allowed destinations are owned and tested
Network security
Egress policy and test result
3.3
Browser and internet access are enabled only for approved cohorts and sensitive internal sites have additional protection
Security + endpoint
Role policy, site controls, and blocked-site test
3.4
Computer-use and desktop-control capabilities are disabled unless required; enabled workflows have action boundaries and endpoint controls
Security + endpoint
Capability policy and action test
3.5
Scheduled and background tasks have narrow identities, bounded runtime, rate and spend limits, stop conditions, and reviewable outputs
Platform engineering
Task configuration and stop-control test
3.6
Remote dispatch, mobile triggers, remote sessions, and SSH paths are authenticated, attributable to an initiator, and revocable
Platform engineering + identity
Authentication path, event sample, and revocation test
3.7
Local filesystem access is limited to approved roots; sensitive, home, credential, and cloud-synced paths are denied unless required
Endpoint + security
Path policy and denied-access test
3.8
Hosted triggers are authenticated and protected against replay; the control plane is outside the agent's writable runtime
Platform engineering
Trigger tests and architecture evidence
3.9
Hosted agents use task-scoped, short-lived credentials issued through a broker or vault where feasible
Platform engineering + identity
Credential policy and active-run revocation test
3.9, 4.7
Hosted-agent workloads isolate tenants and tasks, use managed secrets, restrict egress, and limit spend, rate, duration, and actions
Platform engineering
Runtime configuration and boundary tests
3.9
Hosted tasks have a tested kill switch that stops work and revokes active credentials, sessions, and downstream access
Platform engineering + IR
Kill-switch exercise record
3.9, 5.6
Data protection & residency
Every approved surface has a tested DLP enforcement or evidence path; exclusions and unsupported paths are documented
Data protection
Test prompts, alerts, and coverage matrix
4.1
Data classes are mapped to allowed products, surfaces, connectors, actions, and deployment models
Data protection
Class-to-tool matrix
4.2
Processing, storage, support, log, backup, and subprocessor regions are verified for each surface and plan
Compliance + privacy
Contract terms, settings, and regional test evidence
4.3
Retention is configured per surface; regulated data is limited to surfaces with a proven retention posture
Compliance
Retention export and deletion test
4.4
Zero Data Retention eligibility and exclusions are recorded by endpoint, feature, and session type
Compliance + platform engineering
Provider terms and endpoint configuration
4.4
Training and data-use terms are confirmed for each product, plan, workspace, and authentication path
Compliance
Contract, admin setting, or provider term
4.5
Knowledge bases, embeddings, vector stores, memory, fine-tuning and evaluation datasets, caches, backups, and exports have lifecycle owners
Data protection + platform
AI data-store inventory and lifecycle records
4.4
Source permission changes and deletion requests propagate to retrieval indexes, generated artifacts, and downstream copies or gaps are documented
Data protection + app owner
Permission and deletion propagation tests
4.4, 4.6
Cross-app transfers, generated files, live artifacts, links, publishing, and downstream sharing are in the data-flow review
Data protection + app owner
Data-flow diagram and sharing test
4.6
Secrets and credentials are blocked or scrubbed from prompts, tool parameters, logs, traces, and agent configuration
Security engineering
Secret-scanning and redaction test results
4.7
Threats & incident response
Prompt-injection scenarios have been exercised against untrusted content and connected tools
Security testing
Test report and remediation record
5.1
Exfiltration through connectors, tools, files, URLs, browser actions, and generated artifacts has been tested
Security testing + data protection
Exfiltration test report
5.2
Vulnerabilities and supply-chain advisories for enabled clients, SDKs, extensions, servers, and runtimes are tracked and remediated
Vulnerability management
Advisory and patch record
5.3
Memory poisoning, data poisoning, spoofed tool results, SSRF, replay, approval races, and denial-of-wallet are covered in design review and testing
Security architecture + testing
Threat model and abuse-case tests
5.4, 5.5
Tool poisoning, identity confusion, permission inheritance, and confused-deputy scenarios are covered in design review and testing
Security architecture
Design review and abuse-case tests
5.4
High-risk workflows are red-teamed before expansion and after material changes
Security testing
Scoped red-team report
5.5
The incident runbook covers revoking users, agent identities, connectors, credentials, remote tasks, sessions, and published artifacts
IR lead
Current runbook and containment checklist
5.6
Incident responders have exercised the containment path and can identify required evidence by surface
IR lead + security operations
Tabletop or technical exercise record
5.6, 6.6
Each material workflow has a current threat model covering data, identity, tools, runtime, users, outputs, and trust boundaries
Security architecture
Approved threat model
5.7
Observability, audit & evidence
Audit coverage and known gaps are documented per product, surface, authentication path, and execution location
Security operations
Coverage matrix and tested event samples
6.1
Telemetry uses a versioned schema with normalized timestamps, source identifiers, correlation IDs, model and policy versions, targets, and outcomes
Security operations + platform engineering
Schema and representative event samples
6.2
Delivery latency, completeness, source health, sampling, clock drift, parser failures, and retention are measured and reconciled
Security operations
Telemetry SLO and reconciliation report
6.2, 6.6
Agent telemetry records the required identifiers, actions, approvals, tool activity, outcomes, and errors
Security operations + platform engineering
Telemetry schema and event samples
6.2
Prompt, response, and tool-content capture follows a documented content, redaction, access, and retention policy
Security operations + privacy
Collector configuration and redaction test
6.2
All available audit and compliance sources are collected; coverage, retention, and exclusions are tested and recorded
Security operations
Collection configuration and reconciliation report
6.3
Usage, adoption, model, token, task, and spend analytics are reviewed for anomalies and unowned activity
FinOps + security operations
Review report and follow-up record
6.4
SIEM detections are selected from approved threat scenarios, tested with representative events, and linked to response runbooks
Security operations
Detection test and runbook link
6.5
Every enabled surface has a tested evidence path for the investigation questions it must answer
Security operations + compliance
Scripted-action reconciliation report
6.6
Review records show quarterly recertification and out-of-cycle reviews after defined trigger events
AI governance lead
Review history
6.7
Anthropic checklist implementation notes
Inventory Anthropic surfaces separately: Claude Web, Claude Mobile, Claude Desktop (Chat / Cowork / Code), Claude Code, Claude Design, Claude in Chrome, Claude Tag, Claude for Microsoft 365, and the Anthropic API & Agent Platform. They can share an organization but differ in endpoint exposure, execution location, available controls, and evidence.
Within Claude Desktop (Chat / Cowork / Code):
Chat uses the managed Claude workspace and connector policy, while the desktop installation adds endpoint, local file, local MCP, and extension considerations.
Cowork may run remote research tasks or use local folders, apps, browser actions, and computer use. Record the execution path for each approved workflow. Anthropic currently excludes Cowork and its Microsoft 365 add-ins from audit logs, the Compliance API, and data exports, so test the available OpenTelemetry feed and downstream application evidence before production.
Code brings the Claude Code agent into the desktop. Apply local repository, shell, filesystem, network, approval, and managed-settings controls in addition to desktop deployment controls.
Claude Code also runs through the CLI, IDE integrations, and hosted or remote workflows where enabled. Treat each path separately:
CLI and IDE: local operating-system identity, repository trust, shell, filesystem, credentials, MCP servers, hooks, sandboxing, and egress are the primary boundaries.
Desktop Code: the same local agent risks apply, plus app deployment, updates, local extensions, and desktop permissions.
Hosted or remote tasks: review remote environment isolation, secrets, repository access, egress, retention, spend, task termination, and server-side logs.
Remote dispatch: preserve initiator attribution and test session and task revocation.
Claude Design should appear in the product inventory when enabled, with its input assets, generated outputs, sharing behavior, retention, and audit evidence reviewed. Claude Tag belongs in the hosted-agent column, including Slack scope, service accounts, Access bundles, retained memory, spend limits, Agent Proxy egress, and evidence across Claude, Slack, and connected systems. Managed Agents belongs under the Anthropic API & Agent Platform; apply API project, SDK, dependency, hosted-runtime, retention, and observability controls rather than creating a separate workforce-app category.
Anthropic documentation
Applicable Harmonic guide
OpenAI checklist implementation notes
Inventory OpenAI as ChatGPT Web, ChatGPT Mobile, ChatGPT Desktop (Work / Codex), Codex, and the OpenAI API Platform. Keep the ChatGPT workspace, local Codex clients, Codex cloud, and API organization or project controls separate even when the same person uses them.
Within ChatGPT Desktop (Work / Codex):
Work is an agentic workspace that can research, create files and sites, use connected apps, and, where enabled, interact with the local computer. Review connected-app scopes, local permissions, browser or computer-use boundaries, generated artifacts, publishing, and the gap between message evidence and action evidence.
Codex runs coding-agent workflows from the desktop. Apply repository trust, sandbox, approvals, filesystem, network, MCP, plugin, hook, and managed-configuration controls.
Codex also runs in the CLI, IDE extension, web or cloud tasks, and remote workflows:
CLI and IDE: local repository, shell, filesystem, credentials, MCP, hooks, sandbox, approvals, and egress are the main boundaries.
Desktop Codex: add desktop deployment, update, local application, plugin, and endpoint controls.
Web or cloud tasks: review environment isolation, repository access, cloud secrets, egress, retention, spend, task termination, and hosted evidence.
Remote dispatch: preserve initiator attribution and test task, session, and credential revocation.
For the OpenAI API Platform, inventory organizations, projects, service accounts, API keys, model and tool access, data controls, rate and spend limits, and logs. Treat the Responses API and Agents SDK as application and hosted-agent components. Agent Builder is a low-code builder in transition and is scheduled for shutdown on November 30, 2026; new and migrated workflows need an owned target architecture and migration date.
The Enterprise Compliance API covers messages and responses across Chat, Work, and ChatGPT-authenticated Codex, but not Work files, actions, or tool calls. API-key-authenticated Codex follows API organization and project settings and does not appear in ChatGPT Compliance API exports. Keep a separate evidence row for each path.
OpenAI documentation
Applicable Harmonic guides
Frequently asked questions about the AI security checklist
When should the checklist run?
Run it at intake, the pilot gate, production expansion, and quarterly recertification. Run it earlier after incidents, material vendor or architecture changes, new data classes, autonomy changes, or ownership changes.
Should every row be required?
No. The deployment model, data class, and risk tier determine which rows apply. A skipped row needs a rationale. A required control that is not met needs a time-bounded exception or a rollout stop.
What counts as evidence?
Prefer reproducible evidence: configuration exports, policy files, event samples, reconciliation reports, contract terms, and test results. Screenshots and attestations are fallbacks when the provider offers no export, and they should be reviewed more often.
Who maintains the checklist?
One security owner should maintain the checklist structure. Identity, platform, endpoint, data, privacy, legal, procurement, incident response, and business owners remain accountable for the evidence in their domains.
Applicable regulations and frameworks
G.1 Map your controls to NIST AI RMF and CSF 2.0
This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes.
G.3 DORA and AI resilience in financial services
Conditional: for a DORA-regulated workflow, this supports risk-based rollout, control validation, and recovery readiness.
G.5 SANS Critical AI Security Guidelines mapping
This article implements relevant SANS Deployment Strategies and GRC guidance.
G.6 Write an AI Acceptable Use Policy that holds up
This article supplies a technical or process control used to enforce the acceptable-use policy.
G.8 ISO/IEC 42001 AI management system
This article supports ISO/IEC 42001 AIMS preparation through readiness evidence for operating the management system.
G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.
Related handbook guidance
Last updated
Was this helpful?