Agents are the new insiders, with API keys
In plain words: An AI helper that can send email and change records is like a new member of staff who believes anything they read, so it needs a boss, limits and a diary of what it did. AI, explained simply
In short
- An AI agent is software that decides its own next step and then takes it, using real credentials and real tools.
- That makes it an insider. It can be careless, it can be over-privileged, and unlike a person it can be persuaded by any text it reads, including text written by an attacker.
- The controls are the ones we already use for privileged staff: a named owner, the least access that works, approval for actions that cannot be undone, and a full record of what it did.
Why "insider" is the right word
Insider risk has always been about people who already have access: they can make mistakes, be tricked, or act against the organisation. An agent with an API key fits each part of that description.
The difference is that an agent takes instructions from its inputs. Prompt injection is the name for hiding instructions in content the agent reads: an email, a web page, a document, a ticket. If the agent cannot tell the user's request from the attacker's text, it may follow both. No current model fully solves this, so the design has to assume it will sometimes happen.
Simon Willison has described the most dangerous combination as a "lethal trifecta": an agent that can read private data, is exposed to untrusted content, and can send data out. Any agent with all three can be steered into leaking what it can read.
What goes wrong
OWASP calls the core problem excessive agency: an agent given more functions, more permissions or more autonomy than its job needs. The typical causes are familiar from service accounts.
- Borrowed power. The agent runs with its builder's own credentials, or a shared admin key, because that was quickest.
- Broad tools. It is given a "send email" tool when it only needed "draft email", or full database access to answer read-only questions.
- No brake. Payments, deletions and messages to customers go out without a person seeing them first.
- No owner. Six months later nobody remembers who set it up or what it is allowed to touch.
OWASP's Top 10 for Agentic Applications, published for 2026, adds agent-specific risks such as tool misuse, identity and privilege abuse, and memory poisoning.
Treat it as a privileged actor
My own view: an agent should go through the same door as any new privileged account.
- Its own identity. One identity per agent, never a person's credentials, so its actions can be told apart and its access revoked on its own.
- Least access. Read-only by default, narrow tools, short-lived tokens, and only the data its task needs.
- Break the trifecta. If it must read untrusted content, cut its ability to send data out, or the other way round.
- People on the irreversible steps. Payments, deletions, external messages and access changes wait for a human to approve.
- A record. Every tool call logged with the input that prompted it, so you can reconstruct what happened.
What to do on Monday
- List the agents already running, including the ones built by teams on their own. Give each one an owner.
- Check which credentials each uses. Replace any personal or shared admin keys with an identity of its own.
- For each agent, ask whether it reads untrusted content, holds private data and can send data out. If all three, change the design.
- Decide which actions always need a person to approve, and enforce it in the tool, not in the prompt.
Sources
- OWASP, LLM06:2025 Excessive Agency, in the Top 10 for LLM Applications 2025.
- OWASP, Top 10 for Agentic Applications for 2026.
- Simon Willison, The lethal trifecta for AI agents: private data, untrusted content, and external communication (June 2025).
- NCSC and CISA, Guidelines for secure AI system development (2023).
Personal work and my own view, not my employer's. Sources are public.