Assistant vs Agent: Where Your AI Security Model Changes

Vendors use "assistant", "copilot" and "agent" as marketing gradations of the same thing. For security they are not gradations. There is a line, and crossing it changes what can go wrong, who owns it, and which reference list applies.

That line is whether the system can act, which is a narrower question than autonomy in the abstract.

The problem

A support tool starts by drafting replies. A human reads each one and sends it. Over a few months it gets better, and someone points out that a person clicking send on a draft they did not read is theatre. So the tool sends directly for a defined set of ticket types.

Nothing about the model changed, and the architecture diagram barely changed either. The failure mode did: before, the worst case was a bad draft that someone spotted. After, it is a message sent to a customer with no one in between.

Later it gets a tool to look up account details, so replies are accurate. Now a hostile ticket body is text the model reads while holding a credential that can query customer records. The tool crossed the line twice, and neither crossing had a design review, because each was a small increment on something that already existed.

Why it's different with AI

Five properties separate an agent from an assistant. They tend to arrive one at a time, which is why the line gets crossed without anyone noticing.

First, it holds an identity. The system authenticates as something. Once that is true, everything you know about privilege applies, except the entity deciding what to do with it is probabilistic.

Second, it can act, through tools that write, send, deploy or pay. What matters is whether a tool's effects are reversible and whether anyone sees them before they land, more than whether the tool exists at all.

Third, it keeps state, meaning memory across steps or sessions. This is the property people underestimate most. State means an attacker's influence can persist past the conversation that introduced it, which is what OWASP catalogues as Memory and Context Poisoning at ASI06 [1].

Fourth, it continues without you, running multi-step plans to completion. The blast radius of one bad decision grows from one response to every step that followed.

Fifth, it coordinates, whether that means multiple agents or one agent using tools that are themselves agents. Insecure Inter-Agent Communication (ASI07) and Cascading Failures (ASI08) exist because a fault in one component now propagates [1].

The OWASP Top 10 for LLM Applications 2026 still applies across all of this: prompt injection is LLM01 whether or not the system can act, and hidden context exposure is LLM08 either way [2]. It does not cover what happens after the model decides something, because it was written for applications that use a model rather than systems that act through one. The agentic list fills that gap, starting with Agent Goal Hijack at ASI01 and Tool Misuse at ASI02 [1].

The two lists complement each other. Using only the LLM list on an agent leaves the identity, memory and coordination risks unexamined. Using only the agentic list on an assistant is overhead for capabilities it does not have.

What actually works

Decide which side of the line each system is on, and write it down. Ignore the vendor's word and ask the five questions above. Any yes means agent, and agent means a different review.

Put the confirmation where the effect is. A human approving a plan is different from a human approving each irreversible step. The approval should sit at the point of effect, and only on effects that warrant it, because an approval that fires constantly stops being read.

Treat memory as an input rather than as storage. Anything an agent wrote to memory during a session influenced by untrusted content is untrusted on the next read. Scope memory per user and per task, and expire it. Shared long-lived memory across tenants is the version of this that goes badly.

Give the agent an identity of its own, instead of a human's account or a shared service account. This is the single change that makes an agent's actions attributable and its rights boundable, and it is infrastructure work rather than model work.

Bound the loop with a step limit, a time limit, and a spend limit, enforced outside the agent. An agent that has convinced itself it is nearly finished will keep going, and the limit that stops it cannot be one it can reason about.

Watch the actions more than the tokens. Logging prompts and completions tells you what the model said. Logging tool calls with their arguments and results tells you what it did, which is the record you need during an incident. The practical test: if an agent modified something last Tuesday, can you say which call did it, under which identity, with what arguments? If reconstructing that means reading conversation transcripts, the logging is at the wrong layer.

Separate the agents that read from the agents that write. Splitting one broadly capable agent into a retrieval agent and a narrowly scoped acting agent costs some elegance and buys a real boundary: the component exposed to untrusted content is not the component holding write credentials. It also makes the eventual incident question answerable, because the thing that acted had a small, enumerable set of things it could do.

What doesn't work

Deciding by product category fails because "copilot" describes marketing rather than capability. Some copilots only suggest; some commit code and trigger pipelines. The name tells you nothing about which.

Treating the human in the loop as a control without checking it is real fails too. If a person approves forty actions a day, they are a rubber stamp and the control is decorative. Fewer, better targeted approvals are stronger than more of them.

Assuming read-only tools make an agent safe is another mistake. An agent that can only read, but can read customer records and reach the network, is an exfiltration path. Least privilege applies to reads.

Securing the model and stopping leaves most of the risk in place. Guardrails on inputs and outputs address one layer. They do nothing about a credential that is too broad or memory that persists an injected instruction into tomorrow.

Letting the line get crossed by increments is the common one. Nobody approves building an autonomous agent. They approve adding a tool, then removing a confirmation step, then adding memory. Each is small; the result is a different system under the same name, usually still described in the change log by the name it had when it only drafted things.

Assuming the framework's defaults are conservative is the last trap. Agent frameworks optimise for getting something working, which generally means broad tool access, persistent memory on by default, and no step limit. Those are reasonable defaults for a demo and poor ones for production, and they are rarely revisited because nothing fails while they are wrong.

Where to start

• List your AI systems and mark each with the five properties: identity, action, state, continuation, coordination. The ones with three or more are agents whatever they are called internally.
• For each agent, name the identity it authenticates as. If it is shared or human owned, that is the first fix.
• Find the irreversible actions and check whether a human sees them before they happen, and whether that human has time to actually look.
• Check what memory persists, for how long, and whether it is scoped per user.
• Add the line to your change process. Adding a tool, removing a confirmation, or enabling memory should each trigger a review, because each one moves a system across the line.

So the useful question is whether a wrong decision produces a wrong answer or a wrong action, whatever the system is called. Everything else follows from that.

Sources

1. OWASP Top 10 for Agentic Applications 2026, OWASP GenAI Security Project, published 9 December 2025: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
2. OWASP Top 10 for LLM Applications 2026, OWASP GenAI Security Project, published 3 August 2026: https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/