When a company hires a person, there's a process. They get an identity, they get the access their role needs and not more, someone approves it, it gets reviewed periodically, and when they leave it gets revoked. Decades of painful lessons went into that process.
Then a team deploys an AI agent with a shared API key that has admin rights to three systems, because that's what made the demo work.
An agent is an identity
The first fix is conceptual. An agent that reads your CRM and sends emails is not a feature; it's an actor in your systems, and it needs its own identity. Not the developer's credentials, not a shared service account that five other things use. Its own. That's what makes everything else possible.
Least privilege, for real
Once the agent has an identity, ask what it actually needs. An agent that triages support tickets needs to read tickets and write a classification. It does not need to delete tickets, read billing, or access the customer database. Scope the access to the job, and if the job grows, grow the access deliberately.
Just-in-time beats standing access
Many agent actions are occasional. Rather than granting permanent access to a sensitive system, grant it for the duration of the task, with an approval where the risk warrants one. This is the same pattern that's replaced standing admin rights for humans, and it applies directly.
Audit like you mean it
Every action the agent takes should be attributable: what it did, with what data, on whose behalf, triggered by what. When something goes wrong, and something will, this is the difference between a ten-minute investigation and a week of guessing.
Plan for revocation
Agents get decommissioned, replaced, or compromised. If revoking an agent's access means finding every place its key was pasted, you've already lost. Central identity, central revocation.
Nothing here is new. It's the same discipline the industry built for people, applied to a new kind of user that works faster and never gets tired.