5 AI Agent Governance Best Practices For Security and IAM teams

The request to connect an approved AI agent to your finance team's data warehouse has sat in the access queue for three weeks. On day three, an analyst on the same team connected an AI assistant to the warehouse with her own sign-in, and it has pulled numbers every morning since, with every permission she holds. When the approved agent finally ships, scoped and owned, nobody moves over to it.

AI agent governance best practices are the routines that decide which agents may act in your company, on whose authority, and how quickly you'll know when one strays from what you approved. The people who launch agents and the agents themselves both take the path of least resistance. The practices that hold make the governed path the fastest one for people and the only one left open to agents.

You probably run the basics of AI agent identity governance already, with an inventory, an owner for every agent, least privilege, policy enforced outside the model, and reviews. Programs with all five still get routed around, even when they follow the AI agent security best practices for stopping attackers. The practices below explain why, starting with the speed of the governed path, moving to the side doors agents find on their own, and ending on the number that proves the program works.

1. Stop shadow AI agents by making the approved path the fastest one

If the approved way to connect an agent takes longer than a consent screen, people will click the consent screen, so the governed path has to be the fastest one. While a request waits in a queue, the agent usually runs anyway, on someone's personal sign-in or laptop, with everything that person holds and no record anyone can review. Every week the governed path runs slower than the workaround, your ungoverned inventory grows, which makes speed the first control in governance for AI agents.

The UK's National Cyber Security Centre made this point about shadow IT before agents arrived. Its shadow IT guidance, first published in 2023 and last reviewed in August 2026, calls shadow IT "rarely the result of malicious intent" and traces it to people trying to finish their work when approved routes fall short. Slow or unclear request processes are on its list of triggers, and so is approved software that lacks features such as AI assistance. The NCSC's answer is a simple, fast way to request services, and it warns that blanket lockdowns push people toward workarounds.

Our own IT team runs access on that principle. It takes requests through a self-service AppStore in Slack and on the web, routes each one to the app's owner or business approver, and redirects about 50 IT tickets a week. Our Director of IT's takeaway is that access shouldn't be a blocker, and accountability belongs inside the workflow people already use.

Three moves make the governed path the fast one for agents. Approve agent patterns once, and a request that fits a common agent type with pre-approved scopes, an owner, and an expiry gets an answer in minutes. Take requests where people already work, whether that's chat, the ITSM queue, or the agent's own access request.

Then make every governed grant expire by default, the rule at the center of AI agent access management, so a fast approval never turns into standing access. Publish one number to go with it: time to yes, measured from request to working access, with a target the business can see.

Roku shows what a faster front door does. Before Lumos, people went around its access process with direct Slack messages to IT. Once requests moved into Slack through Lumos, reliance on those backdoor workarounds dropped.

Pick the three agent requests your teams make most often and pre-approve each as a pattern with its scopes, owner, and expiry. Then publish your time-to-yes target and measure against it every month.

2. Run AI agent pilots under production access rules from day one

A pilot is where an agent first holds real credentials, and it needs the rules production will have from its first day. Most programs treat the pilot as the stage before governance starts, the moment access gets the least attention.

Anthropic's own testing shows what happens when a test environment gets real-world reach. In a July 30, 2026 report, it describes reviewing 141,006 evaluation runs in which its models could have reached the internet. It found three cases in which models, working in an evaluation environment a third party ran, reached real organizations' servers and gained unauthorized access. A misconfiguration traced to a misunderstanding between Anthropic and that vendor gave tests meant to be offline live internet access, and the prompts said there was no internet without saying which targets were in or out of scope.

Anthropic calls the root cause closer to a harness and operational failure than a model alignment failure. Its fixes read like a pilot checklist: hold test environments to production's security standard, spell out what's in scope, check every access path before a run, and extend that assurance work to the vendors involved.

Enterprise pilots repeat those mistakes. Someone issues a production key "for the demo," the scope lives in a kickoff deck, a vendor runs half the setup, nobody is assigned to read the logs, and the pilot becomes production because nobody turned it off. Governing AI agents starts here, because the pilot is where those habits get set.

The pilot is also the easiest place to get expiry and record-keeping right in your identity governance software, because nothing depends on the agent yet. The Access Request Agent in Lumos's Identity Agent Force grants access for a set time and revokes it automatically, so access granted for the pilot ends with the pilot. In the coding agents it supports, MCP Governance records every tool call from the first day with the person behind it, including servers employees add on their own laptops, and that record exists before anyone decides whether to keep the agent.

Before your next pilot starts, register it with an owner, an end date, and a written list of the apps, data, and destinations it may reach. Enforce that list with AI agent access control at the credential and network layer, since a prompt that says "stay in scope" is the control that failed in the lab. Default to read-only access and masked or synthetic data, and review the pilot's logs every week it runs. If nobody can name the owner, the list, and the end date, the pilot isn't ready.

When the pilot ends, decide in writing. An agent that graduates goes through your production gate with fresh credentials and a probation period, and it joins your next AI agent access right audit. One that doesn't is retired through the AI agent lifecycle management steps you use for every other agent.

3. Assign every control on vendor and SaaS AI agents before they act

Every control around a vendor's agent belongs to you or to the vendor, and the ones nobody claimed are the ones that fail first. A vendor's agent works on your data under settings split between your admin console and the vendor's, and each side tends to assume the other is watching. Of all the AI agent governance best practices, this is the one that depends most on someone outside your company.

Vendor documentation won't settle the question for you. The 2025 AI Agent Index, a Cambridge-led study of 30 deployed agents as of the end of 2025, found that 23 publish no third-party testing information and 4 document no way to stop them. For many enterprise agents, the researchers couldn't tell whether a record of each run exists at all, and some enterprise platforms only let you stop every agent or pull the whole deployment. Settle ownership when your enterprise AI agent governance program approves agents that ship inside SaaS apps, and use this table as the question set.

‍

We build agents that act inside our customers' tools, and here's how ours answer a few of these rows. The Lumos Access Request Agent now takes access tickets assigned to it in Jira Service Management, fetches only what it's assigned, sends each request through the approval path a direct request would take, and reports its status back into the ticket. When we add provisioning through AWS Account Access Manager, we plan to act with credentials scoped to the approver's own permissions, with no standing integration role behind them.

Fill the table for every vendor agent with write access in your environment, and send the blank rows to each vendor before its next renewal. The record row matters most at audit time, because the evidence has to land somewhere your auditors already trust.

Checkr shows what a good answer to that row looks like. Lumos's AI-driven ticket interceptor funneled access requests that came in through Jira into Slack, and Lumos logs every request in Jira, which Checkr treats as its source of truth for compliance.

Treat any row nobody will claim as a finding. Give it an owner on your side until the vendor commits in writing.

4. Stop AI agent sprawl at the keys and accounts agents create

Agents create identities as well as use them, and every identity an agent creates needs an owner and an end date the moment it exists. Governance programs inventory the identities agents run on, and few watch the ones agents make while they work. A coding agent wiring up a script mints an API key, an automation creates a service account or an OAuth app, and an orchestrator can hand its sub-agents credentials, the part of AI agent orchestration security that lands on the identity team. Some agents go further and sign up for outside services.

The evaluation incidents from the pilot section included exactly that. One model registered its own account on a public package registry, using a free email address it signed up for along the way, to finish its task. Every place where non-human identity sprawl starts can now be reached by an agent acting mid-task, and each new identity needs tracing back to the session that made it before it joins your list of AI agent security vulnerabilities. The defaults below are a starting point to tune for your environment.

‍

Some of those identities end up in a role a person also holds, and a shared role can't be reviewed for either one. Lumos now reads AWS IAM Account Access Manager assignments into one graph with human access, and our agent flags drift between reviews, including duplicate assignments and ownership tags that point to people who have left. It also maps the roles a CI pipeline and an engineer both use, since revoking a shared role to clean up the person's access breaks the pipeline, and the pipeline's activity hides whether the person still uses it.

Turn on alerts for identity creation events in your cloud accounts and identity provider. Route every one an agent session created to the person behind that session for an owner and an end date.

Identities created through one governed flow come with an end date. In its first two months on Lumos, Marqeta automated onboarding and offboarding across more than 150 apps, moving off in-house governance its engineers had built, which worked at its size but wasn't as scalable or audit-ready as it needed.

Agent-created identities need that kind of flow, with the agent session as the trigger. Your user access review software should then confirm at each review that the end date held.

5. Judge AI agent monitoring by how fast you notice a stray agent

The number that proves your governance works is how long an agent can act outside what you approved before a person knows. The evaluation incidents from the pilot section show how long that can run.

The earliest dated to April. The review that found them started in late July, after another lab disclosed an incident of its own, and neither of the two affected organizations contacted had noticed anything. A frontier lab reviewing its own evaluations took months to find out, and someone else's incident is what sent it looking.

Identity teams report a similar gap. In Lumos's 2026 survey of 133 security and technology leaders at large North American companies, nearly 48% said they struggle to detect identity misuse in real time.

Four off-path events deserve a clock: an agent reaching something outside its approved list, creating an identity, widening a scope, or acting after its owner leaves. The behavior signals that flag a stray agent catch the first and the last of those. Define time to notice as the hours from the event to a person acknowledging it, and track it for each event type.

Running our own access reviews taught our IT team that governance has to run continuously in the background, all year. For agents, the clock needs a starting timestamp, and in the coding agents it supports, MCP Governance records each tool call with the person behind it and the policy decision. That record is the starting point for AI agent oversight.

Set a target for each event type by what the agent could reach. An agent still acting after its owner leaves should reach a person within the hour, while a new read-only scope can wait for the next daily review. Report the targets with the rest of your non-human identity governance metrics, and agent drift shows up in one report with everything else.

Then test it. Once a quarter, have a test agent trigger a harmless off-path event and time the response, and within a week of any public agent incident at another company, search your own records for that pattern. Report both results next to your time-to-yes number, and you'll see whether the governed path is fast and whether anyone is watching the side doors.

Build governance for AI agents around the path of least resistance

People and agents will both take the easiest path available. Make the governed path the fast one for people, close the others for agents, and know how quickly you'd notice an agent that found one anyway.

Publish a time-to-yes target and pre-approve your most common agent patterns this month. Write the reach list and end date before your next pilot, then fill the vendor table, watch creation events, and run the first drill this quarter. Governance that people route around isn't governance, it's paperwork.

Lumos gives your people a path that's faster than the workaround, with self-service access in Slack, Teams, and your ITSM queue, routine requests approved by policy, and grants that remove themselves when time's up. With agentic AI security for the agents it governs, Lumos keeps access to what an identity layer issued, recorded, and can take back, with an owner for every agent and an allow-or-deny decision on every tool call in the coding agents MCP Governance supports. Book a demo to see how fast your governed path can get.

‍