How to secure AI-agent deployments

Agents like Claude Code and Cursor can now ship backend changes on their own. Banning them loses the speed; trusting them blindly loses production. This guide is the middle path: the principles and the concrete, inspectable practices for letting an agent operate production without handing it the keys.

Why agent deploys are different from human deploys

A human who fat-fingers a destructive command usually notices, hesitates, or gets stopped by a teammate. An AI agent executes at machine speed, doesn't hesitate, and will confidently take an action that looks right from the text it was given but is wrong for your system. The failure modes that matter aren't malice — they're a plausible-but-wrong command, a hallucinated file path, an over-broad permission, or a remediation that fixes one thing and breaks another.

So the goal isn't to make the agent perfect. It's to make the system around the agent safe: bound what any single action can do, require a human where the stakes are high, and make everything that happened inspectable after the fact. The rest of this guide is how.

Five principles

1. Least privilege, always

An agent should hold the narrowest set of capabilities that lets it do its job — and nothing it doesn't currently need. Don't hand it your cloud root credentials so it can restart one service. Scope tokens to a single client, agent, or service; prefer per-action grants over standing access.

2. Human-in-the-loop for anything irreversible

Reads are cheap and safe; let the agent read freely. Mutations — deploys, migrations, deletes, permission changes — should be requests that enter an approval queue, not actions the agent applies itself. The agent proposes; a human disposes. This single boundary eliminates most catastrophic outcomes.

3. Signed and inspectable code

You should never run privileged code you can't read, and an agent should never run code it can't verify. The agent that has authority over your machine should verify its own source (signature and hash) before executing anything, and you should be able to diff what's running against published source. Trust by inspection, not assertion.

4. Bounded blast radius

Assume any single action could be wrong, and design so that "wrong" is survivable. Constrain an agent to one host or one service rather than the whole fleet; roll changes out gradually; keep recovery controls ready. The question to ask of every grant is: "if this goes wrong, what's the largest thing it can take down?"

5. Tamper-evident audit

Every action an agent takes should land in an append-only, hash-chained ledger that you can verify yourself — offline, trusting nothing. After an incident, "what exactly happened, in what order, and did anyone edit the record?" should have a cryptographic answer, not a verbal one.

Putting it into practice

Write the rules down as policy

Document which changes are allowed, which identity may request them, and when a person must approve. Apply those rules using controls supported by your deployment system. Test denied actions as well as permitted ones before enabling production access.

Give the agent a governed interface, not a shell

Give automation a narrow interface for reading status and requesting changes. Keep execution permissions separate, and require review where your deployment policy calls for it. Verify which approval controls the chosen system actually enforces.

Check readiness and blast radius before you trust it

Before an agent goes near production, know what it could touch and whether the target is even ready. Two quick checks: the AI-agent blast-radius checker ("what can this agent actually destroy?") and the production-readiness checker (paste a Dockerfile/compose/.env and get a graded checklist).

Verify what's actually running

Trust, then verify — yourself. Re-hash your agent's audit ledger to confirm nothing was edited, deleted, reordered, or gapped, and verify release signatures against the published key. See how Infraveil makes the customer-side code inspectable.

Free tools that help

More at infraveil.com/tools. Related reading: add governance to your existing deploy.

FAQ

Should I let an AI agent deploy to production?

Yes — but not with unrestricted access. Let it propose and request changes; route everything that touches production through a policy and a human approval. The agent gets speed, you keep control.

How do I limit what an AI agent can break?

Least-privilege scoping, allowed/denied actions declared in a governance policy enforced in CI and at runtime, and a blast radius limited to a single host or service rather than the whole fleet.

How do I know the code an agent runs hasn't been tampered with?

Run an agent that verifies its own code (signature and hash) before executing, keep a tamper-evident audit ledger you can re-hash yourself offline, and verify release signatures against a published key.