Security Team Checklist

A practical checklist for security teams deploying AI tools across identity, data, runtime, supply chain, observability, and rollout.

Security Team Checklist

Last reviewed: August 18, 2026

Work through this checklist before widening an AI rollout. Each item links to the handbook article with implementation guidance. Record the owner, evidence, last test date, and any exception with an expiry date in 7.3 The security team checklist.

Identity

• Managed user surfaces use SSO where the provider supports it; unsupported surfaces and login exceptions are documented. (1.1)
• MFA, conditional access, session lifetime, reauthentication, revocation, device-loss, and emergency-access behavior are defined and tested for every authentication path. (1.1)
• SCIM or a documented joiner, mover, and leaver process covers every approved AI surface. (1.1)
• Roles and groups restrict high-risk capabilities, not only access to the platform. (1.2)
• Personal-account use is blocked where tenant restrictions are supported; other surfaces have a tested detection and remediation path. (1.3)
• Shadow accounts, unmanaged organizations, and accounts on verified domains are discovered and remediated. (1.4)
• Agents and other non-human identities have dedicated credentials, named owners, and revocation paths. (1.5)
• API keys and service accounts are inventoried, scoped, stored, and rotated. (1.6)
• Human approval is required before autonomous systems take actions beyond the approved baseline. (1.7)

Supply Chain & Extensibility

• Connectors and apps are reviewed, approved, and scoped to the minimum permissions. (2.1)
• Local and remote MCP servers are inventoried, authenticated where applicable, and assessed before use. (2.2)
• An MCP gateway or equivalent managed restrictions enforce the approved server and tool policy. (2.3)
• Skills and instruction bundles are reviewed; creation and sharing are restricted by role. (2.4)
• Plugins, marketplaces, and extensions are reviewed at intake and after material updates. (2.5)
• Hooks and lifecycle scripts are inventoried; untrusted or unowned scripts are blocked. (2.6)
• The agent bill of materials records every model, SDK, connector, MCP server, skill, plugin, hook, package, image, template, knowledge source, and tool with its owner, source, version, permissions, and review trigger. (2.7)
• The extension review record names the owner, version, scopes, data classes, evidence, and next review date. (2.7)
• Signed packages, trusted distribution paths, version pinning, and update behavior are verified where supported. (2.8)
• SaaS agent builders are treated as supply chain, including templates, connections, publishing, and sharing. (2.9)
• Hosted-agent frameworks, SDKs, tools, models, and other dependencies have owners and an update-review process. (2.10)

Runtime, Sandbox & Autonomy

• Each execution surface has a documented isolation model and centrally enforced baseline where supported. (3.1)
• Approval policies default to the least privilege needed and protect destructive or high-impact actions. (3.2)
• Agent network egress is restricted and tested; allowed destinations are owned and reviewed. (3.3)
• Browser and internet access are restricted by cohort and sensitive internal sites are protected. (3.4)
• Computer-use and desktop-control capabilities are disabled unless required and explicitly approved. (3.5)
• Scheduled and background tasks use minimum permissions, bounded runtime, and defined stop conditions. (3.6)
• Remote dispatch, mobile triggers, remote sessions, and SSH paths are authenticated, attributable, and revocable. (3.7)
• File access is limited to approved roots; home directories, secrets, and cloud-synced folders are excluded unless needed. (3.8)
• Hosted triggers are authenticated and replay-resistant; control-plane policy cannot be changed by the agent runtime. (3.9)
• Hosted agents use task-scoped credentials, tenant and task isolation, egress controls, spend and rate limits, action limits, and tested stop and recovery controls. (3.9) (3.9)

Data Protection & Residency

• Every approved AI surface has a tested DLP enforcement or evidence path; unsupported paths and gaps are documented. (4.1)
• Data classes are mapped to allowed tools, actions, connectors, and deployment models. (4.2)
• Processing, storage, support, log, and subprocessor regions are verified for each surface. (4.3)
• Retention is configured and tested; Zero Data Retention limitations are understood before regulated use. (4.4)
• Training and data-use terms are confirmed for each product, plan, and authentication path. (4.5)
• Knowledge bases, embeddings, vector stores, memory, fine-tuning and evaluation data, caches, backups, traces, and exports have owners, retention, deletion, access, and regional controls. (4.4)
• Cross-app flows, generated artifacts, publishing, and sharing are included in the data-flow review. (4.6)
• Secrets and credentials are excluded from prompts, tool parameters, logs, and agent configuration. (4.7)

Threats & Incident Response

• Prompt-injection controls are tested against untrusted content and connected tools. (5.1)
• Exfiltration paths through tools, connectors, files, URLs, and generated artifacts have been tested. (5.2)
• Vulnerabilities and supply-chain advisories for enabled AI components are tracked and remediated. (5.3)
• Tool and memory poisoning, spoofed results, identity confusion, confused deputy, SSRF, cross-tenant access, replay, approval races, and denial-of-wallet are covered in design and testing. (5.4) (5.4)
• High-risk workflows are red-teamed before expansion and after material changes. (5.5)
• The incident runbook covers revoking sessions, connectors, credentials, tasks, and published artifacts, and has been exercised. (5.6)
• Each material AI workflow has a current threat model covering data, identity, tools, runtime, and trust boundaries. (5.7)

Observability, Audit & Evidence

• Known audit gaps are documented per product, authentication path, and execution surface. (6.1)
• Agent telemetry uses a versioned schema and captures identity, surface, runtime, model, policy, tool, approval, target, result, error, cost, and correlation fields. (6.2)
• Delivery latency, completeness, source health, clock drift, schema drift, sampling, and retention are measured and reconciled. (6.2)
• All available compliance and audit sources are collected; coverage and exclusions are tested and recorded. (6.3)
• Usage and spend analytics are reviewed for adoption shifts, anomalies, and unowned activity. (6.4)
• SIEM detections are selected from the approved threat scenarios, tested, and linked to response runbooks. (6.5)
• Every enabled surface has a tested evidence path for the investigation questions it must answer. (6.6)
• Controls are recertified at least quarterly and after incidents, major vendor changes, new data classes, or ownership changes. (6.7)

Rollout & Operations

• The rollout plan defines the approved scope, risk tier, owner, pilot cohort, training, support, and expansion gates. (7.1)
• A tested exit plan covers stopping work, revoking access, ownership transfer, exports, deletion, artifacts, schedules, and billing. (7.1) (7.1)
• Pilot success metrics include security-control tests and clear go, hold, and stop criteria. (7.2)
• Every checklist decision has evidence, a named owner, a last-tested date, and a time-bounded exception where needed. (7.3)
• Required controls are selected by deployment model, data class, and risk posture. (7.4)

Related handbook guidance

• AI Security Handbook
• 7.3 The security team checklist
• 7.4 The vendor-neutral control matrix
• 7.2 Pilot design and success metrics
• 6.7 Continuous review cadence