AI agent security: what to lock down before you deploy

Quick answer

Lock down five things: give each agent only the tools and data it needs (least privilege), store credentials in a vault not in prompts, put human review gates before any irreversible action, keep a full audit trail of what each agent did and when, and scope each agent's role narrowly so that a mistake in one agent can't cascade across the whole system.

Why AI agent security is different from regular software security

Most software security is about preventing unauthorised access — keeping attackers out. AI agent security has a different primary failure mode: the agent is authorised, it's doing exactly what it was told, and the damage still happens.

An agent that has write access to your CRM, your email system, and your billing platform isn't a security risk in the traditional sense. No one broke in. But if it misclassifies a lead, it might email a hundred people with the wrong message, update their CRM records, and trigger a billing event — all in a single run, all before a human sees it.

The threat model for AI agents is less about intrusion and more about blast radius. How much can go wrong in a single autonomous run? And is there anything to stop it?

Three properties make agents different from regular software:

They act autonomously. A misconfigured API endpoint sits there broken. A misconfigured agent acts on it, repeatedly, at scale.

They chain together. In a multi-agent system, a mistake in one agent becomes an input to the next. Errors compound rather than stop.

They reach external services. Agents call APIs, send messages, write to databases, and post to third-party platforms. The blast radius isn't limited to your internal systems.

Getting the security architecture right at design time is significantly cheaper than retrofitting it after something goes wrong.

What to lock down

1. Access — least privilege per agent

Every agent should have access to exactly the tools and data it needs for its job, and nothing more.

This sounds obvious. In practice, it requires deliberate effort at design time. When you're building a pipeline quickly, the path of least resistance is to give every agent access to everything and tune it later. The problem is that "later" often means "after the first incident."

A lead research agent needs read access to your CRM and access to a web search tool. It does not need write access to your CRM, access to your email system, or access to your billing platform. A CV screening agent needs access to your ATS and a scoring prompt. It does not need access to Slack or to any customer-facing system.

Define each agent's access policy as part of the design, not as an afterthought. The question to ask for each agent: what is the minimum set of tools and data this agent needs to do its job?

2. Credentials — vault, not hardcoded

API keys, OAuth tokens, and service passwords should never appear in agent prompts, role definitions, or workflow configurations. They should live in a credential vault and be applied at run time.

The practical reason is simple: anything in a prompt can appear in model outputs. If a key is in the prompt, it can end up in a log, a response, or a downstream agent's input.

The less obvious reason is that centralising credentials makes rotation easy. When an API key needs to change, you change it in one place and every agent that uses it picks up the new value on the next run. When credentials are scattered across workflow configs, rotation becomes a manual process prone to gaps.

A vault also makes auditing possible. You can see which agents are using which credentials, revoke a credential for a specific agent without affecting others, and identify unused credentials that represent unnecessary attack surface.

3. Human gates before irreversible actions

Autonomous doesn't mean unobserved. For any action that can't be undone — sending an email, posting publicly, deleting a record, initiating a payment — there should be a human review step before the agent proceeds.

This is a design decision, not a technical one. The agent doesn't "decide" to have a gate. You put one there when you design the workflow, at the point in the pipeline where an irreversible action is about to happen.

A well-placed gate looks like this: a research and drafting agent runs autonomously, producing a draft response to a customer inquiry. Before the send agent dispatches the email, the draft surfaces to a human for approval. The human can approve it, edit it, or reject it. Only on approval does the email go out.

The cost is a small delay at one point in the pipeline. The benefit is that no agent sends on your behalf without a human seeing it first. For most organisations, that's a reasonable trade.

The common mistake is placing gates at the end of a long pipeline, after the irreversible action has already happened, or not at all because the team is optimising for speed. The right place for a gate is before the irreversible step, not after.

4. Audit trail — know what each agent did

Every agent action should be logged: which agent ran, what tools it called, what inputs it received, what outputs it produced, and what time it happened.

This matters for three reasons. First, debugging: when something goes wrong in a multi-agent pipeline, you need to be able to trace the error back to its source. Without logs, a mistake in agent two that surfaced in agent four is nearly impossible to diagnose.

Second, compliance: in regulated industries — finance, HR, healthcare, legal — there's often a requirement to demonstrate that a decision was made by a human, or at minimum to show what information was available when a decision was made. Agent run logs are the evidence trail.

Third, improvement: patterns in agent failures are visible in logs before they become incidents. An agent that's frequently calling the wrong tool, or producing outputs that humans consistently reject at a gate, is a signal that the design needs adjustment.

5. Role scope — narrow agents, small blast radius

A narrow agent with a single, well-defined job is inherently more secure than a general-purpose agent with broad authority. Not because of technical controls, but because a mistake in a narrow agent can only affect the narrow thing it was doing.

An agent whose job is "classify this support ticket as billing, technical, or general" can make a classification error. The consequence is that a ticket goes to the wrong queue. An agent whose job is "handle this support ticket end to end — classify it, draft a response, escalate if needed, update the CRM, and close the ticket" can make a classification error that then propagates through every downstream step.

This is the multi-agent design principle applied to security: decompose the workflow into small, single-purpose agents, each with a defined input and a defined output. Keep the scope narrow. The blast radius of any single failure stays proportional to that agent's scope.

What to get right at design time

Security decisions in AI agent systems have a well-known property: they're cheap at design time and expensive to retrofit.

At design time, adding an access policy to an agent takes minutes. Adding a credential vault is an architectural choice, not a migration. Placing a gate in a pipeline is a design step.

After deployment, tightening access requires understanding which agents are using which credentials in which contexts — and changing it without breaking live workflows. Adding gates to a running pipeline means modifying something users or other systems depend on. Building an audit trail into a system that wasn't designed for it means touching every integration point.

The five things above are all design-time decisions. They don't require special technology. They require that someone asks the right questions before building starts: what does each agent need access to, where do credentials live, which actions require human review, what gets logged, and how narrow is each agent's scope?

Where Envelope fits

Envelope's design output is a structured spec — agents, roles, tools, access policies, approval gates — that documents these decisions before implementation begins. The spec isn't code, but it captures the security architecture: which agent has access to which tools, where the human review steps sit, and what each agent's scope is.

That spec is what you hand to an engineering team to implement, or load into a runtime directly. The design work happens in Envelope. The security decisions are part of the design.

→ Start designing a workflow
→ How human-in-the-loop gates work
→ Sub-agent design: the five components every agent needs

---

Frequently asked questions

What is AI agent security?

AI agent security covers the controls that limit what an AI agent can access, what it can do without human oversight, and what trace it leaves behind. The primary concern isn't intrusion — it's blast radius: how much can go wrong in a single autonomous run, and what's in place to contain it.

What does least privilege mean for AI agents?

Least privilege means each agent gets access to exactly the tools and data it needs for its specific job — nothing more. A research agent gets read access to the data sources it needs. A send agent gets access to the email tool. Neither gets access to the other's domain. Limiting access per agent limits the damage a single misconfigured agent can cause.

Why shouldn't I put API keys in agent prompts?

Anything in a prompt can appear in model outputs — including logs, responses, and downstream agent inputs. Keys in prompts can leak. They also make rotation difficult: when a key changes, you have to find and update every prompt that contains it. A credential vault centralises storage and decouples keys from the agents that use them.

What is a human gate in an AI agent workflow?

A human gate is a deliberate pause in an agent pipeline that requires a human to approve, edit, or reject the agent's output before the workflow continues. Gates are placed before irreversible actions — sending an email, posting publicly, initiating a payment — so a human sees the output before it has consequences.

Do all AI agent actions need a human gate?

No. Gates are for irreversible actions with real consequences — customer-facing communications, payments, record deletions. Read-only operations (research, classification, summarisation) can run autonomously without review. The design question is: if this agent produces incorrect output, can the damage be undone? If not, gate it.

How do I audit what an AI agent did?

Agent run logs should record: which agent ran, what tools it called, what inputs it received, what outputs it produced, and when. In a multi-agent system, logs should be linkable by run ID so you can trace a decision through every agent that touched it. This is the evidence trail for debugging, compliance, and improvement.

Is AI agent security different in regulated industries?

Yes, in degree rather than kind. The same five controls apply — least privilege, credential vault, human gates, audit trail, narrow scope — but regulated industries (finance, HR, healthcare, legal) typically have formal requirements around auditability and human oversight that make these controls mandatory rather than recommended. Design for them from the start rather than retrofitting them when compliance requires it.

What's the most common AI agent security mistake?

Over-permissioning at build time and planning to tighten access later. It's faster to give an agent access to everything and cut it back once the workflow is tested. In practice, access rarely gets cut back — the workflow goes live, the team moves on, and the agent retains broader access than it needs indefinitely. The right time to define access policies is during design, before a line of code is written.