AI agent security: the checklist before agents touch production tools

"Is our AI agent secure?" is the wrong-shaped question. It implies one setting to check. In practice, agent security is five separate problems that each fail independently: how credentials are held, how much an agent can see versus what it needs, whether the content an agent reads can hijack it, whether risky actions run unattended, and whether anyone can reconstruct what happened afterward. A team can solve four of these and still get burned by the fifth.

1. Credential exposure

The most common failure is also the simplest: a raw API key or OAuth token sitting in an agent's runtime, config file, or prompt history. Anything that can read the agent's environment can read the credential, and that credential usually reaches far more than the one task the agent was given. The fix is to stop handing out the underlying SaaS credential at all — issue each worker a scoped, revocable token instead, and keep the real credentials server-side. See scoped tokens vs. raw API keys and from shared keys to per-worker identity for the mechanics.

2. Tool overexposure

An agent that can see a tool will eventually try to use it, even outside its actual job. Overexposure is not a hypothetical — it is the default state of most MCP setups, where every connected tool is visible to every agent. Least-privilege scoping and tool filtering by role are the two controls that close this, and they compose: filter what the agent can discover, then scope what the ones it can see are allowed to do. Detail in least privilege for AI agents and tool visibility for AI agents.

3. Prompt injection through tools and content

A model that trusts whatever text it reads — a webpage, a document, a tool description — can be steered by instructions hidden in that text. This is not limited to chat input. MCP tool descriptions, third-party server metadata, and scraped content are all untrusted input that reaches the model the same way a user message does. You cannot reliably train this out of a model; you can make sure that even a successfully injected instruction still has to pass a permission check before it does anything. See prompt injection and the permission boundary and, for the MCP-specific version of this risk, MCP server security.

4. Risky actions running unattended

Reads are cheap; writes are not. Spend changes, publishes, code pushes, and customer-facing edits deserve a different bar than an agent pulling a report. The practical answer is not "a human reviews everything" — that just recreates the bottleneck agents were supposed to remove. It is gating the specific action classes that are expensive to get wrong, while letting analysis and read-only work run freely. See approval gates for AI workers and human-in-the-loop without the bottleneck.

5. No audit trail after the fact

When something goes wrong — and eventually something will — the question is always the same: which worker did what, through which credential, and what happened as a result. If every agent shares one API key and there is no per-call log, that question has no answer. An audit trail is not a nice-to-have added after incidents start; it is the thing that makes every other control on this list verifiable. See what to log in an AI agent audit trail.

A minimal checklist

• No raw SaaS credentials in agent runtimes, prompts, or local configs — scoped tokens only.
• Each agent role sees only the tools and accounts its job requires, not the full catalog.
• Tool descriptions and third-party MCP servers are treated as untrusted input, not documentation.
• Action classes that spend money, publish, push, or touch customers require approval; reads do not.
• Every call — allowed, blocked, or pending — is logged with the worker, tool, and result.

None of these five is optional, and none of them substitutes for another. A scoped token does not stop tool overexposure. An approval gate does not create an audit trail. Treat them as five separate checks, not one "security" checkbox.

FAQ

Is AI agent security different from normal application security?

It overlaps but adds a layer: application security mostly assumes a human or a fixed program is making the calls. Agent security has to account for a model deciding, at runtime, which tool to call next based on text it just read — which is why prompt injection and tool overexposure are agent-specific concerns on top of standard credential and access hygiene.

Where do most AI agent security incidents actually start?

In practice, credential exposure and tool overexposure account for most of it — a shared key with too much reach, or an agent that could see a tool it never should have discovered. Prompt injection gets more attention but requires the first two failures to be dangerous: if the agent's token is properly scoped, a successfully injected instruction still hits a permission wall.

Can these five controls be added incrementally, or do they need to ship together?

Incrementally is fine and normal. Scoped tokens and an audit trail are usually the highest first return, since they contain damage and make every later incident debuggable. Tool scoping and approval gates typically follow once the first agents are running in production.