How do you stand up an AI agent security program in 90 days?

For many businesses, AI agents have rewritten what’s considered possible to achieve in ninety days. But what if you’re creating an AI agent security program? Then their proliferation actually makes life much more difficult than even a year ago.

So let us set the scope: within ninety days, you can get some level of visibility and control over the agents already running in your environment. This isn’t a full AI security program, and it’s important not to overpromise here because AI takes many shapes and forms in a modern organization.

When we say “control”, there are actually four outcomes we’re talking about: an inventory, a named human owner, contained privilege, and logs good enough to run an investigation when something inevitably goes wrong. 

Your north star is the ability to answer the following questions:

• How many agents do we have, and where are they?
• Who owns each agent?
• What can each agent do if it misbehaves or is compromised?
• Would we know if something goes wrong?

It might be tempting to start with policy, since it has no prerequisites, but visibility should come first. The policy will be easier to write once you know what it applies to, and what the emergent workflows are.  

What’s already covered by identity programs

Good news! You probably already have some of the agentic surface covered by existing identity work, both human and non-human. If you’ve applied least-privilege to human identities and secrets, agents that use them will be bound by that level of access. 

That said, your coverage is probably insufficient in at least three areas:

Agents act with delegated human authority

The agent’s user is not necessarily the person whose OAuth grant or personal token was used in that agent’s creation. Their access might be different, leading to confused deputy scenarios. Moreover, your access review logic is probably built for humans, and not for unattended processes.

Effective privilege is the sum of many parts

Let’s say an agent has two different tools, both of which are scoped correctly in isolation, but not in their mutual context. Two MCP servers that look reasonable on their own can combine to form an exfiltration path. One can only read the customer table; the other can only post to external webhooks. The agent is the glue. 

Agent behavior is non-deterministic

A nightly job that makes the same six API calls for a year has a baseline. An agent given the same instruction twice takes two different paths, both of which may be legitimate. You’ll need to rethink baselines, and understand that detection has new limits. Not only that, anomaly alerts tuned for service accounts will produce a lot of noise when agents use those accounts. 

But what about the models?

Model choice barely changes the agent's risk profile. Credentials and tools matter much more. And so, the operating principle for the quarter should be to control the identity and the tool surface.

Days 1 to 30: count the agents, then rank them by blast radius

Week 1: Decide what counts as an agent

Here’s a sample list:

• Vendor copilots with tool access
• Agents within SaaS platforms
• Internal agents built on a model API
• MCP servers
• MCP clients
• Coding agents
• Chats with privileged access

Which of these matter to you? Are there more? Decide before you count, both to avoid taxonomy arguments and because every org is somewhat different. And don’t fret too much over it; your number only has to stay consistent with itself.

Weeks 1 to 3: Discover

Unfortunately, no single source will see all of your agents unless that source was built for that purpose and collects data from multiple sources.

• The identity provider will show you OAuth application grants, consent records, service accounts, and credentials with no interactive login history.
• Cloud and SaaS audit logs will show you which principals call APIs at machine cadence, and which human accounts show API activity with no matching console sessions.
• Secrets stores and source control will get you keys to model providers, tokens committed to repositories, and things named after an agent framework.
• Egress telemetry will pinpoint traffic to model provider endpoints from hosts that shouldn’t be producing it.

And let’s not forget the human channel, which finds more than any scan. Ask engineering managers what their teams are running, and announce an amnesty window with no consequences for declaring shadow AI. 

Week 3: Assign an owner to every agent

One agent, one named human. Don’t let teams talk you into putting the whole team as an owner. If no one claims responsibility, publish a list of decommissioning candidates with a retirement date. 

Week 4: Rank by blast radius

For each agent, write one sentence answering what it could do with an attacker in full control, stated in impact. Can it move money? Read the customer table? Merge to main? That’s the sentence you’ll rank by. The top ten agents are your starting point. 

Do remember that the list starts to lose relevance the moment it’s finished, because someone’s bound to create another agent. 

Day 30 Exit criteria

• Definition published
• Registry populated against a documented schema
• Every agent carries a named owner or a decommissioning date
• Top ten ranked
• Baseline metrics captured

Days 31 to 60: Cut privilege on the top ten and close the front door

You have the inventory and now it’s time to reduce privilege where it matters. At this stage, you also should set up a gate to prevent unchecked agent growth. 

Week 5: Threat model the top ten on one page and one hour each

You’re moving fast, so there’s no time for full STRIDE on every agent. Instead, just ask a few questions and take this week to answer them: 

• What untrusted content reaches it? 
• Which tools can it invoke? 
• What credentials does each tool hold? 
• What can an attacker do with those tools and credentials? 

Weeks 5 to 7: Right-size permissions against observed use

Some of your agents will be running on a human’s token. To right-size their permissions, you will first need distinct identities for each of them. You will then need to make sure that the person responsible understands they’re now in charge of those identities too. 

When this is done, pull granted scope and used scope from 30 days of logs and cut the delta. Check two weeks later to find what you over-cut. 

For tool combinations, the scope should be reviewed by the set rather than for each grant, because of the aforementioned effective privilege. 

You still need to accept that you’ll break some quarterly jobs, especially with wildcard cloud roles getting right-sized. Publish an appeal path before you act, so that owners can get their things approved quickly. 

Weeks 6 to 8: Remove standing credentials from the top ten

Where you can, replace long-lived keys with short-lived, workload-bound credentials. It won’t always be possible because many third-party SaaS agents offer only a long-lived API token. For those, scope reduction + monitoring is probably the best-case scenario. Still, don’t call it “least privilege”.

Week 8: Create the intake gate with an SLA attached

You want to enable agents, not just restrict them, so your intake gate should be as streamlined as possible. A one-page form and a 48-hour turnaround will probably invite far fewer shadow AI attempts than a 5-page form and a month-long approval process. 

Day 60 Exit criteria

• The top ten agents are threat-modeled
• Granted-versus-used delta is cut
• No standing long-lived credential on a top-ten agent without a dated, signed exception
• Intake gate is live and was used at least once

Days 61 to 90: Make the controls survive your attention moving elsewhere

Weeks 9 to 10: Publish a logging standard and implement it for the top ten

Logging agentic activity is a world unto itself, and we have a full checklist for it[link]. 

Weeks 10 to 11: Build two detections and run one tabletop

Once you have a logging standard, you should start building detections. Don’t overdo it, start with two: an agent invoking a tool for the first time, and an agent acting outside its established pattern. Both are relatively easy to implement once you log actions, and catch real issues. 

Then run a 90-minute tabletop on a poisoned-tool scenario. The ClawHavoc campaign supplies a realistic script: IBM X-Force reported that attackers uploaded more than 1,100 malicious skills to the OpenClaw community repository in early 2026, several of which became among the most-downloaded packages there. Your agents install their tools from somewhere, so put that somewhere in the exercise.

The real output of this exercise is a list of things you can’t do yet. 

Week 11: Write the runbook around the gaps you find

Who can suspend an agent? How fast? On whose authority? What breaks? You need to know these before there’s a fire, together with the business owner.

Week 12: Baseline the maturity model and write the next two quarters

Score the model in its current state while showing the progress since day 0, and name the three things you deliberately didn’t do. Then start planning what to do next, because chances are, your work is just beginning. 

Day 90 Exit criteria

• Logging standard published and live for the top ten
• Two detections in production
• Runbook tested in a tabletop and signed by a business owner
• Maturity baseline scored
• The 91-to-180 plan approved with funding

The twelve weeks on one page

What you will not fix in 90 days

These should be in your plan, but trying to get to them early will stall needed progress:

• Prompt injection resistance at the model layer. Treat every agent as compromisable through its inputs and contain the consequences instead. 
• Runtime policy enforcement everywhere. 90 days lets you do it for the top ten at best, usually through a gateway in front of that subset.
• Vendor agent assurance at depth. You will read documentation and ask questions, but real assurance of a SaaS vendor's agent takes contract cycles, not quarters.
• Agent-to-agent trust. If multi-agent systems are already in production, you need to work on it, but you’ll need the single-agent controls underneath them first.
• Maintaining any of this by hand. Check the creation rate in week 12: how many agents appeared during the quarter while you worked on the ones you already had? You now know your deficit, if such exists, and what to build or buy next. 

‍