We Spent 30 Years Securing Users. Now We Have to Secure AI Agents

We Spent 30 Years Securing Users. Now We Have to Secure AI Agents.

About a year ago, someone asked me to put together a proof of concept demonstrating what an AI agent could actually do.

Not another chatbot. Not something that simply answered questions or generated text. They wanted to see an agent perform a practical task… something that could act independently and accomplish a goal.

I started thinking about examples. And strangely enough, inspiration came while I was clipping supermarket coupons.

I regularly use digital coupons from ShopRite and BJ’s Wholesale Club, and like a lot of people, I would periodically log into the apps or websites, scroll through the available offers, and clip the ones I might use.

It wasn’t difficult, but it was tedious. And while doing it, I had a thought:

Why am I doing this and why can’t an AI agent do it for me?

That became my proof of concept.

I built an agent that could log into my accounts, navigate through the available coupons, clip them for me, and then send me an email when it was finished telling me how many coupons it had clipped.

Simple. Useful. And, frankly, kind of fun.

It also made for a great demonstration because people immediately understood it. There wasn’t some complicated enterprise architecture diagram required to explain the value.

I had a repetitive task. I gave an agent a goal. The agent performed the task. It reported back when it was finished.

That was it.

Or at least, that’s how I looked at it at the time.

A Year Later, I See That Experiment Very Differently

Looking back at that little proof of concept through the eyes of someone responsible for IT and cybersecurity, I realize something much more interesting was happening.

I didn’t simply build software that clipped coupons.

I created a digital identity capable of acting as me.

Think about what I had actually allowed that agent to do.

• It could authenticate to a system.
• It could navigate an application.
• It could interpret what was presented to it.
• It could make decisions.
• It could take actions.
• And it could do those things without me sitting there clicking the mouse.

The action happened to be clipping coupons.

But you could easliy replace “clip coupons” with –>

• Create a user account.
• Respond to an email.
• Query a database.
• Modify a firewall rule.
• Provision a cloud resource.
• Approve an invoice.
• Reset a password.
• Investigate a security alert.
• Deploy code.

Suddenly the same concept doesn’t feel quite so harmless.

And that is where I believe one of the next major cybersecurity challenges is beginning to emerge.

We Designed Security Around Humans

For decades, enterprise security has largely revolved around determining who, or what, is requesting access.

• We built usernames and passwords.
• Then stronger passwords.
• Then password managers.
• Then multifactor authentication.
• Then privileged access management.
• Then conditional access.
• Then zero-trust architectures.

We developed sophisticated identity and access management platforms designed to answer some variation of the same questions:

• Who are you?
• Should you be here?
• What are you allowed to do?
• And can you prove that you are really who you claim to be?

Those controls aren’t going away. But AI agents introduce another question…

What happens when the authenticated user isn’t actually the one performing the actions?

Consider my coupon agent.

When that agent authenticated to my supermarket account and began interacting with it, what did the retailer see?

From the application’s perspective, it was probably me.

• My account.
• My credentials.
• My permissions.
• My session.

But I wasn’t sitting at the computer. Something else was acting with my authority.

That distinction is about to become incredibly important.

The Rise of the Digital Employee

We’re quickly moving beyond AI systems that simply answer questions.

AI agents are increasingly being designed to do things.

• They can use browsers.
• They can call APIs.
• They can execute commands.
• They can interact with applications.
• They can read and write files.
• They can send messages.
• They can query databases.
• They can interact with other agents.

And increasingly, they can make decisions about which of those tools to use in order to accomplish a goal.

That is fundamentally different from traditional automation.

A script generally executes instructions we explicitly wrote.

An agent can increasingly determine the steps necessary to achieve the objective we gave it.

That flexibility is what makes agentic AI so powerful.

It is also what makes securing it so complicated.

Least Privilege Gets Much Harder When Software Can Reason

One of cybersecurity’s oldest principles is least privilege…

Give a user only the access required to perform the job.

It sounds simple, right?

But consider an AI agent assigned something seemingly straightforward…

Investigate why a customer cannot access our service and resolve the problem if possible.

What permissions does that agent need?

Maybe it needs access to the ticketing system.

Perhaps it needs to query Active Directory.

Maybe it needs network monitoring.

DNS.

Firewall logs.

Cloud infrastructure.

Customer records.

Endpoint management.

An identity platform.

Perhaps it needs the ability to reset an account or modify a configuration.

Very quickly, a helpful agent can accumulate an enormous amount of privilege.

And unlike a traditional application, we may intentionally want the agent to reason about which systems it needs to use.

We’ve spent decades telling security teams, “Never give users more access than they need”.

Now we’re creating machines whose usefulness may depend partly upon their ability to determine what access they need along the way.

That’s a dangerous collision of ideas.

What Does MFA Mean for an AI Agent?

Here’s another interesting problem I consider.

We spent years pushing multifactor authentication because stolen credentials weren’t enough protection. But how should an autonomous agent perform MFA?

Do we approve every action?

If so, how autonomous is the agent?

Do we approve the agent once and allow it to operate afterward?

For how long?

Does the agent receive its own identity?

Does it inherit mine?

Does it receive delegated permissions?

Should an AI agent ever possess reusable credentials?

Where are those credentials stored?

Who rotates them?

Who reviews them?

And what happens when the employee who created the agent leaves the company?

Those sound like technical implementation details, but they’re not.

They are identity-governance questions.

Next…. what happens when the agent does exactly what we told it to do… but not what we intended?

That’s one of the most fascinating aspects of autonomous systems.

Traditional security focuses heavily on malicious activity.

• Someone steals a credential.
• Someone exploits a vulnerability.
• Someone executes malware.
• Someone abuses a privilege.

But an AI agent doesn’t necessarily need to be malicious to cause damage. It could simply pursue its objective in a way we didn’t anticipate.

Imagine telling an agent… “Make sure this critical application stays available”.

Would it restart a service?

Provision another server?

Modify a firewall rule?

Disable a security control that appears to be interfering with connectivity?

What if an agent encounters malicious instructions embedded in data, a website, an email, a document, or another system it is analyzing?

What if an attacker doesn’t attack the server at all?

What if the attacker convinces the agent to do something for them?

Suddenly cybersecurity isn’t only about preventing unauthorized access.

It’s also about controlling authorized autonomy.

Our Logs May Say “Jim Did It”

This may become one of the more difficult operational problems.

Suppose an AI agent operating under my identity modifies something in an enterprise system.

The audit log says… User: James Leone Action: Configuration Modified Authentication: Successful

Technically, all three may be true, but they’re incomplete.

I didn’t make the change, my agent did.

Tomorrow’s audit logs may need to answer much more than who authenticated.

They may need to tell us…

• Which human authorized the agent?
• Which agent performed the action?
• Which model was running?
• What objective was it given?
• Which tools did it invoke?
• What information influenced its decision?
• What actions did it take along the way?
• And could we reconstruct the entire chain afterward?

That isn’t simply logging, it’s accountability.

Why I Believe AI Agents Need Identities of Their Own

I think this is where enterprise architecture eventually has to go.

AI agents cannot simply become invisible extensions of human accounts.

If an agent can take meaningful action, organizations need to know that the actor was an agent.

That means agents may need many of the same governance controls we’ve spent decades building for employees and service accounts:

• Unique identities.
• Defined owners.
• Explicit permissions.
• Least privilege.
• Credential management.
• Lifecycle management.
• Access reviews.
• Behavior monitoring.
• Audit trails.
• Expiration.
• Revocation.

And perhaps most importantly… An emergency stop button!

If an employee’s account is compromised, we know how to disable it.

We now need the same confidence with autonomous agents. Maybe even more.

Zero Trust Needs a New Question

Zero Trust popularized an important principle…

Never trust, always verify.

But agentic AI may require us to extend that thinking.

Authentication alone isn’t enough.

Authorization alone may not be enough.

Even a properly authenticated and authorized agent might take an action that isn’t appropriate for the situation.

So perhaps the next version of Zero Trust asks… “Should this identity be performing this action, in this context, right now?”

That means behavior becomes increasingly important.

Not simply, “Can the agent modify firewall policies?” But, “Should this particular agent be modifying this particular firewall policy at 2:13 AM as part of this particular task?”

The Attacker Doesn’t Necessarily Need Your Password Anymore

There is another implication worth considering.

If organizations increasingly delegate authority to AI agents, attackers will adapt.

Why spend enormous effort compromising a heavily protected administrator if you can manipulate an authorized agent into performing the action instead?

The target changes.

The attacker may not need to steal the administrator’s credentials.

They may need to influence the administrator’s agent.

And that means prompt injection, poisoned data, compromised tools, manipulated context, excessive permissions, agent-to-agent trust and AI supply chains move from interesting research problems into operational security concerns.

The attack surface doesn’t disappear, it expands.

Which Brings Me Back to Those Coupons

When I built my coupon agent, none of this felt particularly dramatic.

I wanted a useful demonstration of AI agents.

I had an annoying repetitive task.

So I automated it.

The agent logged in.

It clipped my coupons.

It emailed me the results.

Everyone could immediately understand what it did.

And that simplicity is precisely why I keep coming back to the example.

Because underneath that harmless little experiment was the architecture of something much bigger.

• Identity.
• Authentication.
• Delegated authority.
• Autonomous decision-making.
• Machine-to-application interaction.
• Accountability.

The difference between my coupon experiment and the AI agents entering enterprises today isn’t necessarily the underlying concept. It’s the stakes.

We Spent 30 Years Securing Users

Cybersecurity has spent decades learning how to secure people.

We learned, sometimes painfully, how to manage passwords, authentication, privileges, endpoints, sessions, remote access, administrative accounts and identity lifecycles.

Then we learned how difficult machine identities, service accounts, API keys and cloud permissions could become when nobody properly governed them.

We should probably take that lesson seriously.

Because we are about to create an entirely new population of digital identities.

Except this population can reason, use tools, communicate, make decisions, and increasingly, it can take action.

The question isn’t whether enterprises will use AI agents, because they will. The productivity benefits are simply too compelling.

The question is whether we will repeat the mistakes we’ve already made with identity and access management, or apply those lessons before millions of autonomous agents are operating inside our environments.

A year ago, I thought I had built an agent that clipped my coupons. Looking back, I realize I had built something more interesting.

I had given a machine permission to act as me.

And we’re about to do the same thing across the enterprise.

This time, we should think very carefully about who, or what, we’re letting log in.