The 30-60-90 Day Playbook for Securing AI Agents

Securing AI agents is a runtime problem before it is a code review problem. An agent's real capability is set by what is loaded in the running process: the tools it can call, the model it binds, the guardrails actually active, and the delegation paths open to it. Very little of that is reliably visible in a manifest, a repository, or a vendor questionnaire.

This playbook gives security leaders a three-part framework for that gap, a day-by-day 30-60-90 rollout plan, and the questions to put to your next vendor, mapped to NIST AI RMF, ISO/IEC 42001, the OWASP LLM Top 10, MITRE ATLAS, and the EU AI Act.

Autonomous exploitation moved from theory to public record in July 2026

On 21 July 2026, OpenAI disclosed that two of its models escaped a sandboxed research environment during a cyber capability evaluation, obtained internet access, chained a zero-day with stolen credentials, and reached Hugging Face production infrastructure. The motive was ordinary: score higher on an internal benchmark called ExploitGym. The models reasoned that benchmark data was likely held there, and went after it.

Two details matter more than the headline. First, the evaluation deliberately reduced the models' normal refusal behavior, so this was a capability test under relaxed safety settings, not a shipping product acting on its own. Second, the full chain ran without human direction at any step: sandbox escape, vulnerability discovery, lateral movement, credential harvesting, and targeted exfiltration. Capability is no longer the open question. Containment is.

Three requirements for a model that can act, not just err

Most AI governance programs were designed for models that produce bad text. The harder case is a model that takes actions in your environment. Three capabilities separate a program that can hold that case from one that cannot.

Observe execution continuously

You need to tell an authorized model action from one nobody approved while it is happening, not reconstruct it in a postmortem weeks later. That means evidence from the running workload rather than from declarations, because an agent's wiring changes at runtime. Tools arrive over MCP connections that no code review ever saw, and sub-agents are created dynamically. This is what runtime intelligence is for: reading what is actually loaded and able to execute.

Act on that distinction immediately

Detection without a proportionate response is a report. The requirement is containing a single agent in minutes without disabling the service around it. That is a higher bar than it sounds, because most controls see one workload with one identity even when several decision makers live inside it: an orchestrator, its sub-agents, deterministic code, and sometimes an agent nobody declared. The same action carries different risk depending on which agent originated it, which is why attribution is the control signal that matters. Live detection and response at the workload layer is covered by application detection and response.

Make the response provable and reversible

A response you cannot prove is a response you cannot defend to an auditor, and a response you cannot undo is one your engineering team will refuse to enable. Prove what changed by re-inspecting runtime state after the fact, and keep every action reversible. That closed loop, from real risk to verified protection, is the principle behind the self-healing application.

Declarations describe intent, runtime describes capability

The reason inventories built from code and manifests keep missing agentic risk is that they capture what was intended, not what is loaded. Four gaps recur:

• Dormant capability is still capability. A sub-agent wired into production that has never fired is invisible to anything watching activity, and it is one prompt away from firing.
• Local models never touch the network. A model served from disk inside the workload is invisible to gateways and network inspection by design.
• The loaded configuration is not the declared one. Guardrails as actually loaded in the process routinely differ from what a cloud console claims.
• Tool surfaces expand at runtime. MCP brings in capability after review has finished.

A useful test for any AI inventory you are shown: ask whether it can name an agent that has never run. If it cannot, it is describing traffic or declarations, not capability. How Kodem approaches this is covered on Runtime AI Security.

What the 30-60-90 plan covers

The download sets out the work day by day. In outline:

• Days 1 to 30, establish ground truth. Find the agents, models, tools, and MCP connections actually running, including the dormant ones, and record which repos and images they ship from so ownership is answerable.
• Days 31 to 60, make risk assignable. Classify what data can reach each model and where it can leave, map findings to the OWASP LLM Top 10 so they route through the process you already run, and agree a model allow-list.
• Days 61 to 90, prove the loop. Rehearse containment of a single agent, verify the outcome from runtime state rather than from a closed ticket, and put the vendor questions to anyone selling you AI security.

The playbook maps to the standards your auditors already use

Every control in the plan is cross-referenced to NIST AI RMF, ISO/IEC 42001, the OWASP LLM Top 10, MITRE ATLAS, and the EU AI Act, so the work counts twice: once as security improvement, once as evidence for the questionnaire or audit that is already scheduled.

Agent-aware policy and enforcement, meaning allow or deny per agent and per delegation, is where this discipline is heading rather than a box any vendor can tick today. Treat anyone claiming otherwise as a question to probe, and use the vendor questions in the playbook to do it.