How we solve it.Piece by piece, with provenance.

Initial. No coordinated AI governance. Teams self-manage AI usage with self-selected tools and providers. No AI-specific policies, procedures, or safety/ethics guidance.

Repeatable. Initial AI usage policies established with basic guidance (e.g., "do not share sensitive enterprise or customer data with generative AI"). No AI-specific governance structures or designated management in place. Policies include high-level safety/ethics statements. Some AI-related procedures documented but not consistently followed across the organization.

Defined. AI team, AI Council, AI Center of Excellence, or equivalent in place to guide usage. Initial AI policies in use for AI-supported development, AI-powered applications, or both. Basic adoption of procedures, standards and benchmarks (e.g., AICM). Partial control objectives established for at least one provider. AI deployment/application registry in place. General AI safety guidelines established.

Capable. Central AI team has subject matter experts for current AI models/providers and responsibility and authority to set rules/baselines. Developer policies for AI usage in place with training. AI security control objectives for AI-supported development and applications in use, with initial automated tracking. AI safety policies established for different use cases. Cross-functional AI ethics/safety review process for high-risk use cases.

Efficient. Governance is monitored and managed using automated tooling (models/provider version compliance, guardrails coverage, agent/MCP registries). Defined process to update control objectives/specifications as AI providers and tools add/modify services and release new models. AI ethics review board in place with enforcement authority.

Initial. No visibility into enterprise AI usage. AI-powered applications and AI coding assistants are untracked. Individual teams self-manage AI tools and services without centralized oversight. No technical controls to restrict or manage AI service usage.

Repeatable. AI usage tracked through available means (billing analysis, endpoint telemetry, manual surveys). Approved AI platforms and developer tools identified but enforcement is policy-based or limited to provider-managed settings. Basic security requirements for AI deployments documented. No automated discovery of AI services or coding tool usage. AI feature settings managed for major SaaS platforms (e.g., Microsoft 365 Copilot) but not consistently.

Defined. Initial technical controls for AI services on primary cloud platform (e.g., AWS SCPs restricting Bedrock models, Azure Policy for Copilot, GCP Organization Policy for Vertex AI). AI coding assistants deployed via enterprise licensing with centralized administration (e.g., GitHub Copilot Business/Enterprise). Dedicated cloud deployments (account/subscription) provisioned for AI workloads. AI service inventory maintained for primary platforms but discovery remains manual.

Capable. Consistent organizational policies enforce approved AI services and models across cloud accounts. Enterprise controls for AI developer tools enforced (approved assistants, security code review agents). Initial use of AI-SPM or cloud-native tools for automated AI service discovery. Unmanaged AI discovery capability covering both AI services and unauthorized coding tools. Visibility into models, endpoints, agents, and dependencies. Blast radius controlled through account/subscription isolation.

Efficient. Automated, continuous AI discovery across cloud platforms and developer environments. Shared security services leverage automation for efficiency. Policy-as-code for AI service restrictions integrated with provisioning pipelines. AI-SPM integrated into security operations with automated alerting on unmanaged AI or policy violations. Org-level AI controls updated proactively as providers release new models/services. Automated workflows to bring discovered unmanaged AI under management or block.

Initial. AI services and developer tools accessed using personal credentials, shared credentials or user impersonation. Agents inherit full user permissions without scoping. No distinction between human and non-human identities. API keys manually managed with broad access. No MCP or tool authorization in place.

Repeatable. Initial use of service accounts or managed identities for AI workloads. SSO for enterprise AI chatbots. Basic OAuth integration for AI application access. Agent permissions defined but not scoped to tasks, agents typically receive user's full authorization. MCP servers, if used, rely on static API keys. Initial documentation of which agents access which resources.

Defined. Dedicated service accounts or managed identities provisioned per AI workload and enterprise AI application. Enterprise AI platforms and SaaS AI features (e.g., Microsoft 365 Copilot, Salesforce Agentforce) managed through provider IAM controls. OAuth or similar standards used for primary MCP tool authorization. Agent credentials managed with rotation and revocation procedures. Initial least-privilege policies for enterprise AI agents documented. Customer-facing AI applications include authentication and consent management.

Capable. Distinct non-human identities established for AI agents across deployment types (enterprise-built, SaaS-embedded, developer tools). Delegation and consent flows implemented (users explicitly authorize agent actions). On-behalf-of authorization patterns with tokens reflecting both user and agent identity. Agent identity integrated with enterprise IdP for supported technologies. MCP tool authorization with fine-grained scopes. AI developer tools consistently tag their commits/actions with agent identity.

Efficient. Automated agent identity lifecycle management integrated with AI deployment pipelines. Just-in-time, ephemeral credentials for agent operations (tokens expire after task/session). Delegation chain validation for multi-agent workflows with transitive trust boundaries enforced. Full auditability from user intent through agent actions to resource access. Policy-as-code enforcement for agent authorization. Continuous validation of agent permissions against intent. Customer-facing AI identity flows secured with consent management and revocation.

Initial. No AI-specific monitoring. Reliance on cloud and/or AI provider default logging, if enabled. No visibility into prompts, agent actions, or AI service usage. AI activity untracked and unauditable.

Repeatable. Basic AI service logs collected (model invocations, API calls) and initial token/cost tracking for major AI platforms. Logs retained in the provider but not regularly analyzed for security. No prompt or response capture. AI usage logs reviewed for billing or troubleshooting but not security.

Defined. Prompt/response logging implemented for key AI applications (with appropriate data handling/masking). Agent action logging captures tool calls and resource access. Initial AI-specific alerting (e.g., guardrail violations, information disclosure). Logs aggregated into central SIEM. MCP and tool invocations logged.

Capable. Comprehensive AI telemetry across applications, including prompts, responses, agent actions, delegation chains, and data access. AI-specific threat detection in place (prompt injection, jailbreak attempts, anomalous patterns). Delegation chain auditability for multi-agent workflows. Alerts integrated with SOC workflows. Sensitive data detection in key AI inputs/outputs.

Efficient. Real-time AI security monitoring with automated response capabilities. Full auditability from user intent through agent actions to resource access. AI behavioral baselines with anomaly detection. Proactive threat hunting for AI attack patterns. AI monitoring integrated with incident response playbooks.

Initial. AI workloads run on general-purpose infrastructure with default security settings. No dedicated or isolated environments for AI training or serving. Network segmentation between AI and other workloads is absent. Hosting infrastructure for AI not differentiated in vulnerability management or monitoring.

Repeatable. Basic separation between AI development, training, and production environments (e.g., separate accounts/subscriptions or network segments). AI hosting infrastructure included in standard vulnerability management. Initial security configurations documented for AI compute and serving environments but inconsistently applied.

Defined. Standardized AI infrastructure architecture with documented security baselines. Training and inference environments isolated with defined network boundaries. AI workloads provisioned using Infrastructure-as-Code with security configurations. Hosting infrastructure integrated into CSPM/CNAPP coverage. Hardening and resilience standards applied to AI compute resources.

Capable. AI infrastructure initial use of zero trust architectures. Model and app serving workloads implement runtime security monitoring and enforcement. Confidential computing evaluated for high-sensitivity training and inference workloads. Deployments managed using IaC with security checks in the pipeline. Resilience includes system prompts, agent configurations, and other AI-specific components.

Efficient. Zero trust architecture consistently enforced across AI infrastructure. Immutable infrastructure patterns for AI hosting where feasible. Confidential computing deployed for high-sensitivity workloads. AI infrastructure security continuously validated and adapted as new attack vectors emerge. Infrastructure changes automated with security gates.

Initial. Models deployed without security or safety review regardless of deployment type. For self-hosted models, no integrity controls or restrictions on unsafe file formats. For PaaS/API models, default configurations used without security assessment. No evaluation of third-party or open models before use. Model provider security posture not assessed.

Repeatable. Basic security requirements documented for model deployments (e.g., system prompt requirements). Third-party and open models undergo risk review for major deployments, including basic safety evaluation. For self-hosted models, unsafe file formats recognized but enforcement inconsistent. For PaaS/API models, initial configuration reviews performed. Model provider security assessments conducted for primary providers.

Defined. Standardized security and safety (bias/harm/hallucination) requirements for models based on deployment type and risk classification. Self-hosted models require integrity verification and secure file formats. PaaS/API model configurations hardened per documented standards. Formal risk assessment process for third-party and open models. Model versioning and rollback capability established. Initial monitoring for model behavior and performance in production.

Capable. Model signing and provenance verification enforced for self-hosted models. Automated configuration validation for PaaS/API deployments. Adversarial robustness testing standard for production use cases. Continuous monitoring for model drift, degradation, safety, and anomalous behavior across deployment types. Model risk metrics tracked and reported through governance processes.

Efficient. Automated model security verification across deployment types integrated into pipelines. Real-time monitoring with automated alerting on drift, safety issues, or anomalies. Adversarial testing integrated into CI/CD with defined thresholds. Proactive updates to model security controls as providers release changes or new attack vectors emerge.

Initial. AI applications rely solely on traditional application security controls. No AI-specific input or output validation. Prompt injection risks unaddressed. No guardrails for model interactions. Agentic components and MCP servers, if used, deployed without security boundaries or tool restrictions.

Repeatable. AI-specific application risks identified (prompt injection, insecure outputs). Initial input/output validation for AI components or some apps. Guardrails deployed for some high-risk applications. Basic API security for AI endpoints (authentication, rate limiting). Agent tool permissions defined but inconsistently enforced. MCP servers, if used, deployed without formal security review.

Defined. AI application security requirements documented. Input validation standards include prompt injection mitigations. Output filtering requirements defined for sensitive content. Guardrails deployed for critical AI applications but coverage incomplete. Initial agent security boundaries defined with tool access restrictions. MCP/A2A integrations undergo security review for new deployments. Initial AI-specific security testing.

Capable. Guardrails deployed consistently across production AI applications. Input/output validation automated in deployment pipelines. Runtime protection monitors AI application behavior. Agent orchestration hardened against drift and unauthorized actions. Human-in-the-loop enforced for high-risk agent actions; alerting otherwise. AI-specific security testing integrated into CI/CD.

Efficient. Guardrails continuously tuned based on emerging attack patterns. Real-time detection and response for prompt injection and output anomalies. Agentic security automated with policy engines governing tool access and multi-agent interactions. AI application red teaming conducted regularly.

Initial. AI data repositories (training data, vector stores, RAG sources) rely on general-purpose data security controls. No differentiation between AI and other data assets. Data provenance for training and fine-tuning for self-trained models not tracked. Vector databases deployed with default access controls. No validation of data sources used for grounding or retrieval.

Repeatable. AI-specific data risks identified (poisoning, RAG leakage). Training and fine-tuning data sources documented for critical models. Basic access controls on vector databases. Basic validation (source approval, format checks) for external sources used in RAG. Sensitive data handling requirements documented for AI contexts but inconsistently applied.

Defined. AI data security requirements documented by data type (training, fine-tuning, RAG, embeddings). Data ingestion restricted to approved, documented sources with format validation before use. Vector databases use tenant or application isolation to prevent cross-context access. Sensitive data filtering applied to training and grounding sources (e.g. PII scanning). Initial data versioning for critical AI systems.

Capable. Data sources and transformations documented and auditable for production AI systems. Automated data validation integrated into AI pipelines where applicable. Permission-aware retrieval implemented for RAG tool calls (query results filtered based on user access to source data). Comprehensive data versioning with ability to trace data changes over time.

Efficient. Data lineage integrated with model inventory for end-to-end traceability (for training). Permission-aware retrieval standard across RAG deployments. Scanning for detection of potential data poisoning or adversarial patterns in training/RAG. AI data security controls updated proactively as new attack vectors emerge.

Initial. No AI-specific risk assessment. AI providers and models selected by business units or individuals without security involvement. Existing general vendor assessment processes (if any) applied inconsistently to AI. No differentiation between AI services and other technology procurements. No registry of approved AI providers or models.

Repeatable. Security performs risk assessments for major AI providers and platforms when requested. Initial provider registry documents approved AI providers (may be informal, e.g., spreadsheet). Basic evaluation criteria established (e.g., data handling, SOC 2 compliance). Security engaged for some AI project risk assessments but not consistently. Initial broad data classification requirement set for all providers/models.

Defined. Initial AI provider/model assessment process using industry frameworks (e.g., AI-CAIQ, AICM). Major provider/model registry documents approvals by data classification/type. Initial AI-specific project risk assessment process for AI applications. Open/third-party models require documented risk evaluation before use. Providers reassessed on a scheduled basis (typically annually) or after significant changes.

Capable. Provider/model registry with service and model approvals based on data types/use cases. Application risk registry includes AI risk rating. Risk assessments and management plans integrated into the AI project lifecycle starting at design/architecture. Provider assessments and mitigating controls consistently updated when providers release new models or significant service changes. Initial automation to track major provider/model updates requiring reassessment.

Efficient. Automated discovery of AI services and models in use via CSPM and AI-SPM tooling feeds risk process. Consistent monitoring for provider and model updates with alerting to trigger reassessment and mitigation processes. Application risk registry integrated with AI discovery tooling for visibility across the enterprise. Defined, efficient process to rapidly assess and manage new provider releases and model updates. Risk dashboards aggregate provider and application risk data.

Initial. No controls over AI coding assistant usage; developers self-select and configure tools. No visibility into which AI tools are accessing enterprise code. AI components (models, libraries) not differentiated from other software dependencies. No awareness of AI-specific supply chain risks. Traditional SCA may flag some AI library vulnerabilities but no AI-specific assessment.

Repeatable. AI coding assistant risks identified (code exposure to model providers, insecure code suggestions). Some approved AI coding tools identified but enforcement inconsistent. Initial documentation of AI components in use (models, AI libraries, services). Basic guidance on AI tool usage (e.g., "don't paste sensitive code into public AI chat"). AI libraries included in standard SCA scanning but no AI-specific checks.

Defined. Enterprise-managed AI coding assistant deployed (e.g., GitHub Copilot Business/Enterprise) configured to prevent code exposure to model training. AI coding tool usage tracked via enterprise licensing and administration. AI components included in existing SAST/SCA scanning processes. AI providers and major AI components documented in supply chain inventory. Open models require integrity verification (checksums, safe file formats) before use.

Capable. SAST/SCA tools include AI-specific assessment capabilities (insecure AI-generated code patterns, AI library vulnerabilities). Security testing consistently integrated into pipelines for AI-generated and AI-assisted code. AI security agents integrated into CI/CD for automated code review. AI supply chain inventory includes models, versions, MCPs, and dependencies (initial AI-BOM). Model provenance verification for self-hosted models. Automated scanning blocks known-vulnerable AI libraries and unsafe model formats.

Efficient. Multiple AI development tools supported (coding assistants, coding agents) with consistent enterprise security controls. On-demand agent-based security assessments available in IDE for developers. AI security agents integrated into pipelines for automated code review. Comprehensive AI-BOM generated and maintained. Model signing and provenance verification standard for production deployments. Supply chain monitoring alerts on new vulnerabilities in AI dependencies.

Initial. No AI-specific audit/compliance actions. AI deployments treated the same as any other application with no recognition of unique AI requirements. No tracking of AI model or training data licensing. No verification that AI deployments meet internal safety/ethics policies established in governance.

Repeatable. AI-specific compliance requirements identified (e.g., EU AI Act risk classifications, data privacy regulations, sector-specific AI rules). Assessment of AI deployments against internal policies performed when requested. Initial documentation of model and dataset licensing for some deployments. No systematic process to verify compliance with AI safety/ethics policies.

Defined. AI providers, models, and services assessed for regulatory compliance and approved for use with different data types (aligned with provider registry). Scheduled compliance assessments of AI deployments against internal AI governance policies (safety, bias, transparency requirements). Model and training data licensing tracked and verified for in-scope deployments. Manual compliance reporting includes AI-specific controls and standards (e.g., AICM, ISO 42001). Manual AI-CAIQ for some external facing apps. Privacy impact assessments conducted for AI deployments handling personal data.

Capable. Continuous assessment of AI deployments using automated tooling for technical compliance (guardrails coverage, data handling, access controls). Bias and fairness audits conducted for high-risk AI use cases per governance requirements. License compliance automated for models and major AI components. Compliance status integrated into AI deployment registry. Reporting partially automated with AI-specific (or enriched) compliance dashboards. AI-CAIQ automated for major external apps.

Efficient. Continuous compliance monitoring across AI deployments with automated evidence collection. Real-time verification of safety/ethics policy compliance integrated into deployment pipelines. Comprehensive license tracking automated. Compliance reporting fully automated with dashboards covering AI-specific regulations, internal policies, and industry frameworks. AI-CAIQ generation automated for external apps. Proactive monitoring for emerging AI regulatory requirements.

Initial. No AI-specific incident response capabilities. AI deployments treated the same as any other application incident. No AI-specific telemetry collection (prompt logs, model activity). IR team lacks awareness of AI-specific attack types. Incidents involving AI systems are handled ad hoc without AI-specific procedures or expertise.

Repeatable. Incident response team designated for AI incidents with basic manual processes. Initial AI-specific telemetry collection in place for some deployments (prompt/response logs). Major AI attack categories documented (prompt injection, data leakage, model abuse) but no formal detection. Cloud and application IR processes extended to cover AI deployments. Basic AI incident documentation.

Defined. Initial AI-specific playbooks (prompt injection, data exfiltration, model abuse, unauthorized usage, compromised agent credentials, tool misuse). IR team trained on AI-specific threats and response procedures. Input/output monitoring in place for high-risk AI deployments. Responders have read access to AI deployment configurations, logs, and telemetry. AI incidents categorized and tracked separately from general application incidents.

Capable. Threat intelligence for AI systems integrated into program. Input/output security telemetry tools (guardrails, prompt injection detection) deployed for production AI systems. AI security alerts integrated with SIEM for correlation and tracking. Agentic threat detection (tool abuse, prompt injection, anomalous delegation) via log analysis. Response automation available for common AI incidents via SOAR integration. Responders can escalate to administrative access for AI system containment.

Efficient. Runtime AI security monitoring with behavioral analysis detects anomalous activity (unusual tool calls, unexpected data access patterns). Automated response for agentic AI threats (agent hijacking, MCP attacks, memory manipulation). Comprehensive telemetry capture (prompts, responses, tool executions, context state). ChatOps or workflow automation engages AI/development teams for rapid incident validation. Detection rules continuously refined based on emerging AI attack patterns and threat intelligence.