How to let an AI agent access production — safely

Let coding agents request production operations through scoped controls. Define what they may touch, which changes need review and how you will check the result.

Treat proposed actions as untrusted

Treat proposed actions as untrusted input. A coding agent can be useful while its plans remain fallible. Enforce permissions and review gates around actions, outside the model.

Keep production credentials outside the client. Scope operating permissions to the task, and choose release-hash signing separately; automatic signing does not authorize every operating action.

Five non-negotiable principles

1. The agent never decides its own access

Enforce access outside the agent. Diagnosing an endpoint needs relevant logs and traces, not permission to delete its database.

2. The agent never sees raw credentials

Keep raw production credentials outside the client. Let it act through named, scoped operations enforced by the control layer.

3. Select high-risk state changes for human approval

Set review gates for high-risk operations. Configure release signing separately: manual review, exact-hash allowlist or automatic signing. Release policy is not blanket operating authority.

4. Record actions and validate recovery

Review managed-action history with health and logs. Prepare service recovery and data restore procedures before enabling production access.

5. Production is a destination, not a default

Keep the agent’s working environment separate from production. Reaching production should require an explicit target and authorized action.

The safe setup, step by step

1. Put a control layer between the agent and prod

Expose a fixed set of scoped operations instead of raw SSH/database credentials. The control layer checks the requested target and action before execution.

2. Scope permissions to the task

Start with read-only diagnosis. Add narrow write access for the required action through a deliberate grant.

3. Gate the selected high-risk state changes

Require the relevant owner review for high-impact changes. Let the agent prepare the patch and recovery plan without unrestricted execution rights.

4. Isolate backups out of reach

Keep recovery copies off-host under separately managed credentials, outside ordinary operating access.

5. Review actions and prepare recovery

Retain release/action history with health and logs. Test restart, rollback and data restore procedures separately; not every managed action is 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.