How to let an AI agent access production — safely

Claude Code and Cursor can ship in minutes. The danger isn't what they build — it's what happens when you point them at production without effective controls. This is the threat model, the principles, and a step-by-step setup for governing agent access to production.

The one mental model that fixes everything

Almost every safe-agent question answers itself once you adopt a single mental model: treat the agent as an untrusted actor. Not because the model is malicious, but because it's non-deterministic. It can be right 999 times and, on the 1,000th, decide that the cleanest way to fix a credential mismatch is to reset the database. You cannot review reasoning that happens in tokens. So you don't try — you put controls around the actions instead.

An untrusted actor should not receive raw production credentials or unnecessary system access. High-risk actions should use an approval policy appropriate to the environment, and configured actions should produce scoped evidence. Manual, exact-hash allowlist, and automatic modes do not provide the same per-release human veto.

Five non-negotiable principles

1. The agent never decides its own access

Access is granted by a layer the agent doesn't control, scoped to exactly what the current task needs. An agent debugging a slow endpoint needs to read logs and traces — it does not need a credential that can drop tables. Least privilege, enforced outside the agent.

2. The agent never sees raw credentials

If the agent holds your database password or a root API key, you've already lost — a prompt injection, a hallucinated command, or a bad plan now has the keys. The agent should act through a control layer that holds the credentials and exposes only governed actions.

3. Select high-risk state changes for human approval

Define which deploys, migrations, deletes, scale operations, and config edits must stop for explicit human review. Other paths may use exact-hash allowlisting or automatic mode, so the policy and evidence boundary must be explicit.

4. Record actions and validate recovery

Configured Infraveil-managed actions follow the selected approval mode and produce an operational record. Recovery and rollback depend on the service, configuration, and infrastructure, so define and validate those procedures before relying on them.

5. Production is a destination, not a default

The agent's normal working environment is not production. Reaching prod is itself an explicit, gated step — so the agent can't drift into it by accident.

The safe setup, step by step

1. Put a control layer between the agent and prod

Instead of handing the agent SSH keys and a database URL, route its production actions through a control plane that holds the credentials and exposes a fixed set of governed operations (deploy, restart, read logs, trace a request, roll back). The agent calls the operation; the layer decides whether and how it runs.

2. Scope permissions to the task

Grant the minimum: read-only for diagnosis, narrow write scopes for specific actions. No standing credential that can delete data or backups. If the agent needs more, that's a deliberate, logged grant — not a default.

3. Gate the selected high-risk state changes

Configure the layer so destructive and production-changing actions pause and require a person to approve. The agent can draft the fix, attach the reasoning and a rollback plan, and queue it — but nothing ships until you click approve.

4. Isolate backups out of reach

Keep snapshots off-box, under credentials the operating layer cannot touch. The blast radius of any single action must never include your recovery path.

5. Record and prove everything

Configured managed actions can produce inspectable proposal, approval, execution, and receipt evidence. Evidence may be partial, server integrity links are not universal customer signatures, and reversibility depends on the action and available recovery material.

Anti-patterns that get people breached

• --dangerously-skip-permissions on a production box. It removes the one gate between the model's plan and an irreversible action. The flag is named after exactly what it does.
• Pasting prod DB credentials or root API keys into the agent's context. Now any bad plan or injected instruction has full power.
• Letting the agent run in the same environment it's meant to manage. An agent should never control the box it itself runs on.
• Auth or paywall checks the agent "added" living only in the client. AI frequently ships access control to the browser; verify it server-side.
• "We'll add guardrails later." Later is after the incident. The gate is cheap before; the breach is expensive after.

The pre-flight checklist

• The agent acts through a control layer, not with raw production credentials.
• Access is least-privilege and granted outside the agent's control.
• Selected high-risk state changes require explicit human approval; other configured modes are documented separately.
• Production is an explicitly-gated destination, separate from the agent's working environment.
• Backups are off-box and beyond the operating credentials' reach.
• Configured actions should retain bounded evidence; reversibility and attestation depend on the action, mode, and available recovery material.
• --dangerously-skip-permissions is never used against production.

Frequently asked questions

Is it safe to give Claude Code or Cursor access to production?

It can be safer when the agent acts through a scoped control layer instead of holding raw production credentials. Use manual approval where a per-change human veto is required; exact-hash allowlist and automatic modes have different tradeoffs, and audit evidence remains bounded.

What's the safest way for an AI agent to act on production?

In the manual-review example: agent proposes → human approves → control layer executes with scoped permissions → bounded evidence is recorded. Verify credential exposure and bypass paths separately; do not assume universal signing or coverage.

Should I use --dangerously-skip-permissions on a production server?

No. It removes an important permission boundary and can allow a model's plan to become a live, potentially irreversible action without the intended review.

How is this different from just using a deploy platform?

A deploy platform primarily gets code onto infrastructure. A governance layer can add configured permissions, release modes, and bounded evidence, but those controls must be verified for the selected workflow rather than assumed universal.