Your AI Agent Doesn't Need to Be Hacked to Become a Security Incident

For the last few years, much of the AI security conversation has focused on prompt injection, data leakage, model vulnerabilities, and AI supply-chain risk. All these matters.

But Agentic AI changes the security equation.

An AI agent does not just generate an answer. It can retrieve information, access enterprise data, invoke tools, call APIs, and potentially take actions on behalf of a user. And that creates a quite different security problem.

The agent does not necessarily need to be hacked.

It may simply have too much authority.

Consider the chain:

User → Agent → Model → Context/Memory → Tools → APIs → Enterprise Systems

Every connection introduces another trust boundary. An agent with access to customer data, internal APIs, email, cloud resources, or identity systems can create significant business impact if its authority is poorly designed—even when the underlying model is functioning exactly as intended.

NIST's recent work on AI-agent identity and authorization precisely highlights this challenge: giving agents access to diverse data, tools and applications requires appropriate identification, authorization, auditing, and accountability.

Least privilege is no longer enough.

Traditional IAM asks:

What can this identity access?

For AI agents, we need to ask:

What can this agent access, decide, execute and change—and under what circumstances?

This introduces three related concepts:

Least privilege — What resources can the agent access?

Least agency — What actions can it perform?

Controlled autonomy — Which actions require additional validation or human approval?

OWASP's current AI Agent Security guidance recommends scoped tool permissions, explicit authorization for sensitive operations, human approval for high-impact actions, and strong monitoring of agent decisions and tool calls.

The RAG connection matters too.

RAG makes enterprise AI more useful by allowing models to work with external and organizational information. But when that information can influence an agent that can act, untrusted content can become part of the attack path.

A malicious instruction embedded in a document, email or web page does not necessarily need to compromise the model. It may simply influence the agent's context and cause an inappropriate tool invocation.

That is why retrieval authorization alone is not enough. The resulting action needs its own authorization and policy validation. 

The SOC must evolve.

Traditional monitoring asks:

Who did what, when and where? Agentic security increasingly requires:

Which agent acted? What influenced its decision? Which tools did it invoke? What authority did it exercise? Who authorized the action?

Agent decisions, tool calls, and outcomes therefore need to become part of security telemetry and incident investigation.

The question CISOs should be asking.

Most organizations know how many applications and human identities they have.

But increasingly, we need to know:

How many AI agents are operating in our environment—and what can each one do?

And if an agent starts behaving abnormally:

Can we revoke its authority? Can we stop its tool calls? Can we contain it before the impact becomes irreversible? The biggest AI security risk may not always be an attacker breaking into the agent. It may be an attacker influencing the agent—or the agent simply exercising authority, that we gave it in the first place.

The real shift

We should not secure AI agents only as AI systems. We need to secure them as identities, decision-makers, and digital actors. Because once AI can decide and act, cybersecurity is no longer protecting only the model. We are protecting the authority we gave the model to act.

And that, in my view, will be one of the defining security challenges of the agentic AI era.