Every security program eventually gets marked to market; the only question is whether you set the position before the loss prints or after it.
Why a 90-Day Agent Governance Plan Matters Now
The agents are already inside the perimeter. Gartner’s CIO survey puts 17% of organizations running AI agents in production today, with another 42% planning deployment inside twelve months. That means the “wait and see” option does not carry a zero baseline — it carries unhedged exposure that compounds every sprint. You are already long the risk. You just haven’t priced it.
The problem is timing. Most governance programs stall in committee for twelve to eighteen months while legal, identity, and data-classification workstreams negotiate scope. The fleet does not wait for the committee. By the time the “correct” sequence — identity, then classification, then enforcement — clears its first gate, the exposure has already migrated from a handful of sanctioned copilots to dozens of unsanctioned standalone agents with full filesystem reach. A 90-day plan is the difference between marking your book on a schedule you control and discovering the loss at settlement.
| Signal | Figure | Source |
|---|---|---|
| Organizations with AI agents in production | 17% | Gartner CIO Survey |
| Planning deployment within 12 months | 42% | Gartner CIO Survey |
| Unauthorized agent transactions caused by internal violations through 2028 | ≥80% | Gartner |
| Flagged agent actions that are internal or unintentional, not malicious | 88% | Ospiri research |
The headline number that should reframe the program: through 2028, at least 80% of unauthorized agent transactions will come from internal violations — oversharing, misuse, misguided autonomy — not external attackers. This is not a perimeter problem. It is a policy-and-observability problem, and it is endogenous. You cannot firewall your way out of your own employees’ agents by treating them as intruders.
Three Ways to Sequence This — and Why Two of Them Stall
Before the runbook, the strategic choice. There are really only three sequences a CISO can pick, and the default instinct — do identity first, properly — is the one that quietly blocks the business.
| Sequence | What it optimizes | Time to first control | Failure mode |
|---|---|---|---|
| Identity-first | Clean IAM and data classification before any enforcement | 12–24 months | Business deploys agents anyway; governance arrives after the exposure |
| Block-by-default | Maximum control posture on day one | Weeks | Engineering revolts; tool gets ripped out in two quarters |
| Wait-and-see | Avoiding premature vendor lock-in | Indefinite | Exposure accrues with no offsetting position |
| Enablement-first (90-day) | Observability and enforcement now, identity in parallel | Days to weeks | Requires accepting that identity matures after visibility |
The enablement-first path inverts the textbook order on purpose. Enforcement and observability ship in weeks because they sit at the kernel and don’t need a finished identity graph to function. Identity, classification, and full information governance are real twelve-to-eighteen-month projects — so you run them in parallel, not in series, and you stop letting them gate the only controls that can deploy this quarter.
The Runbook: Three Phases, Ninety Days
Gartner’s own recommendation is to “launch a cross-functional initiative to systematically discover, inventory, map and manage all AI agents” and to “trial emerging guardian agents now.” Here is what that looks like as a dated plan rather than a slogan.
-
Day 1–30 — Baseline the book. Deploy enforcement and observability at the kernel layer across the dev estate. Do not write policy yet. The first thirty days are pure discovery: enumerate every agent — sanctioned copilots and standalone downloads alike — and capture what each one actually touches. A median fleet of a thousand developer endpoints typically surfaces eight to fifteen distinct agents, most of them unsanctioned. The inventory itself usually moves the budget conversation inside thirty minutes.
-
Day 30–60 — Codify policy from observed behavior. Now you have a behavioral baseline, so policy is empirical instead of theoretical. Convert the observed access patterns into kernel-scoped rules: which directories, which network egress, which inter-process calls each agent class is permitted. Surface the high-risk shadow agents — the ones with stranger registry persistence than their vendor tag implies — and hand that evidence to whoever owns the AI mandate. You are turning measured exposure into a position limit.
-
Day 60–90 — Integrate and hand off. Fold in the identity, data-classification, and information-governance layers as they mature out of their parallel workstreams, and transition the program from a launch to a standing operation. The kernel controls keep enforcing throughout; the slower identity work attaches to a system that is already producing evidence.
| Phase | Primary output | Owner of record |
|---|---|---|
| Day 1–30 | Full agent inventory + behavioral baseline | Security engineering |
| Day 30–60 | Codified kernel-scope policy + shadow-agent risk register | CISO / AI leader |
| Day 60–90 | Integrated identity/IG layer + ops handoff | GRC + platform ops |
Scoring the Exposure: a Position Limit, Not a Vibe
A 90-day plan needs a number the board can defend, not an adjective. Borrow the discipline from risk management: size each agent the way a desk sizes a position — frequency times severity, adjusted for how far it has drifted from its mandate.
Agent Risk Score = (Permission Scope × Reversibility) + (Frequency × Drift)
| Factor | What it measures | Quant analogue |
|---|---|---|
| Permission Scope | Breadth of filesystem, network, and process reach | Notional exposure |
| Reversibility | Whether an action can be undone (copy-on-write vs destructive) | Recovery / haircut |
| Frequency | How often the agent acts autonomously | Trade velocity |
| Drift | Deviation from the agent’s baselined behavior | Tracking error |
Roll the score up per endpoint, per team, and per org, and you have a posture dashboard that plugs into your existing UEBA and SIEM rather than competing with them. The drift term is the one users underestimate: an agent does not have shame or hesitation, so when it starts touching new directories or issuing new syscalls, the move is faster and less correlated than any human insider’s.
What Kernel Enforcement Adds That the Rest of the Stack Can’t
The reason the 90-day plan is even possible is architectural. Most “guardian agent” tools today support passive monitoring — they observe, they don’t intervene. A dashboard that flagged an action thirty seconds ago is not a control. The distinction that matters is where the enforcement point sits.
| Control point | What it sees | Can it stop an action mid-flight? |
|---|---|---|
| Prompt guardrails (Lakera, Protect AI) | The prompt, before the agent acts | No — the plan is gone by the time it hits the OS |
| API / DSPM monitoring | Metadata on traffic between known systems | No — after the fact, and blind to local filesystem |
| EDR (CrowdStrike, SentinelOne, Defender) | Process-layer telemetry | Partially — instruments the process, not the agent’s kernel scope |
| Kernel-scope enforcement | The action itself, at the syscall boundary | Yes — block or copy-on-write before the write lands |
This is complementary, not competitive. Prompt guardrails and DSPM remain valuable upstream; the agent firewall is the layer that enforces after the prompt resolves, when the agent is actually moving against the filesystem. Copy-on-write is what lets you say yes to deployment without block-on-deny political risk — the agent runs, the destructive write is intercepted, and engineering never files the revolt ticket that kills the rollout in two quarters.
What CISOs Should Do This Quarter
| Step | Action | Output | Effort |
|---|---|---|---|
| 1 | Deploy kernel-layer observability across the dev estate | Agent inventory in 30 days | Low |
| 2 | Baseline behavior before writing any policy | Empirical access map | Low |
| 3 | Codify kernel-scope policy from observed patterns | Enforced position limits | Medium |
| 4 | Run identity and classification in parallel, not as a gate | Program that ships now | Medium |
The Bottom Line
If your agent governance program has a twelve-month timeline, you are running an unhedged position and calling it prudence. The 90-day plan inverts the textbook sequence — observability and enforcement first, identity in parallel — because the controls that can deploy in weeks are the ones that actually contain the 80% of incidents that come from inside the building. Agent governance is not a security tax on AI adoption; it is the enablement layer that lets you approve deployment now instead of staging a year-long bottleneck. The fleet is already growing; the only variable you control is whether you have a baseline before the first incident or after it.
If your team is sizing this for the next budget cycle, request a working session. We will walk through your environment, build your first agent inventory and observability baseline live, and scope a kernel-scope enforcement deployment — the same first thirty days of the runbook above, in 90 minutes.