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

Give the agent only the read access its task needs. Require human review for destructive or high-risk changes, and make the execution policy explicit. Manual approval provides a per-release human veto; allowlist and automatic modes support different workflows and do not provide that same review step.

3. Inspectable code and release integrity

Understand the component that has authority on your server and the release it will execute. Review customer-side code where available and use the documented signature or integrity checks for the managed artifacts involved. Match the check to the installed release rather than assuming a public template represents every installation.

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. Action history and recovery

Record the managed change, the actor, and the reported result where available. Use that history with service health and logs to investigate a failure, and prepare restart, rollback, and database restore procedures before they are needed. An action record helps an operator; it is not a guarantee of complete coverage or reversibility.

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).

Operate the release, not just the request

Watch the service after delivery: did the process start, did the health check pass, and is managed traffic reaching the expected version? Infraveil brings releases, supervision, health, gateway policy, and recovery into one operating plane. Use its available logs and change history to investigate when those steps fail.

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?

Use scoped access and a deliberate release policy. Require manual review for high-risk changes; use allowlist or automatic approval only where unattended delivery fits your risk policy. Keep service health and recovery controls available to the operator.

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?

Use the signature or integrity checks documented for the installed component and managed release. Compare the relevant source and artifact, keep credentials scoped, and review available action history. These checks do not make every action independently attested.