The CISO's Five-Phase AI Defense Framework
Over the past year I have had versions of the same conversation with many security leaders. It starts with confidence: clean scans, a recent audit, EDR on every endpoint. Then I ask one question.
"If a working exploit for your most critical system appeared four hours from now, and the attacker used an agent to move through your cloud accounts, what would actually happen?"
The room usually goes quiet. Not because these leaders are doing a poor job, but because their programs were designed for a slower adversary.
This chapter is the plan. Five phases, each with specific actions and a deliverable. Timelines, budget splits and scorecards here are my recommendations, built from experience and the data in earlier chapters. Adjust them to your environment.
The Honest Starting Point
Most enterprise programs share five gaps:
- Scanning covers known classes. Logic flaws and chains are mostly invisible.
- Patch velocity is measured in weeks. Real-world numbers are often two to four times the policy number.
- Machine identities are ungoverned. No complete inventory, little rotation, no behavioral baselines.
- Teams are stretched. Adding AI-driven threats on top of current workload breaks teams that do not automate.
- Board reporting is about compliance. "Compliant" and "defended against an agentic attacker" are different claims.
None of these are failures of effort. They are design limits. The phases below address them in order.
Phase 1: Map Your AI Attack Surface (Weeks 1-4)
You cannot defend what you have not mapped.
Action 1.1: Codebase risk inventory. Catalog the software you build and operate, and score each system on these factors:
| Factor | Why it matters |
|---|---|
| Language and memory safety | C and C++ carry memory corruption risk; every language carries logic risk |
| Business criticality | Customer-facing and revenue systems first |
| Exposure | Internet-facing and untrusted-input paths first |
| Code age and churn | Old, rarely touched code hides old bugs |
| Dependency depth | Deep trees mean inherited risk |
Action 1.2: Dependency audit. Produce a software bill of materials for critical systems. For each key dependency, record who maintains it, how quickly they ship security fixes, and whether it is likely to receive AI-discovered disclosures. Expect a higher volume of advisories in widely used open source.
Action 1.3: Machine identity inventory. Run the discovery step from Chapter 5: secrets in code and CI, cloud roles, OAuth grants, certificates and every AI agent credential.
Action 1.4: Patch velocity baseline. Measure real time-to-remediate for your last ten critical vulnerabilities, end to end.
Action 1.5: AI usage inventory. List sanctioned AI tools, the agents your teams have built, and what data and systems each can reach. IBM found shadow AI was a factor in 43% of AI-related breaches. Ask business units directly what they use.
Deliverable: an attack surface map ranking your systems, dependencies and identities by risk, plus a measured gap against your patching targets.
Phase 2: Deploy AI-Augmented Discovery (Weeks 4-8)
Use the attacker's method on yourself first.
Action 2.1: AI code review in CI/CD. Add AI-based security review to pull requests for your most critical repositories. Tune it to catch authorization flaws, injection, unsafe deserialization and cryptographic misuse. Block merges on high-confidence high-severity findings.
Action 2.2: Scheduled deep scans. Run agentic discovery against your highest-risk codebases on a schedule, in isolated environments, with results flowing into your normal vulnerability workflow. If you qualify, Anthropic's Cyber Verification Program and similar programs from other providers give vetted defenders access to stronger models with fewer restrictions.
Action 2.3: Attack path analysis. For your five crown jewel systems, merge findings across tools and run the chain analysis from Chapter 3.
Action 2.4: Cryptography review. Audit TLS configuration, certificate validation, key management and password storage. Pay particular attention to custom crypto code and outdated libraries.
Action 2.5: Add triage capacity. Budget analyst time to validate and route AI findings. Without it, discovery only grows your backlog.
Deliverable: AI-augmented scanning on critical repositories, a first set of identified attack paths, and a triage process that can absorb the output.
Phase 3: Compress Detection and Response (Weeks 8-12)
Speed is now the main defensive variable.
Action 3.1: Automate tier-1 response. Most alerts follow known patterns. Automate enrichment, evidence capture, initial containment (isolate host, revoke token, block IP) and ticket creation. Keep human analysts for judgment.
Action 3.2: Pre-authorize decisions. At 2 a.m. you need action, not approvals. Agree on these in advance with leadership:
| Scenario | Pre-authorized action | Escalate when |
|---|---|---|
| Exploited zero-day in a production dependency | Virtual patch, enhanced monitoring, emergency change window | Evidence of exploitation in your environment |
| Leaked or misused machine credential | Revoke and rotate, review its activity logs | Access to sensitive data confirmed |
| AI agent behaving outside baseline | Suspend the agent, preserve telemetry | Unauthorized action confirmed |
| Compromised third-party integration | Revoke its OAuth grants and tokens | More than one integration affected |
Action 3.3: Implement patch tiers. Same day automated, 72 hours for production, seven days maximum for crown jewels, as described in Chapter 4.
Action 3.4: Prioritization feeds. Wire KEV, EPSS and vendor threat intelligence into your vulnerability tooling so the queue reorders itself as exploitation signals change.
Deliverable: automated first response for common patterns, signed-off playbooks for four high-impact scenarios, and patch tiers in operation.
Phase 4: Machine Identity Governance (Weeks 12-20)
This is the phase most organizations have not started, and in my view it carries the highest return.
Action 4.1: Separate agent identity management. Run agent identities through a dedicated system or a clearly separated part of your IAM stack, built for short-lived, per-agent, task-scoped credentials.
Action 4.2: Automated rotation, by risk.
| Credential type | Target rotation or lifetime |
|---|---|
| Agent credentials for sensitive systems | Minutes to hours, issued per task |
| Production service accounts | Daily or short-lived tokens |
| Internal tooling | Weekly |
| Development and test | Monthly, never reused in production |
Action 4.3: Behavioral baselines. Instrument agents, collect two to four weeks of telemetry, then alert on sustained deviations and first-ever denials.
Action 4.4: Orphan cleanup. Suspend every machine identity without a named owner. Re-enable only on request with an owner attached.
Action 4.5: Runtime policy. Add approval gates for irreversible agent actions.
Deliverable: a governed machine identity program with ownership, rotation, monitoring and runtime controls for your most sensitive agents.
Phase 5: Build AI-Literate Teams (Ongoing)
Technology without skilled operators is theater. Chapter 8 covers this phase in depth. The short version: train your SOC on AI-driven attack patterns, stand up a small internal AI red team, and run quarterly exercises that assume a four-hour exploit timeline.
Deliverable: a team that can use AI offensively against your own systems and recognize AI-driven attacks against them.
Budget Allocation
A starting split for new AI defense spending, which you should adjust to your gaps:
| Category | Share of AI defense budget | Notes |
|---|---|---|
| AI-augmented discovery and detection | 30-35% | Include triage capacity, not only tools |
| Machine identity governance | 20-25% | Often starting from near zero |
| Response automation | 15-20% | SOAR, playbooks, patch automation |
| People: training and hiring | 15-20% | The most commonly underfunded line |
| Threat intelligence | 5-10% | Exploitation signals and AI-specific feeds |
The most common mistake I see is buying a platform that generates thousands of findings and staffing it with three analysts. Fund the people who act on the output.
Vendor Evaluation Scorecard
Every security vendor now claims AI. Use weighted criteria to cut through it:
| Criterion | Weight | What to ask |
|---|---|---|
| Chain and path detection | 25% | Can it show how findings combine into attack paths? |
| Machine identity coverage | 20% | Does it baseline service accounts and agents, not just users? |
| Precision | 20% | What is the validated true positive rate in production deployments like mine? |
| Integration | 15% | Does it feed my existing CI/CD, SIEM, SOAR and ticketing? |
| Vendor security posture | 10% | SOC 2 Type II, pentest results, disclosure policy, incident history |
| Cost predictability | 10% | Are compute-driven costs capped and transparent? |
Ask for evidence, not demos. A demo against a vendor-chosen repository proves little. Run a short proof of concept against one of your own codebases and compare the output to what your team already knows. My guide to AI tokens helps when you need to sanity-check usage-based pricing.
Board Communication
Boards respond to clear framing, evidence and a plan. Four frames work well:
- The threat changed, with data. Cite the 29-minute breakout time, AI involvement in one in four malicious breaches, and the first autonomous agent intrusions.
- Our specific gaps. Be honest. Use the three tiers of residual risk from Chapter 3, and show patch velocity against target.
- The plan. Present the five phases with dates and deliverables.
- The economics. Compare the investment to the cost of an AI-enabled breach, which IBM puts around $6 million on average, before regulatory and reputational costs.
Replace "number of open critical vulnerabilities" with three metrics: known attack paths to critical assets, median days to remediate critical exposures, and percentage of machine identities with an owner and a rotation policy.
For more on structuring security conversations with boards and buyers, see the resources in The CISO Desk.
The 90-Day Quick Start
If you can only do part of this now, do this:
- Week 1: Machine identity inventory.
- Week 2: Measure real patch velocity for the last ten criticals.
- Weeks 3-4: Suspend orphaned identities; rotate the 10 riskiest credentials.
- Weeks 5-6: AI code review on your most critical repository.
- Weeks 7-8: Sign off playbooks for your top three scenarios.
- Weeks 9-10: Behavioral detection on your most critical production system.
- Weeks 11-12: Tabletop exercise with a four-hour exploit timeline and an agent-driven intrusion. Write down where it broke.
Key takeaways
- Five phases: map, discover, respond faster, govern machine identity, build the team.
- Each phase has a concrete deliverable you can report.
- Fund triage and people alongside tools.
- Evaluate vendors on your own code, with weighted criteria.
- Report attack paths, remediation time and identity coverage to the board, not raw vulnerability counts.
No organization can do all of this alone. The same properties that make AI-driven attacks dangerous make collaboration necessary. Chapter 7 tells the story of the largest experiment in collaborative AI defense so far.