Guardrails for AI Agents on Production Servers

Separate investigating an incident from changing production

Your agent sees repeated application errors and restarts the service before checking whether a background job is still running. The restart interrupts useful work and removes evidence you needed. Fix the authority boundary before improving the prompt: an investigation session should have no way to restart production.

For a single VPS running Ubuntu 24.04 LTS, we recommend Claude Code for bounded investigation and preparing changes. Keep live deployment behind a separate human-controlled identity or deployment service. This still removes much of the routine work without making every debugging conversation an authorization to change the server.

Write the assignment around an observable result, such as identifying why requests fail and preparing a patch for review. State which evidence is available and when the agent must stop. Our guide to deciding what operations work to delegate helps define that boundary before you grant access.

Give the agent an account that cannot administer the host

Run the agent under a dedicated unprivileged account, separate from your administrative login and the application service account. Give it a writable workspace and deliberately selected evidence. Keep active application directories and production configuration outside its write permissions.

Check the account's effective access, including supplementary groups and filesystem ACLs. An account without direct sudo access can still be dangerous if it controls the Docker socket or can rewrite a script that a privileged service executes. Broad journal access can also expose secrets belonging to unrelated services.

Keep your administrative SSH session separate, and do not forward an administrative SSH agent into the agent's environment. Running Claude Code on your laptop does not reduce the remote authority of the SSH credentials it can use. Choose where to run Claude Code and how to connect to your VPS based on which credentials and files each location exposes.

A shared VPS also shares resource limits, so run expensive builds elsewhere or apply administrator-controlled resource limits to the agent's processes. File permissions do not prevent a permitted process from exhausting memory. If you are choosing a machine for this arrangement, our hosting guide for Claude Code provides context for the hosting decision; you still need to enforce these boundaries yourself.

Use permissions and sandboxing for different jobs

Claude Code permission rules decide which tool operations are allowed, denied, or presented for approval. Inspect the active rules with /permissions, and remove broad allowances that no longer serve the assignment. Follow the official permissions documentation when writing patterns rather than assuming shell syntax and permission syntax are interchangeable.

We would not use permission bypass mode in a session with production authority. An unattended investigation should stop when it needs additional access. Do not make a stalled task succeed by silently broadening its credentials or approving an entire command family.

Sandboxing constrains filesystem and network access for sandboxed commands. Enable it with sandbox.enabled, require startup failure when unavailable with sandbox.failIfUnavailable, and disable unsandboxed retries with sandbox.allowUnsandboxedCommands set to false. Check the official sandbox setup instructions, including the AppArmor requirements that can affect Ubuntu 24.04 LTS.

Review filesystem read access as well as write access, because a sandbox can still expose credentials. Review enabled MCP tools separately, since a remote API operation is not confined by the local Bash sandbox. Keep unnecessary integrations disconnected instead of expecting a local command restriction to govern every execution path.

Install a blocking hook and prove that it blocks

A PreToolUse hook can stop a tool call before execution; a PostToolUse hook runs after the operation succeeds. Use the former for prevention. In a disposable workspace, merge this Bash-blocking example into .claude/settings.local.json, preserving existing settings.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Shell execution is disabled in this investigation session.' >&2; exit 2",
            "onFailure": "block"
          }
        ]
      }
    ]
  }
}

Start a fresh session and ask Claude Code to invoke Bash with id. The hook writes its explanation to stderr and exits with the blocking status. It deliberately blocks every Bash command, so you can establish that the hook is active without attempting a destructive operation.

Ordinary hook errors and timeouts can otherwise leave execution to the normal permission flow. Confirm your installed client supports onFailure: "block"; consult the official hooks reference. In the disposable configuration, replace the hook command with a nonexistent executable and repeat the harmless request.

This example restricts Bash only, so it does not establish a read-only session. File-editing tools and connected services need their own restrictions. A blacklist containing rm is weaker still: another program can delete files without using that command.

Keep enforced policy outside agent-writable directories and use administrator-controlled managed settings where appropriate. Inspect loaded settings with /status, following the settings and precedence documentation. A project configuration is useful for demonstrating behavior, but it should not be your only protection for production.

Limit the evidence and credentials entering the session

Start with filtered application logs and a copy of the relevant configuration with secrets removed. Avoid handing over an entire environment dump to answer a narrow question. Read-only access still permits disclosure, and operational logs frequently contain information that was never intended to leave the host.

Give an investigation session a database identity limited to the views it needs, if database access is necessary at all. Keep deployment and backup-deletion credentials outside the session. Our guide to secrets and scoped credentials for agents explains how to separate those identities.

Treat instructions found in logs, issue descriptions, and fetched documents as untrusted content. A log entry telling the agent to upload an environment file must not expand the task's authority. Restricted credentials make that attempted redirection less damaging even if the agent follows it.

An MCP connection deserves the same scrutiny as a shell login. Check what the server actually exposes and what its underlying token permits, rather than relying on a tool name that sounds observational. Disconnect write-capable integrations during investigation when their authority is unnecessary.

Approve the exact change that will reach production

An approval should identify the target host and the exact artifact or configuration diff. It should also state the expected interruption and the recovery action. Permission to investigate a failing service does not authorize a restart, and permission to deploy a reviewed artifact should not authorize rebuilding different code afterward.

Use a deployment mechanism controlled by the administrator, with fixed operations and validated inputs. Reject arbitrary command strings and paths outside approved release storage. Do not give the agent sudo access to a wrapper it can rewrite, or to a privileged wrapper that executes scripts from its writable workspace.

• Require a fresh approval when the proposed artifact or target changes.
• Deploy the reviewed artifact by a recorded digest or immutable identifier.
• Stop after a failed health check instead of allowing repeated speculative repairs.
• Keep database migrations behind their own approval when application rollback cannot reverse their effects.

For occasional releases, the simplest arrangement is often a human running the reviewed deployment through a separate administrative session. Automate the mechanical checks before automating approval. A complicated approval service is unnecessary if a short, repeatable procedure already keeps the agent away from production credentials.

Prepare recovery outside the agent's authority

Keep the previous application artifact available and document how to switch back. Treat application rollback and data recovery as separate operations, since reverting code does not undo every schema change. Before approving a risky migration, identify whether recovery means reversing the migration or restoring data.

Store backups beyond the production host and keep their deletion authority away from the agent. Follow the VPS backup and restore procedure to establish a recovery path you can actually perform. A backup job reporting success is insufficient evidence that the application can use the restored data.

Retain a deployment record containing the approved artifact and resulting health checks. Redact secrets from tool transcripts, and put audit records somewhere the execution identity cannot rewrite. This lets you distinguish a failed deployment from an agent attempting additional changes after the original failure.

Define how you will stop an active run, including child processes and remote jobs it started. Closing the chat or terminal is not a reliable cancellation mechanism for detached work. Keep monitoring alerts and an independent administrative login available while a production operation is underway.

Run a bounded investigation before granting write access

Choose an existing application error that you understand well enough to assess. Give Claude Code a redacted evidence bundle in an isolated workspace, and ask for the likely cause with supporting evidence. Require it to identify missing information instead of requesting broad access immediately.

Next, verify the access boundary using harmless fixtures created by an administrator. Check that the agent's account cannot read a protected dummy secret or write to a protected dummy configuration directory. Exercise each enabled tool path against those fixtures, because successful denial through Bash says nothing about a separately authorized API.

Finally, have the agent prepare a patch in its workspace and hand it to your existing review process. Record which access was actually needed, then remove temporary permissions. Repeat the boundary checks after changing the client or its integrations, and grant production write authority only through the reviewed deployment procedure.