Last week, Microsoft shipped an open-source governance toolkit for AI agents. It covers all 10 of OWASP's agentic AI risk categories with sub-millisecond policy enforcement. Solid work.
But what caught my attention wasn't the toolkit. It was that OWASP now has an agentic AI risk list.
That list doesn't exist unless there are enough agents doing enough things causing enough problems. We're there.
The numbers are real. EY rolled out agent-based systems to 130,000 auditors across 150 countries — not a pilot, production. Databricks expanded its Unity AI Gateway to govern which models and tools agents can access. Okta is shipping "identity management for AI agents" by end of April.
The industry is saying something out loud now: we need to know who our agents are, what they can do, and what they've done.
I ran into this practically a few weeks ago.
I was reviewing the permission model in our clinical SaaS. Every record in the system tracks two things: who created it, who last modified it. The system pulls a user ID and writes it in. Simple, sensible design.
Now imagine: a clinic runs an AI agent that recommends appointments, updates treatment timelines, and flags patient notes for follow-up. Something goes wrong — wrong date, wrong procedure assigned to the wrong patient. What does the "modified by" field say?
The agent isn't a user. But it doesn't leave a trace, either.
This isn't a hypothetical. It's a legal problem, a compliance problem, and a product design problem.
Most software was built for humans.
Human login: password. Human role: defined. Human permissions: scoped. Human log: every change tracked, every session tied to an identity you can trace back to a person.
An agent? It comes in on an API key. Usually with broad permissions because flexibility is necessary. Which user context was it operating in? Which business rule did it follow? Who authorized this specific action? None of that is in a standard log.
According to Okta's research, most organizations right now don't know which agents have access to what. No control plane. An admin-level API key can read, modify, and delete across the system — and nowhere does it say who requested it, or why.
Here's the thing: this is where the PM needs to step in.
Identity and permissions look like a security team problem. They're not. Who can do what is business logic. What data the agent can access is a product decision. How that action gets logged is a UX and data model decision.
"Who is this agent?" is a PM question.
In a healthcare product, it gets serious fast. Audit trails aren't optional — they're regulatory requirements. If a patient record gets modified, the "who" carries legal weight. If an agent did it, what does the system say? What does the clinic say?
When you're sitting in front of 17 support tickets and the answer to "who did this?" is "the system" — that's not an answer.
Microsoft's toolkit is a starting point. But the real question is: what happens when an agent uses your product?
Most SaaS products haven't asked this. I hadn't. When I went back and looked a few weeks ago — permission model, audit trail, role hierarchy — everything assumed a human on the other end.
Agent wasn't the assumption. Agent is now the assumption.
And "your agent doesn't have an ID" means it can act anonymously in your system. Anonymous and authorized. Together, that's a combination that doesn't cause problems until the problems are expensive.
I think this lands on product roadmaps in the next 12 months whether teams plan for it or not. The PMs who ask the question now will shape the architecture. The ones who don't will answer for it later — in support queues, in compliance audits, in conversations they weren't expecting to have.
Which agents are running in your product, and with what permissions?