For decades, enterprise identity has been built around a familiar moment.

Someone, or something, asks for access.

Who are you?
Can I verify you?
What are you allowed to access?

We’ve gotten remarkably good at answering those questions. MFA, conditional access, privileged access management, least privilege, and Zero Trust have all made the front door significantly harder to get through.

None of that is going away.

And to be clear, modern identity doesn’t literally stop at login. We have session controls, risk-based access, continuous access evaluation, authorization policies, and increasingly sophisticated ways to reevaluate access.

But much of the way we’ve designed and operated identity still centers on a fundamental question:

Should this identity be allowed in?

AI agents introduce a harder one:

Should this identity still be allowed to do this, right now?

An AI agent can authenticate once and then spend the next hour making decisions, accessing data, calling tools, initiating workflows, communicating with other systems, and potentially delegating work to other agents.

The identity may never change.

The behavior can.

We built identity around the moment of access. AI agents force us to think about the lifetime of access.

A valid identity can still do the wrong thing

Most identity security problems start with some version of compromise.

A credential gets stolen. An account gets taken over. Someone gains privileges they shouldn’t have. A malicious actor impersonates a legitimate user.

Now consider a different scenario.

Nobody steals the identity.

The agent is exactly who we think it is. Its credentials are valid. Its access was legitimately granted. Nobody broke through the front door.

And then it does something nobody intended.

NIST recently warned that agents can operate at a speed and scale far beyond humans and, when given broad objectives, may pursue unexpected paths, tools, or data while trying to accomplish their goals. Even agents with strict limits may find ways around intended constraints.

That’s the part of this conversation I think deserves more attention.

The next identity crisis may not be someone stealing an identity. It may be a perfectly valid identity doing something nobody intended.

Think about the difference between a human and an agent.

I log in. I open an application. I request some data. I perform an action. There is usually a reasonably understandable connection between my intent and my actions.

With an agent, I may simply provide the intent.

The agent determines many of the actions.

It can decide what information it needs, which tools to call, which systems to interact with, and what intermediate steps are necessary to accomplish the goal.

Authentication tells us:

I know who, or what, this is.

Authorization tells us:

I know what this identity is permitted to access.

But autonomous systems force us to ask something else:

Is this particular action still consistent with the authority and purpose we gave it?

Authentication may happen once.

The decisions that follow don’t.

From identity to continuous trust

This is where I think our identity model has to evolve.

Identity remains the foundation. But autonomous systems require us to keep making trust decisions after that initial access decision.

NIST is already pointing in this direction. Its recent guidance argues that agents should be treated as first-class entities with their own identities, credentials, entitlements, and delegated authority. It also points toward dynamic, granular authorization instead of broad, long-lived permissions.

Microsoft is making a similar architectural argument: give agents identities, discover unmanaged agents, apply least privilege, monitor behavior, and maintain the ability to pause or revoke an agent when something goes wrong.

I think about that as four continuing responsibilities:

Discover → Verify → Monitor → Control

Discover. Do we actually know what agents are operating inside our environment?

Shadow IT was difficult enough when employees could adopt a SaaS application with a credit card. Imagine shadow AI when someone can create an autonomous actor, connect it to corporate data and tools, and put it to work.

An agent we don’t know exists is an agent we can’t govern.

Verify. What is this agent? Who owns it? What is its purpose? Who delegated authority to it? And what exactly was it authorized to do?

Knowing who the agent is isn’t enough.

We also need to know what authority we gave it.

Monitor. This is where things get harder.

Logging agent activity isn’t enough. We need to understand whether the behavior we’re seeing is still consistent with the purpose and authority we assigned.

An agent performing thousands of legitimate actions creates an enormous amount of activity. Somewhere inside all of that may be the one decision that matters.

A log can tell you what happened. Continuous trust has to help you decide whether it should still be happening.

Control. And finally, can we do something about it?

Can we block a specific action? Reduce authority? Require human approval? Revoke access? Pause the agent?

And can we do it without shutting down the entire application or business process around it?

Detection without control isn’t enough.

The goal isn’t to eliminate autonomy.

The goal is to make autonomy governable.

What I mean by continuous trust

Continuous trust isn’t continuous authentication. It isn’t repeatedly asking an agent to prove who it is, and it doesn’t replace the identity infrastructure we already have.

It extends that foundation into the lifetime of autonomous activity.

Identity → Authorization → Context → Behavior → Action → Re-evaluation

And sometimes the answer needs to be:

Stop.

Continuous trust isn’t continuously asking who you are. It’s continuously asking whether what you’re doing still deserves the authority you’ve been given.

I’m less interested in which vendor ultimately owns each of these controls than I am in the pattern developing across the industry.

NIST is working on agent identity and authorization. Microsoft is building identity, discovery, monitoring, investigation, and revocation into its agent security architecture. Other vendors are attacking different pieces of the same problem.

The pattern is what matters.

Knowing who an agent is and what it can access is necessary.

Knowing whether it should still be doing what it’s doing is becoming just as important.

The Boardroom Questions

This is where the conversation moves beyond IAM architecture.

If autonomous agents are going to operate inside critical business processes, leadership teams should already be asking some uncomfortable questions:

Do we know how many AI agents are operating inside our environment today?

Can every agent be tied to an owner, purpose, identity, and clearly delegated authority?

Can we distinguish between “this agent can access this system” and “this agent should be allowed to perform this action right now”?

Can we recognize when a legitimate agent begins behaving outside its intended purpose?

Can we reduce or revoke its authority immediately?

Ultimately, all five lead back to one question:

Should this identity still be allowed to do this, right now?

Identity is the beginning

We’ve spent decades getting better at deciding who gets through the front door.

We needed to, and we still do.

But AI agents change what happens after the door opens.

The next generation of identity won’t be judged solely by whether we correctly authenticate the human, machine, application, or agent asking for access.

It will also be judged by whether we can continue making trust decisions after access has been granted.

Authentication happens at a moment in time.

Autonomous action continues long after.

Identity gets you in. Trust determines what happens next.

And in an agentic world, that decision may need to be made thousands of times.

FIELD NOTES | CONTINUOUS TRUST

Sources & Further Reading