The next identity challenge doesn’t have a human behind it.

Before we give an AI agent access, I want to know what it needs to do and who is responsible for letting it do it.

An agent that summarizes a document and an agent that changes a client record are exercising very different levels of authority. A conversational interface can make those activities feel similar. Our access controls need to preserve the distinction.

Give the task a defined scope

The right starting point is the intended business activity: what the agent needs to accomplish, which resources it needs, and which actions it can take. Permissions should follow that purpose. They should not simply inherit everything available to the person who configured the agent.

For a hypothetical client service assistant, reading the records relevant to a case may be appropriate. Exporting every client record or changing payment instructions would be a separate decision, with separate controls.

NIST’s zero trust architecture focuses protection on resources and rejects network location as a sufficient basis for trust. Applied to agents, I see a practical design principle: evaluate the specific access and action, even when the agent runs inside an approved environment.

Make delegation visible

Every agent should have an accountable owner. Its activity should be attributable to the agent, the initiating person or event, and the authority used. Shared credentials and a generic “service account” log entry can leave important parts of that chain unexplained.

We should also distinguish actions an agent can take independently from actions that need human approval. Use that approval where the consequence warrants it, and make sure the approver can see what is about to happen. Requiring someone to click through every low-impact action can turn oversight into a reflex.

Good identity design gives useful automation a clear boundary.

Build the stop mechanism before expanding access

Access must be revocable, and suspension needs to be tested. We should know what happens to running jobs, active sessions, and downstream credentials when an agent is disabled. A control that only prevents the next sign-in may not stop work already underway.

Start with narrow authority, observable actions, and proportionate review. Expand access when the workflow demonstrates value and the controls hold up. That gives teams a practical route to adoption while keeping accountability intact.

For me, the direction is clear: bring agents into the identity discipline, rather than manage their permissions as an exception beside it.