Held to the weakest of People, Process, Technology (L1, tier 2 not yet evidenced). Autonomy sits within the gate. A self-assessment, never a measured or certified result.
The maturity radar
Self-assessed
Maturity · governance (AISMM · L1–L5) · this function
How well-governed Application & DevSecAIOps Security is across the 12 AISMM categories, L1 hub to L5 rim. Measures 5 of 12; dashed spokes are outside scope, not zeros.
Autonomy · AI adoption (AI-CMM · L1–L4) · the org portfolio
How far AI adoption has advanced in each of the 8 security functions, Manual → Autonomous — the wider frame Application & DevSecAIOps Security sits in. our model · calibrated to SAE J3016.
AI adoption (AI-CMM)
Levels1 Manual2 Assisted3 Augmented4 Autonomous
1 Identity Security
2 Network & Infrastructure Security
3 Endpoint & Workload Security
4 Application & DevSecAIOps Security
5 Data Security
6 Cloud & Container Security
7 Security Operations
8 Security Governance, Risk & Assurance
Two axes: governance maturity (AISMM, 5 levels) vs AI autonomy (AI-CMM, 4 levels, our authored ladder). Set targets below to see the dashed overlay. The autonomy lens is the org portfolio, self-assessed where a run exists, illustrative otherwise.
Govern · AISMM
L2.2
Repeatable · avg of 5 categories
Adopt · AI-CMM
L1.0
Manual · our model · calibrated to SAE J3016, not a Cloud Security Alliance (CSA) standard
The gate
Within the gate
Coverage governs autonomy up to L2. Autonomy sits within what the controls can catch.
Govern reads the AI Security Maturity Model (AISMM); Adopt reads the AI Cyber Maturity Model (AI-CMM).
FoundationInformation security: Not yet profiledCloud: Not yet profiledPrivacy: Not yet profiled
Capability · People · Process · Technology
The same control answers, read on the three dimensions a program is actually managed by (our lens over Cloud Security Alliance (CSA) control text). Capability is bounded by the weakest dimension, tooling alone can’t carry it.
PeopleAdministrative · evidence by document L1 Initial2 asked · capped: tier 2 not yet evidenced
TechnologyTechnical · evidence by instrument → L3 Defined6 asked
Capability, bounded by PeopleL1 Initial · tier 2 not yet evidenced
The lever names itself: weak People is fixed by training and champions; weak Process by runbooks and review cadences; weak Technology by vendor features, automation or fitted skills. The PPT grouping is our authored interpretation of the CSA control objectives.
Where you are (L3 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.
The next rung (L4 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.
Verbatim from CSA AISMM v3.7; your level stays a provisional self-assessment.
Infrastructure Security and Resilience L2 Repeatable
What L2 looks like for Infrastructure Security and Resilience · the next rung
Where you are (L2 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.
The next rung (L3 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.
Verbatim from CSA AISMM v3.7; your level stays a provisional self-assessment.
What L2 looks like for Data Security · the next rung
Where you are (L2 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.
The next rung (L3 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.
Verbatim from CSA AISMM v3.7; your level stays a provisional self-assessment.
What L3 looks like for App Security · the next rung
Where you are (L3 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.
The next rung (L4 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.
Verbatim from CSA AISMM v3.7; your level stays a provisional self-assessment.
Where you are (L1 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.
The next rung (L2 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.
Verbatim from CSA AISMM v3.7; your level stays a provisional self-assessment.
Peer benchmark
Not enough peer data yet for Application & DevSecAIOps Security — need at least 5 other orgs’ runs, currently 0. No comparison is shown below that floor; this is a real count, not a placeholder.
Autonomy by workflow step (AI-CMM)
Code review L1 Manual
Dependency / SCA L1 Manual
Threat modeling L1 Manual
AppSec testing L1 Manual
Model-build assurance L1 Manual
Plays. Can this function run them at its current autonomy?
Each play names the controls it requires before running at an autonomy level, and the key performance indicator (KPI) it moves. Judged here at your current adopt level (L1) from this run’s answers, a control the diagnostic didn’t ask about reads not yet assessed, never assumed. Browse the full catalog →
Secure code-review assistAI-secure the enterpriseKPI: Security-review turnaround ↓0/3 controls evidenced3 not yet assessed✓ no gaps found
LLM guardrails / prompt-injection defenseSecure the AIKPI: Attack catch rate ↑0/2 controls evidenced2 not yet assessed✓ no gaps found
AI SDLC tollgate reviewsSecure the AIKPI: % of AI-assisted PRs passing all gates pre-merge ↑0/3 controls evidenced3 not yet assessed✓ no gaps found
Use cases: each play plotted on the grid
Use cases are the third placeable unit, alongside functions on /board and AI Controls Matrix (AICM) domains on the per-run card. v1 seeds one canonical use case per play in this function; your own concrete instances replace these as the measurement layer ships. Ungoverned dots (⚠) signal the gate caught autonomy ahead of maturity.
Autonomy × Maturity — each play in this function plotted as a use case
Maturity (AISMM) →
Mature autonomyUngoverned ⚠Over-controlledNot started
Secure code-review assistAI-secure the enterpriseM2 · A1
LLM guardrails / prompt-injection defenseSecure the AIM2 · A1
AI SDLC tollgate reviewsSecure the AIM2 · A1
Maturity from this run’s governance reading; autonomy capped at min(your function’s autonomy, the play’s catalog ceiling). All use cases are within the gate at the current reading. Real per-use-case grading arrives with the measurement layer.
Gaps register
The hard gaps to close, consolidated: every cell where autonomy outran the control’s maturity, the workflow steps running ahead of the gate, and the controls you marked absent. This is the diagnosis the action plan below is fitted to, not a coverage scoreboard.
cellIAM-08Are access rights to AI systems reviewed on a tracked cadence, with exceptions managed?autonomy L2 · governed to L1
cellI&S-04Are the hosts and OS running AI workloads hardened to a defined baseline?autonomy L2 · governed to L1
cellI&S-06Are production and non-production AI environments segregated?autonomy L2 · governed to L1
cellDSP-07Is data protection by design applied to AI data pipelines?autonomy L2 · governed to L1
cellAIS-01Is there an application security policy covering AI-enabled apps and their interfaces?autonomy L3 · governed to L2
cellAIS-03Are application security metrics tracked for AI-enabled applications in operation?autonomy L3 · governed to L1
DSP-07Is data protection by design applied to AI data pipelines?Data Security · L3 control
AI analysis
Get a short, plain-language reading of this run’s levels: the one pattern worth naming and the single next step with the best payoff.
Takes about 30 seconds.
Ranked action plan: the fitted few
Targeted at your weakest capability dimensions. Each gets interventions of its own kind: weak People means training, never another tool; weak Process means runbooks and policies; weak Technology draws from vendor features, automation, and the curated core skill set, never the full library. Candidates from the play catalog; fit happens per ecosystem.
People · L1 → L2
Capped: tier 2 not yet evidenced.
PeopleReviewers trained on verifying AI findings (not rubber-stamping them) · Secure code-review assist
PeopleReviewers trained to verify AI-flagged findings — not rubber-stamp them · AI SDLC tollgate reviews
Process · L2 → L3
Capped: DSP-07 absent.
ProcessAttack-class register maintained per LLM app; guard re-fitted as classes evolve · LLM guardrails / prompt-injection defense
ProcessEight-stage gate sequence (Plan · Code · Build · Test · Release · Deploy · Operate · Monitor) wired into existing CI · AI SDLC tollgate reviews
PolicyAI-use policy that defines what counts as an AI-assisted PR + when the human attestation is mandatory · AI SDLC tollgate reviews
Technology · L3 → L4
Weakest dimension at Defined.
Vendor AI featureCode-platform AI reviewer scoped to security rulesets · Secure code-review assist
Deterministic automationCI-native gate runners triggered on PR + model-release events; advisory comments at Assisted, blocking at Augmented, hard-block + human attestation at Autonomous · AI SDLC tollgate reviews
Vendor AI featureGitHub Advanced Security / Snyk / FOSSA snippet scan / cdxgen AIBOM, scoped to the gates they cover · AI SDLC tollgate reviews
Core skills (curated set, the inventory is raw material)
Implementing Semgrep For Custom Sast Rules · Secure code-review assist
Integrating Sast Into Github Actions Pipeline · Secure code-review assist
Detecting Ai Model Prompt Injection Attacks · LLM guardrails / prompt-injection defense
Rollout: phased from your reading
Each AISMM category for Application & DevSecAIOps Security is sequenced by its current level. Weakest categories land in Start now; the rest follow as Next and Later. Targets are capped at L5. This phasing is derived; re-assess to see it shift.
L1
L2
L3
L4
L5
Governance
Move from L1 → L3. Blocker: tier 2 not yet evidenced.
Data Security
Move from L2 → L4. Blocker: DSP-07 absent.
Infrastructure Security and Resilience
Move from L2 → L4. Blocker: tier 3 not yet evidenced.
App Security
Plan for L3 → L5 once Phase 1 controls land.
IAM
Consolidate at L5 after the earlier phases.
Start now
Next
Later
Current
Target
Set your own targets
Pick where each category should land. The roadmap below sequences the gaps Foundational first, then Structural, then Procedural — CSA’s own domain ordering, not an invented dependency graph — and by gap size within a domain.
IAM
L3 nowL3
Infrastructure Security and Resilience
L2 nowL2
Data Security
L2 nowL2
App Security
L3 nowL3
Governance
L1 nowL1
Independent assessment
A second, independent read of the same run — an auditor or a peer team answering the same controls. Saved separately; it never overwrites the self-reported track above.
Implement
Tick the prescribed skills as you fit and operate them. Re-assess to see the categories move.
Implemented 6/4
Progress
This is the first run for Globex · Application & DevSecAIOps Security. Re-assess later to track movement here.
Roll-up to the board
This function owns these AICM domains on the board. Each board number is this reading’s evidence, nothing modelled — re-assess any function and its row moves. This is the second altitude: see the portfolio →
AIS L3 Defined
Light read now, deeper read next
What you have here is the light, self-assessed read: fast, honest, and enough to see where autonomy has outrun governance. The deeper read is what turns it into proof.
This read (light)
Self-assessed against real control objectives
A headline posture and the gate verdict
The gaps register and the fitted few to close them
The next read (deep)
Each control verified against evidence, not self-report
Task-level before/after measured on the few skills adopted
The same motion run across functions to stand up the practice
Only the deep read earns the word measured; everything on this page is self-assessed until then.
Self-assessed and indicative, governance from AICM control coverage (AISMM), autonomy from the AI-CMM ladder (our model · calibrated to SAE J3016). Skill-to-objective fit is illustrative at this stage. Framework pins: CSA AICM v1.0.3, AI-CMM v1 (our construct), CSA AISMM, CSA AI-CAIQ v1.0.2.