Why Agent Security Is Different From Application Security

Traditional application security assumes code does what it was written to do. Agents break that assumption at the foundation. This piece covers what changes, drawing on FISTA Solutions' AI agents engineering work.

What is genuinely different?

Five assumptions that no longer hold.

Traditional assumption	With agents
Code and data are separate	Data can be instruction
Behaviour is enumerable	Behaviour is emergent
Permissions map to users	Agent acts for many users
Attack surface is the interface	Any readable content is a surface
Actions follow a coded path	Actions are chosen at runtime
Tools are used as designed	Tools combine unpredictably

Why does the data-instruction boundary matter so much?

Because it means the attack surface is everything the agent can read.

A document in a shared drive, a customer's message, a ticket comment, or a web page can all contain text directed at the model rather than at a person. If the agent reads it and acts on what it reads, that text is an input to its behaviour.

This does not require access to your infrastructure. It requires only the ability to put content somewhere the agent will look, which in most organisations is not a high bar. See the agent supply chain problem.

How should authorisation work?

Enforced outside the model, always.

Instructions in a prompt telling the agent what it may not do are guidance, not controls. A sufficiently persuasive input can override them, and relying on the model to refuse is relying on the component under attack.

The control is a permission check in code: this agent, acting for this user, may invoke this tool with these parameters up to these limits. An agent persuaded to attempt something disallowed is stopped by the check, and the attempt is logged. See agent permission review checklist.

What is the composition problem?

Safe capabilities combining into unsafe paths.

Reading customer records is reasonable for a support agent. Sending email is reasonable. Together, they are a data exfiltration path that neither tool review would have identified.

Review the capability set as a whole, asking what an adversary could achieve with this combination. That question is rarely asked, and it is where the real exposure sits.

What does delegated authority require?

Bounds, expiry, and revocation.

An agent acting for a user has that user's authority, which may be considerable. It should receive a narrow subset rather than the whole, limited to what its task requires and to a time window.

When an agent delegates onward, that subset should narrow further. Authority that propagates undiminished across delegations means one compromise reaches everything. See the coming agent interoperability standard.

What must be audited?

The reasoning as well as the actions.

A log recording that an agent sent an email does not explain why. Investigating an incident requires the input that triggered it, the context retrieved, the reasoning, the tools called, and the arguments used.

That is more logging than most systems keep, and it is what makes the difference between understanding an incident and guessing at it. See agent trace analysis pipeline.

What should be done first?

Reduce what the agent can do.

Every capability removed eliminates a class of risk. An agent that can read but not write cannot cause damage. One that can write to a single system cannot reach others.

Start from the minimum that accomplishes the task and add deliberately, with review at each addition. This is more effective than any amount of behavioural instruction. See AI agent security risks.

What is the counter-argument?

The counter is that this is manageable with existing security practice — least privilege, input validation, and audit are not new. Largely true, and the point is that they must be applied in unfamiliar places: to content the agent reads, to combinations of capability, and to authority that propagates.

What does this change for engineering teams?

It means permission checks in code between the agent and every action, and structured capability definitions rather than prose tool descriptions.

It also means treating retrieved content as untrusted data in the same way user input is treated, which is a habit most codebases have for form fields and not for documents.

What does this change for buyers?

It means asking vendors how authorisation is enforced, what the agent can read, and what capability combinations exist.

A vendor whose answer is about prompt instructions has not implemented a control.

What should leaders do about it now?

Require a written capability list per agent with limits, and require review of the combination rather than of each tool.

Then require that any action with consequence be authorised outside the model, because instructions are not controls.

How does this scale with adoption?

Poorly, without shared controls. Each agent built independently produces its own permission model, its own logging, and its own review burden.

Shared authorisation and audit infrastructure is what makes a growing agent estate assessable. Without it, security review becomes the constraint on adoption. See the compliance layer of AI.

How will you know if this is happening?

Watch for agents with broad read access and any external capability, for permission models expressed in prompts, and for logs that record actions without reasoning. Each is an exposure.

How FISTA Solutions reads this

FISTA Solutions builds and operates production AI systems through AI agents, AI enablement, and forward deployed engineering: authorisation enforced in code outside the model, capability combinations reviewed as a set, and reasoning logged alongside actions so incidents can be understood, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To discuss what this means for your roadmap, message FISTA on WhatsApp, or read AI agent security risks.