The Defender’s Guide to AI Agents·Chapter 10

Your First 90 Days Securing AI Agents

Your first 90 days

Nothing here requires a budget. Most of it requires asking questions and writing down the answers, and the value is mostly in how long the answers take to arrive.

Weeks 1-3 · Find out what is already true

You are not introducing AI to your organization. You are discovering it. Whatever you find here is your real baseline, and it will be larger than anyone expects.

  • List every AI system in use. Start with what is approved, then go looking: the permissions granted to applications in your identity platform, outbound traffic to AI services, expense claims, browser extensions.
  • For each one: what can it read, what can it do, whose account does it use, and which human owns it.
  • Mark the ones that both read content from outside the organization and hold real permissions. That list is your priority order for everything that follows.
  • Ask whether any of them have memory, and whether any memory store is shared between an agent that reads outside content and an agent with more access.

The list itself is worth less than two facts about it: how long it took to produce, and how many entries surprised somebody.

Weeks 4-8 · Start collecting, and write two lists

  • Turn on whichever of the six events from Chapter 5 you can get today. You will not get all six. Get tool calls first.
  • Spend two weeks establishing what normal looks like, per the end of Chapter 5.
  • Write the destination list: where each agent is allowed to connect. Start in alert mode, move to blocking once it is quiet.
  • Write the tool list: what each agent may call, pinned to a version, with a person's name against each entry.
  • Build the first eval set for your most consequential agent. Forty cases from real traffic.

Weeks 9-12 · Change something structural

  • Take the highest-risk agent from week 3 and split it: one identity reads, a different identity acts.
  • Give every agent its own account with an expiry date and a named owner.
  • Agree the authority ladder for consequential actions - what is pre-authorized, what needs one approver, what needs two - and write it down before you need it.
  • Put the three change classes from Chapter 8 into your existing change process. This costs a meeting and nothing else.

The gate between stages is evidence, not the calendar.

You move forward when you can answer four questions from data: where are all the agents, what identity does each hold, what can that identity actually reach, and what did it do last week. If you cannot answer those, the next stage will be built on a guess.

Say this on Monday

"Give me two weeks and no budget and I'll tell you how many AI agents we have, what they can reach, and who owns them. I suspect none of us knows."


Ten questions for whoever is building this

Take these into the room. They are ordered so that the first three are easy to answer well and the last three are not - and how someone handles the last three tells you more than the answers themselves.

1What sources of content does this agent read, and which of them can someone outside the company write into?
The second half is the attack surface. A good answer is a list. A vague answer means nobody has drawn the boundary.
2What can it actually do - not in the design document, in the live permissions?
Ask them to read it from the system while you watch. The gap between intended and actual is where the risk lives.
3Whose account does it use, and which human owns it?
"A shared service account" and "nobody, really" are both findings.
4If this agent were perfectly manipulated tomorrow, what is the worst single thing it could do?
Not "could it be manipulated" - assume yes. The value of the question is that it forces a specific answer.
5Does it have memory, and can anything it remembers be read by an agent with more access?
If yes, that path around your access controls deserves attention ahead of most of your open findings.
6Which model version is pinned in production, and where is that written?
If the answer is a short name with no date, it is probably floating. If they are not sure, that is the answer.
7What do we log, and could we reconstruct a decision from six months ago?
Walk a specific past action through with them. The moment it breaks down is the gap.
8What test set proves it still works, when did it last run, and what did it score?
Three parts on purpose. Most teams have an answer to the first and not the second.
9Where is it allowed to connect, and who wrote that list?
If no such list exists, this is the cheapest significant control still available to you.
10What is our plan if the provider retires this model in thirty days?
It happens, notice periods vary wildly, and a plan that has never been exercised is not a plan.

Say this on Monday

"I'd like thirty minutes with whoever built this, and I'm bringing ten questions. None of them are about the model."

About the author

Jessen Kurien is a cybersecurity leader and the author of The Defender’s Guide to AI Agents. His 18+ years in cybersecurity include nearly 15 years at Microsoft, work as part of the founding team of the Microsoft Threat Intelligence Center, and detection engineering leadership in Microsoft Defender XDR. His work connects investigations, detection engineering and security operations with the evidence and accountability needed for AI security and governance.

Meet Jessen

Connect with Jessen Speaking, workshops and training

This guide will go out of date.

Providers change how their logs work, models get retired, and new cases get disclosed. Ask to be told when this changes — no newsletter, just the updates.

Get told when it changes

Download the complete guide (PDF)

The telemetry contract, detection specifications, framework mappings and checklists are also published as files — the defender pack, CC BY 4.0, free to reuse.