Most organisations discover their AI agent problem in the same way. Someone asks a reasonable question - how many agents do we have? - and nobody can answer it. Not approximately. Not within an order of magnitude.
That's not negligence. Agents get built inside SaaS platforms, wired together in automation tools, and spun up by individual teams solving individual problems. Very few of them pass through procurement or security review, because from the builder's perspective nothing was procured. They configured a feature that was already there.
This guide is about closing that gap: finding the agents you have, giving each one an owner, scoping what it can reach, and watching what it does. If you're still working out why autonomous agents change your risk model, start with agentic AI security - this page assumes you're past that and want a programme.
AI agent governance is the set of processes and controls that determine which AI agents may operate in your environment, what each one is permitted to access, who is accountable for it, and how its behaviour is monitored and reviewed.
It's the operational counterpart to agent security. Security asks what could go wrong. Governance is the programme that keeps it from going wrong at scale - the inventory, the ownership model, the entitlement design, the review cadence.
The framing that makes this tractable: agents are identities, not applications. They authenticate, hold credentials, are granted permissions and take attributable actions. Once you accept that, most of the machinery you need already exists - you're extending identity governance to a new population rather than inventing a discipline.
Discovery is unglamorous and it's the whole foundation. Four approaches, in rough order of yield:
Agents authenticate, so they leave traces. Review OAuth applications and API tokens in your major SaaS platforms and identity provider. Look for grants issued to automation tools, integration platforms and anything with broad scopes that nobody recognises.
This is usually the highest-yield single action, because it catches agents built inside platforms you already administer.
A great deal of agentic workflow lives in iPaaS and workflow tools rather than in anything anyone would call "an AI project." Enumerate what's running there, and specifically what credentials each workflow holds.
Many applications now ship agentic capability as a feature that a tenant admin enables. Nobody procured it; someone toggled it. Check what's enabled across your major platforms and what data each capability can reach.
Low-tech and consistently effective. A short survey — what have you built, what does it connect to, who maintains it — surfaces agents no automated scan will find, particularly ones built on personal credentials.
For each agent found, record six things: what it does, who built it, who owns it now, what credentials it holds, what systems it can reach, and whether it's still needed. That last field closes more agents than any control you'll design.
AI agent discovery covers automating this once the first manual pass is done.
If you implement one control, implement this.
Every agent needs a named, accountable person - not a team, not a distribution list. The owner confirms the agent is still needed, approves changes to its access, and is who gets contacted when it behaves oddly.
Ownership matters disproportionately because every other control depends on it. Access reviews route to owners. Anomaly alerts route to owners. Renewal decisions route to owners. An agent without an owner sits outside all three, and it will still be there at the next review because nobody has standing to retire it.
Two practical notes. Ownership must transfer when people change roles - orphaned agents are usually created by a person leaving, not by anyone deciding to abandon anything. And the owner should be someone who understands what the agent does, which is often the builder rather than their manager.
Agents are typically built under time pressure, and the fastest route to a working prototype is broad permissions. That prototype then ships, and nobody revisits the scope.
Three principles:
The connection worth making explicit: this is Least privilege access applied to a population that never appears in access reviews. Same principle, harder to enforce, because there's no manager to ask.
Time-bounding is the cheapest way to prevent orphaned agents, and it works because it inverts the default.
Without expiry, an agent runs until someone actively decides to retire it - and nobody ever does, because nobody is looking. With expiry, it stops unless someone actively renews it, which forces a decision from a person who has to justify it.
Practical implementation: set a review date at creation, notify the owner ahead of expiry, require an affirmative renewal, and disable rather than delete on lapse so a mistake is recoverable. Six or twelve months is a reasonable default depending on what the agent can reach.
This single mechanism removes most of the orphaned-agent problem without anyone running a hunt for them.
Agent monitoring differs from human user monitoring in one important way: volume. An agent can execute thousands of actions a day, so alerting on activity is useless. You need to alert on deviation.
Four signals worth alerting on:
Log actions, and log the agent's reasoning wherever the platform supports it. Actions tell you what happened; reasoning is what an investigation actually needs. Many platforms don't expose reasoning yet - worth asking about during procurement.
This is the step most programmes skip, and it's where governance either becomes real or stays theoretical.
Agents hold entitlements. Entitlements should be justified periodically. The obstacle is mechanical rather than philosophical: reviews route to managers, and agents don't have managers - which is exactly why step 2 comes first.
What makes agent reviews work:
User access reviews covers the mechanics across the wider estate. The principles carry over; only the routing changes.
A question worth answering early, because getting it wrong creates duplicated effort: agents belong inside identity governance, not in a separate AI initiative.
The reasoning is practical. Agents hold entitlements like any other identity. If they're governed separately, you end up with two inventories, two review processes and two sets of evidence - and the interaction between human and agent access, which is where compound risk lives, is visible in neither.
If you already govern non-human identities - service accounts, API keys, machine credentials - agents extend that population rather than forming a new one. Managing identities for human and non-human users covers that wider picture.
What agents add that service accounts don't: unpredictability. A service account does the same thing every day. An agent decides what to do at runtime, which raises the cost of getting entitlements wrong and makes monitoring more valuable relative to static review.
One guardrail: don't disable an agent without tracing what depends on it. Breaking a production workflow is the fastest way to lose support for a governance programme that's only a month old.
Josys discovers AI agents, and non-human identities across your SaaS estate - including agents provisioned inside applications that never touched a procurement process - maps what each can reach, and holds them in the same governance model as human identities. Agents appear in access reviews, carry accountable owners, and are subject to the same entitlement scrutiny as anyone else.
See AI agent discovery, the identity security and risk page, or book a demo to see Josys in action.
AI agent governance is the operational practice of determining which AI agents may run in your environment, what each is permitted to access, who is accountable for it, and how its behaviour is monitored and reviewed. It covers inventory, ownership, entitlement scoping, expiry and access review - the programme that keeps agent risk manageable at scale.
Start with OAuth grants and API tokens in your major SaaS platforms and identity provider, since agents authenticate and leave traces. Then check automation and integration platforms where agentic workflows commonly live, review AI features enabled inside SaaS applications, and survey teams directly. For each agent, record purpose, builder, current owner, credentials held, systems reachable, and whether it's still needed.
AI agent identity management treats each agent as a distinct identity with its own credentials, an accountable owner, a defined entitlement set and a lifecycle that ends. It replaces the common pattern of agents running on shared service accounts or a builder's personal credentials, which makes actions unattributable and permissions impossible to revoke individually.
Alert on deviation rather than activity, since agents generate far too much activity to review. The four highest-value signals are access outside the agent's normal scope, volume anomalies, changes to the agent's own permissions or credentials, and failure-rate spikes. Log actions, and log reasoning wherever the platform exposes it.
Yes, and this is one of the clearest gaps in most programmes. Agents hold entitlements that need periodic justification like any other identity. The practical obstacle is that reviews route to managers and agents don't have one - which is why assigning an accountable owner is the prerequisite control.
No. Agents should sit inside your existing non-human identity governance alongside service accounts, API keys and machine credentials. Separate programmes create two inventories and two review processes, and neither shows the interaction between human and agent access. What agents add is unpredictability - they decide actions at runtime - which raises the value of monitoring relative to periodic review.
Time-bound them. Set a review date at creation, notify the owner before expiry, require affirmative renewal, and disable rather than delete on lapse. This inverts the default: instead of running until someone decides to retire it, an agent stops unless someone justifies keeping it. It removes most of the orphaned-agent problem without a separate cleanup exercise.
