When a new hire joins a team, nobody hands them the master password and wishes them luck. They get scoped access, a defined set of systems, and a manager who notices if their behavior changes. A local AI agent deserves exactly the same onboarding discipline — and in most of the unmanaged deployments we get called in to fix, it never got any of it.

Agents fail security reviews for the same reason ungoverned employee access does: broad permissions granted once, during setup, under time pressure, and never revisited. The difference is that an agent can act on those permissions continuously, at machine speed, without anyone in the room to notice if something’s off. That’s not a reason to avoid deploying agents. It’s a reason to be more disciplined about how, not less.

Access, Scoped Like an Employee’s

The baseline question for any agent going into production should be the same one you’d ask about a new hire: what does this role actually need to touch to do its job? Not what’s convenient to grant during setup — what’s necessary. That means read access before write access wherever possible, explicit boundaries around which systems are in scope, and a documented owner who can explain the access list without having to go look it up.

Monitoring, Not Just Logging

Almost every platform logs what an agent did. Far fewer clients are actually watching those logs for what changed. Monitoring means someone — or something — is comparing current behavior against expected behavior and flagging drift before it becomes an incident, not reconstructing what happened after a client notices something went wrong.

A local agent touches your systems the same way an employee would. It should be onboarded, scoped, and reviewed the same way, too.

The Checklist We Run Before Any Agent Goes Live

This is the version we walk through with every client before a deployment goes into production. It’s deliberately short enough to actually get used:

  • Is access scoped to only the systems this specific agent needs?
  • Is there a documented owner accountable for this agent’s behavior?
  • Can we distinguish this agent’s actions from a human user’s in every system it touches?
  • Is there an alert path if the agent’s behavior changes outside expected bounds?
  • Is there a fast, tested way to revoke access if something goes wrong?
  • Has write access been separated from read access wherever the workflow allows it?
  • Is the access list reviewed on a schedule, not just at setup?
  • Does anyone outside the deployment team know this agent exists and what it can do?

None of this is exotic. It’s the same discipline every serious security program already applies to human access — extended to cover the newest members of the team, the ones that happen to be software.