What You Can Do

The sequence matters more than the speed.

Five chapters of problem. One chapter of plan.

To sum up what we’ve learned: a new era arrived without asking (Chapter 1), agents enter through three distinct launch vectors (Chapter 2), governing them is a practice rather than a document (Chapter 3), securing them means chains and context rather than prompts (Chapter 4), and enforcement only works where agents actually run (Chapter 5).

If you lead security, none of this information changes your budget or your headcount, and your inbox now contains countless vendors using every word in this series. So this chapter is the practical one: what to do first, what to fund, what to ask the vendors, and how to know it's working. One rule from Chapter 5 organizes all of it, because it applies to plans as much as products:

Don't buy the end state. Secure the transition.

The end state — every platform instrumented, every agent registered at birth, every action inspected inline — is not available this year, from anyone, at any price. What is available is the capability that makes every future control smarter: knowing what's operating, what it inherits, what it can reach, and what normal looks like. Money spent there compounds.

The first ninety days

The sequence matters more than the speed. It follows the stack from Chapter 3, bottom-up, because each layer makes the next one work.

W1–2 Discovery

W3–6 Governance

W7–12 Controls

Weeks 1–2: Get the number.

The board's first question (“How many agents do we have?”) has a knowable answer, and getting it requires no new infrastructure. No gateway deployment, no endpoint rollout, no traffic rerouting. Connect what you already run: the identity provider, the major platforms, the network tools, the email layer. Then let discovery work across every vantage point at once.

Two tests tell you whether this step is real. The first is time to first insight. It should be days, not quarters; if the answer requires a six-week deployment, you're buying the wrong layer first. The second is the surprise rate: if the discovered population isn't several multiples of the list IT keeps, the discovery isn't reaching the venues where agents actually live. Expect the number to be uncomfortable.

Weeks 3–6: Confirm names and configurations.

Two workstreams, both unglamorous, and together they carry most of the risk reduction in this plan. First, ownership: every discovered agent gets a named human owner or gets suspended. The operational test from Chapter 3 — someone raises their hand within a day when asked "whose is this?" — becomes policy. Second, posture: the configuration debt that makes agents dangerous gets triaged and fixed, starting with the platforms hosting the most reachable agents. Guest-user exposures, intake features wired to agent triggers, sharing rules from three years ago. This is also when guardrails go onto the agents that matter most — human-in-the-loop and input controls on the customer-facing and privileged minority first.

Weeks 7–12: Identify the queue and the path.

With the population visible, owned, and configured, prioritization becomes possible. Stand up risk tiering that meets Chapter 4's bar — context-aware, chain-explainable, built on the conjunction of capability and reach — so the review queue starts with the agent that can actually hurt you rather than the one with the most findings. Begin the least-privilege review cadence on the top tier. And build the enablement path, because the builders are coming either way: a sanctioned route where marketing ops and finance can ship their agents with secure defaults already applied. Blocking teaches evasion. A good path teaches compliance.

Then runtime, as the doors open.

With the map live, each enforcement point that becomes available — platform hooks, inference-level integration, MCP-layer controls, browser enforcement — snaps into context that already knows what normal looks like. As a budgeting principle: runtime spend performs in proportion to the posture spend beneath it.

The mirror test

Before the vendor conversations, take this self-assessment.

The mirror test: four maturity stages for agent security, from blind to instrumented
Stage	What it looks like
Blind	The three board questions — how many agents, what can they reach, who's accountable — have no current answer. Most enterprises are here, whether or not the policy document says otherwise.
Inventoried	The population is discovered and counted, across all three launch vectors, refreshed continuously. The number exists and is believed.
Governed	Every agent has an owner, posture is managed against baselines, risk is tiered with context, and the review cadence runs. The board questions get answered from instruments.
Instrumented	Enforcement operates where agents run: graduated verdicts fed by the graph, full causal paths in every alert, a kill switch held for the provable compromise.

Remember to follow this order. A vendor selling instrumentation tools to a “blind” organization is selling enforcement that can act but can't judge — Chapter 5's radio with no radar.

Fifteen questions to sort through vendors

Every vendor deck says agent security now. These questions distinguish the ones who built for this problem from the ones who renamed a product, because each is only easy to answer well if the underlying architecture exists.

Discovery and coverage

1. How many independent discovery vantage points does your solution use? What does each one see that the others cannot?
2. Can you find agents that never authenticate through SSO or the identity provider?
3. What is your coverage for agents deployed and managed inside third-party platforms — Salesforce, Microsoft 365, Claude, ChatGPT — where external scanners can't reach? (OWASP AST09)
4. How do you discover an agent nobody registered?

Context and prioritization

5. For an agent you've rated critical: show me the chain. Can an analyst see the complete, reachable attack path — capability, reachability, asset — or is the rating an aggregate score?
6. Does the same finding produce different severities on different agents, based on each agent's exposure, guardrails, and reach? Show me the same issue on a sandboxed agent and a customer-facing one.
7. Can you map what an agent reaches transitively — through OAuth grants, app-to-app connections, and other agents — or only its direct permissions?
8. When one agent invokes another, can you reconstruct the delegation chain — original requester, every hop, final action — or does your audit trail start at the last agent?

Enforcement

9. Which enforcement points do you operate today (platform-native hooks, API, MCP layer, browser, endpoint) and what share of my agent population does each cover?
10. What context feeds an allow/block/redact verdict (identity, permissions, delegation, data sensitivity) or is the decision made on the prompt alone?
11. When you block something, what does the alert contain? I'm looking for the full causal path (agent, chain, data, destination, policy).
12. What happens to my protection when your enforcement component itself is compromised or unavailable? (Ask them to address the LiteLLM incident directly.)

Operations and credibility

13. What has to be deployed for first insight, and how long until I see my real agent inventory? (Days is the right answer. A quarter is a different product.)
14. What does your platform read that it doesn't need? (Specific example: email-based discovery should require headers, never message bodies.)
15. Show me your published research. Look for original threat research, framework contributions, disclosed campaigns, etc. The vendors defining this field are findable in OWASP contributor lists and security press citations, not just their own blog.

Proof this works

The approach in this series isn't hypothetical. Enterprises applying it have taken posture scores from failing to strong within a month of getting the map — one measured program moved from 47% to 91% across 21 platforms in 30 days. CISOs are presenting live agent ecosystem dashboards to boards instead of policy summaries. Security leaders have also used the enablement framing to fund the program itself, positioning agent security as the thing that lets the business say yes to AI faster than competitors who are still guessing.

The era is the argument

AI was a decision, and the industry built a generation of security for the thing enterprises decided to use. Agents aren't a decision. They arrive with the software, ride your people's permissions, build each other, and execute inside platforms you don't control — a population compounding inside a universe with no fixed edges.

They are also the opportunity of the decade. Agents make it possible to take on problems that were unsolvable at human scale, to innovate across departments that never shared a workflow, to put data to work that has sat hidden in systems of record for twenty years. The companies that win this era won't be the ones that held agents at the gate. They'll be the ones that said yes early, often, and safely — because saying yes safely was a capability they built, not a hope they held.

That capability is the one every discipline in this series converges on: See the ecosystem. All of it. Continuously.