When AI agents get privileges

EPIC28 Ltd · 1 September 2026

The first wave of generative AI security was obsessed with content. Hallucinations. Toxicity. Brand risk. What the model might say if you asked it the wrong thing, the wrong way.

The second wave is about something more dangerous: capability.

Once an LLM can call tools — open tickets, query internal systems, send emails, push code, trigger workflows — it stops being a chat interface and becomes a new kind of privileged workload. Not malicious by design. Not even unreliable in the way people assume. Just connected to real systems with real permissions. And that is enough.

An agent doesn't need to "hack" anything in the classic sense. It needs to be steered. The attacker's job becomes persuasion by proxy: slip instructions into a document, a webpage, a support ticket, a code comment, a PDF. The agent reads it as context; the model treats it as instruction. Suddenly the confused deputy problem isn't academic — it is in production.

The model is not the boundary. The boundary is whatever the model can reach.

This is why the old comfort of "the model is hosted by a reputable vendor" doesn't help much. The security architecture has to move one layer down: away from arguing about prompts and toward controlling actions. The model should propose. Something else should decide.

That "something else" is an enforcement layer sitting between the agent and the tools, applying policy to every tool call: what can be called, by whom, with which arguments, against which resources, under which conditions. The rest is hygiene that becomes suddenly non-negotiable:

• Short-lived credentials instead of long-lived tokens that get copied into notebooks.
• Narrow scopes instead of "temporary" broad permissions that quietly become permanent.
• Step-up approvals for destructive actions, because the point of automation is speed — and speed is exactly what you don't want when the decision is wrong.

The part most teams underestimate is detection. Agent misuse looks like legitimate business activity because it is business activity, just misdirected. If you don't baseline tool usage, you won't see the early shape of an incident: an agent touching unusual datasets, calling unfamiliar tools, hammering an API with small variations on the same request.

This perspective is the founding assumption of Raucle: capability receipts for every gated action, and a gate that fails closed. If you're drawing the boundary for your first agent deployment, the NCSC's agentic AI guidance is a sound starting map — and the architecture above is how we'd implement it.