If you are deploying AI agents, copilots, bots, or automation that can read data, call tools, and take action, you do not have an “AI project.” You have an identity problem with better branding.
That sounds harsher than it is. It is also the cleanest way to stay out of trouble.
If you have read my earlier pieces like Beyond Human: Securing Agentic AI and Non-Human Identities in a Breach-Driven World, What Are Non-Human Identities?, or the NHI Ownership Security Checklist, this post is the operating plan behind that thesis: agents are actors, actors need identities, and identities need governance before they become incident fuel.
The real failure mode
Here is the failure mode I keep expecting to see more of.
A company launches a support copilot. It can read ticket context, summarize customer history, pull internal documentation, open follow-up tasks, and post updates into Slack. Everyone feels clever for about three weeks.
Then one of three things happens.
A hidden instruction in a ticket or document changes the agent’s behavior. A tool connector has broader rights than anyone realized. Or a long-lived token tied to the agent gets reused somewhere it should not. Suddenly, the “helpful assistant” becomes a quiet exfil path, a workflow vandal, or a privileged operator with no adult in the room.
That is not sci-fi. It is the same old identity story wearing an AI nametag. OWASP now tracks this class of risk explicitly in both the Top 10 for LLM Applications and the newer Top 10 for Agentic Applications 2026, which calls out risks like agent goal hijack, tool misuse, and identity and privilege abuse.
If that sounds familiar, it should. It is the same problem I wrote about in Copilot, Can You Keep a Secret?: over-permissioned content plus AI retrieval equals silent exfil paths. It is also why I keep coming back to the same boring control first: ownership. “Who owns it?” is still the question most programs skip, and it is still the reason everything else fails.
What this plan is, and what it is not
This is not a grand transformation deck. It is not a “build an AI governance center of excellence” exercise that makes people feel like the problem is handled. It is a 90-day operating plan for getting agent identity under control before your environment turns into a permissioned account graveyard.
The spine here is straight from the NIST AI Risk Management Framework and the Generative AI Profile: Govern, Map, Measure, Manage. NIST is also explicit that this is not a checklist and not a magic order of operations. Good. Real environments are messy. But it is a strong way to structure the work.
The threat lens comes from OWASP’s Securing Agentic Applications Guide 1.0, the Agentic AI Threats and Mitigations, and the GenAI Red Teaming Guide. In plain English: do not just catalog the agents. Threat-model them, exercise them, and assume the toolchain will be abused in ways the happy-path demo never showed you.
None of this should feel alien. Most organizations already do some version of this for enterprise apps, service principals, app registrations, and other non-human access. The problem is not that agents require a completely new governance model. The problem is that teams keep treating them like a special case until they are already in production.
The framework
1. Govern
Start with accountability, not architecture.
Every agent gets:
- a named human owner
- a business purpose
- a list of systems it can touch
- an approval authority for scope changes
- an expiry or review date
Not “Platform Team.” Not “AI Innovation.” A human. A real one.
This is the practical version of what I laid out in Non-Human Identity Management and OpenAI Identity Governance and Least Privilege: discovery is necessary, but it only becomes governance when ownership, review, and least privilege show up together.
2. Map
Now map what the agent actually is.
Not the marketing description. The access reality.
Map:
Identity and control plane
- Identity type
- Tokens, secrets, certs, and keys
- Connected tools
- Write actions
- Approval gates
- Fallback behavior
- Kill switch
Data plane
- Data sources used for grounding or retrieval
- Data sensitivity and classification
- Whether prompts, outputs, or context are stored
- Whether the agent influences future refinement, memory, or tuning
- Retention and logging paths for data it touches
This is where most teams discover they built “a helpful assistant” that can also close tickets, post to public channels, modify CRM records, and read internal docs no one meant to expose. My Identity Is the New Control Plane piece makes the broader point: what determines blast radius is not org charts or intent. It is effective access.
And yes, this includes the data plane. What the agent can access for grounding, retrieval, query, and response is part of the identity problem, not separate from it. If you map the connectors and ignore the data, you have only mapped half the blast radius.
3. Measure
Once you know what exists, measure the risk that matters.
For each agent, answer:
- What can it read?
- What can it write?
- What can it trigger?
- What can it approve?
- What happens if its instructions are manipulated?
- What happens if its token is reused?
- What happens if it operates after the owner leaves?
- What sensitive data can it retrieve or summarize?
- Can it expose regulated or internal-only content to the wrong audience?
- Does bad or poisoned source data change its output in a meaningful way?
- Are outputs reviewable when the source material is sensitive or ambiguous?
This is where the AI world needs to stop pretending it invented security. The measurements you need are painfully traditional: privilege scope, data exposure, actionability, persistence, and detectability. The OWASP Top 10 for LLM Applications and the Top 10 for Agentic Applications 2026 are useful here because they force teams to think beyond prompt injection and into tool misuse, identity abuse, supply chain risk, and unsafe autonomy.
AI efficacy is only as good as the data it can access, and AI trust is no different. If the source material is over-permissioned, stale, poisoned, or poorly classified, the agent can become both inaccurate and dangerous at the same time.
4. Manage
Management is where the plan stops being a workshop and becomes a control system.
This is where you enforce:
- least privilege
- short-lived credentials
- environment separation
- approval gates for high-risk actions
- regular access review
- red teaming
- disable and delete paths for orphaned agents
Microsoft is moving in this direction explicitly with Microsoft Entra Agent ID, which is designed to give agents a more identity-native control plane, and Microsoft’s more recent AI security guidance, which calls out scoped, short-lived access for agent functions. That does not solve governance by itself, but it is a strong signal that the market is moving away from “just use an app registration and vibes.”
The 90-day plan
Days 1 to 30: Stop the obvious badness
Your first month is not about elegance. It is about reducing stupid risk fast.
Do these first:
- Create an agent register.
Every agent, bot, copilot, and automation with autonomous or semi-autonomous behavior goes on the list. If it has credentials, tool access, or data access, it is in scope. - Assign a named owner to every agent.
No owner means no production access. Full stop. - Move credentials into a secrets manager.
If the thing is still living in CI variables, a spreadsheet, or a Slack thread, that is not “temporary.” That is negligence with better fonts. - Classify agents by blast radius.
A useful starter model:- Tier 1: read-only assistants
- Tier 2: workflow agents with limited writes
- Tier 3: privileged or sensitive-action agents
- Freeze net-new production agents unless they are registered.
You need one gate. Make it simple. No register entry, no launch.
This is the same practical logic I used in How to Keep Identity Governance from Breaking During Hypergrowth and the longer Stonegate-style governance work: velocity turns “temporary exceptions” into permanent risk unless you make ownership and expiry real early.
For many teams, this is less a funding problem than a scoping problem. The controls usually already exist. What changes is that agents now need to be brought into those controls on purpose.
Days 31 to 60: Shrink blast radius
Month two is where you stop inventorying and start narrowing the scope.
Do these next:
- Review effective access, not requested intent.
Do not ask what the builder thinks the agent can do. Prove what it can actually do across tools, data, and workflows. - Split read from write.
If the same identity can read sensitive content and take irreversible action, you have built a privilege bundle. Break it apart. - Put approvals in front of high-risk actions.
Examples:- financial approvals
- ticket closure
- repo changes
- identity changes
- customer communications
- production actions
- Use short-lived tokens where the platform supports them.
Long-lived secrets are the gift that keeps on leaking. - Test the top abuse paths.
Use the GenAI Red Teaming Guide and the Securing Agentic Applications Guide to exercise prompt injection, tool misuse, unsafe outputs, and connector abuse before a stranger does it for you.
This is also where AI, Identity Security, and Privileged Access become relevant. AI-powered workflows accelerate privileged execution. They do not remove the need for guardrails. They increase it.
Days 61 to 90: Make it durable
By month three, the goal is not just “less scary.” The goal is repeatability.
Do these last:
- Establish quarterly recertification.
Every agent gets reviewed for owner, scope, connected tools, and continued business need. - Create standard build patterns.
Secure defaults beat heroics. Publish templates for:- read-only agents
- approval-gated agents
- sensitive-data agents
- test-only agents
- Wire agent disablement into offboarding and incident response.
If the owner leaves or the team disbands, the agent should not become a digital ghost with Slack access and production reach. - Add governance evidence.
Keep records of owner, last review, last rotation, tool scope, and exceptions. If you cannot prove control, you do not have control. - Track a handful of metrics that matter.
Start with:- percent of agents with a named owner
- percent using vaulted secrets or short-lived tokens
- percent with high-risk actions behind approval
- mean time to disable an orphaned agent
- percent reviewed in the last 90 days
That is the difference between a one-time cleanup and an operating model.
What “good” looks like at day 90
At 90 days, “good” does not mean perfect.
It means:
- Every meaningful agent is known
- Every meaningful agent has an owner
- High-risk actions are gated
- credentials are not living in the walls
- The worst privilege bundles have been broken apart
- Orphaned agents can be killed fast
- Reviews are on a calendar, not in someone’s memory
That is not glamorous. It is also how you keep the first real agent incident from turning into a board slide.
Final thought
The market is going to spend the next year inventing pretty language for a very old problem.
Do not get hypnotized by the new nouns.
If an agent can read data, call tools, make decisions, or take action, it has identity, privilege, and blast radius. Govern it like you mean it.
And if you need a mental shortcut, use this one:
Day 30: know what exists.
Day 60: shrink what it can do.
Day 90: make the controls stick.
That is the plan. No fluff. Just less future regret.
Tech That MattRs 
Leave a comment