Agentic security doesn't need a whole new definition – you just need to reframe what you already know — TechRadar

RESOLVING THE LEDGER

Though attack vectors and threat environments have changed since the advent of the internet, one thing has remained a constant – humans use software, and software has predefined parameters.

That distinction is exactly why social engineering remains so effective. Cybercriminals exploit predictable weaknesses in human behavior, granting them accesss to accounts and other sensitive information.

For the first time ever, that long-standing assumption is being turned on its head. In today's increasingly autonomous world, AI agents can take action on behalf of humans, creating an entirely new class of attack vectors that target machine autonomy rather than human weaknesses.

The boundary between software and user is getting really, really blurry

The purpose of an agent isn't just to retrieve information or wait for a human's approval – its responsibilities can include interpreting objectives, developing plans, choosing tools, accessing data autonomously and taking actions. In short, agentic AI bridges both software and user.

This doesn't make everything we know about software and SaaS security obsolete, but it does mean that many of the assumptions underpinning today's controls are no longer sufficient. Humans will continue to use conventional software, but alongside agentic workflows, leaving organizations responsible for security both types of environment.

Thankfully, the fundamentals remain – least privilege, strong authentication and separation of duties will all be central to the next wave of cybersecurity. What will change, though, is how those principles will be applied to agents, which don't behave as software or human users.

AI agents need identities of their own

The first requirement is to stop treating agents like features hidden inside applications, or software in their own right. An enterprise agent should actually have a first-class identity just like any other human colleague.

This means AI agents should have unique identities, named owners (line managers), clearly defined purposes and specific permissions. But they should also have their own lifecycles akin to software, such as creation dates, review points and expiry dates.

"Expiry dates or periodic recertification are important because agents can otherwise become long-lived access paths that are harder to govern than human users," Zendesk Chief Security Officer Vinay Patel explained to me in an exclusive interview.

At the end of the day, these are the sorts of controls that already exist for human users because organizations already understand the risks of unmanaged access, due to role changes or company departures, for example.

Without treating AI agents as users in their own right, companies risk accumulating abandoned agents, stored credentials and even data access paths whose original business purposes may have disappeared – an unthinkable consequence for humans, so one that should be treated just as severely for AI agents.

Human-in-the-loop automation is the future

Importantly, AI agents don't just occupy one space. They can act autonomously, be commissioned on a task-by-task basis by a human user, or operate somewhere between the two. Patel told me that an "audit trail should preserve both identities: the human who initiated or authorized the action and the agent that executed it."

For fully autonomous agents, a log tying them back to their "owner, purpose, and approved policy" is still just as important.

But of course, it all boils down to flawless visibility and effective management. "Companies need inventory and discovery across the places agents can be created or embedded, including SaaS platforms, internal automation tools, development environments, and third-party integrations," Patel added.

Organizations must monitor not only which agents are deployed, but whether their permissions and behavior remain aligned with their original business purposes.

Recent NIST research raises many of the same priorities, including verifiable records of agent actions, intent, data sources and generated output. But while NIST is developing guidance around agent adoption, visibility, control and accountability, agents are already being deployed, and often without the necessary safeguards.

Traditional IAM falls short

A separate Cloud Security Alliance paper concluded, "traditional identity and access management (IAM) protocols, designed for static applications and human users, can’t keep up."

The researchers argue that credentials and permissions should be task-specific, short-lived and easily revokable, unlike human identities which are generally set for the duration of their employment contracts.

The CSA also recommends applying zero-trust principles by treating agent compromise as a credible possibility. By enforcing least privilege, isolating systems and continuously verifying access, organizations can limit the potential consequences of an attack or misconfiguration as they adapt to this new security environment.

Accountability starts before deployment

Patel says that, "accountability should not collapse onto a single party by default." It's as much the responsibility of adopters as it is lawmakers, and even end users.

Key to understanding vulnerabilities and potential risks is identifying where the failure occurred: "user’s instruction, the agent owner’s governance, the developer’s design, the platform provider’s controls, or the enterprise’s deployment model."

Above all else, Zendesk's Chief Security Officer argues that "accountability must be defined before deployment, not reconstructed after an incident."

In the short term, this work could slow AI adoption as companies address controls that might've been overlooked during early, informal experimentation. The danger arises when a successful pilot actual progresses into production without pausing to define ownership, permissions and other policies.

Before scaling agent deployments, organizations should pause other ensure the right foundations are in...

Agentic security doesn't need a whole new definition – you just need to reframe what you already know — TechRadar | AIPROPX