Your first agent needed access before it could do anything useful. Somebody generated a token, dropped it into a config file and moved on, because the demo was on Thursday. It worked. Six months later it's still working, and nobody has looked at it since.
We've written before about why AI pilots are easy and production is where it pays, and one line in that piece does a lot of quiet work: an agent with no owner is a liability, not an asset. This is the layer underneath it. Not the policy question of who's accountable, but the plumbing question of what that agent can actually reach at 3am when nobody's watching.
An agent is an account, not a feature
You already have a process for people. Someone joins, they get an identity, a role and the access that role needs. They change teams and the access changes with them. They leave and it's revoked on their last day.
Agents skipped that queue entirely. They arrived as features inside projects, so they got credentials the way a script gets credentials: whatever was lying around, scoped to whatever was convenient. An agent that can read your orders table, write to your CRM and call your payment provider isn't a feature, it's a user that never sleeps. And those are only the ones you run: others are already arriving from outside, shopping your catalogue on someone else's behalf.
Autonomy is the whole point. You gave the agent a goal instead of a script, and it picks the steps: query the warehouse, draft the reorder, open the ticket. That flexibility is exactly why it's useful and exactly why you can't predict what it'll touch.
Access is what you handed over to get it. Most agents run on a credential built for a person doing everything, because scoping one properly meant a conversation with three teams. So the agent inherited the widest key in the building.
None of this needs a new discipline. Identity and access management has handled exactly this problem for decades, for humans and service accounts alike. Agents just need to be let into it.
Start with what most teams skipped. Give every agent its own identity rather than a shared one, so a log line tells you which agent did what instead of which human's key was used. Scope that identity to the smallest set of actions the job needs, then widen it deliberately when the job grows. Put the credential in a secrets manager and rotate it on a schedule, because a token pasted into a repo six months ago is a token you no longer control. Log the actions and not just the errors, so there's an audit trail on the ordinary Tuesday and not only the bad one. And write down who owns the thing, because that's the person who has to answer when it books a supplier order at four in the morning. Every one of these is a well understood cybersecurity practice. None of them is new. They were just never applied to something that writes to your database on its own initiative.
Then there's the question nobody has a process for: offboarding. When a project ends the people roll off and their access goes with them, but the agent keeps running because nothing tells anyone it should stop. Your data governance register is the right place to give it an end date.
Your agent will outlive the project that created it
Credentials live where the integrations do
Agent access isn't really an AI problem, it's an integration problem wearing a new hat. At eComia we build the APIs and integrations these agents run through, which is exactly where scoping, rotation and audit logging either exist or don't.
You don't need to slow the agents down. You need them to show up in the same place your people do: with a name, a role, an owner and a date when their access expires.
Do it early and the autonomy stays worth having. Leave it, and the first time someone asks what your agents can reach, you'll be counting keys instead of answering.