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. Set permissions and review requirements for high-risk operational actions. Release-hash signing is a separate policy: manual review, exact-hash allowlisting, and automatic signing do not grant assistant or remediation permissions.

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 migrations, deletes, scale operations, configuration edits, and remediation actions require human review through their applicable permissions and review settings. Separately, choose how managed release hashes are signed: manual review, an exact-hash allowlist, or automatic signing. Those release-signing modes are not blanket authorization for other operations.

4. Record actions and validate recovery

Review available managed-action history alongside service health and logs. Operational and remediation actions use their own permissions and review settings, separate from release-hash signing. Define recovery and rollback procedures for the service and infrastructure involved 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

For high-risk operational actions, configure the applicable permissions and review settings to require a person before execution. The agent can propose a fix and recovery plan without receiving unrestricted authority. Configure release-hash signing separately; an automatic signing policy is not a human review gate.

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. Review actions and prepare recovery

Keep the available release and action history alongside service health and logs so an operator can understand a change and decide what to do next. Define restart, rollback, and database restore procedures before production access is enabled. Records cover managed activity; not every action is recorded or reversible.

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.
• Configure human review for selected high-risk operations through their applicable permissions; choose release-hash signing policy 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 scoped operations instead of holding raw production credentials. Set operational permissions and human-review requirements for the task. Manual, exact-hash allowlist, and automatic settings govern release-hash signing, not every action the agent can request.

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?

Infraveil's job continues after delivery: supervise managed processes, check service health, apply gateway traffic rules, investigate failures, and run the configured recovery workflow. Release-hash signing is one control within that larger backend operating plane; operational permissions are separate.