How to Prevent AI Coding Tools from Touching Production

Mar 25, 2026

I almost had a heart attack when I realized my AI coding assistant had access to production AWS credentials. It could have deleted databases, modified live configurations, or exposed sensitive data—all because I hadn’t properly isolated my environments. That’s when I learned: never give AI coding tools production credentials, ever.

The Problem: AI Tools Should Never Touch Production

The fundamental rule is simple: dev and prod are different, isolated environments. Your LLM is never permitted to touch prod. This isn’t about trusting AI—it’s about basic security hygiene.

The risks of giving AI tools production access include:

Accidental deletion of production resources
Exposure of secrets and credentials in logs or commits
Unauthorized modifications to live infrastructure
Data breaches from overly permissive access
Compliance violations from uncontrolled access

As one experienced developer put it: “You never develop in prod. AI or no AI.” This principle existed long before AI coding assistants, but the speed at which AI can execute commands makes the consequences far more severe.

Strategy 1: Complete Environment Isolation

The first and most critical step is ensuring your development and production environments are completely separate. This means:

+------------------+          +------------------+
|   Development    |          |   Production     |
|   Environment    |          |   Environment    |
+------------------+          +------------------+
|                  |          |                  |
| - Dev databases  |   WALL   | - Prod databases |
| - Dev APIs       | <------> | - Prod APIs      |
| - Dev secrets    |          | - Prod secrets   |
| - AI tools OK    |          | - AI tools NEVER |
|                  |          |                  |
+------------------+          +------------------+

Your AI coding tools should only ever interact with the development environment. Production access should require:

Explicit human authentication
Separate credentials stored outside the AI’s reach
Manual approval for any changes

Strategy 2: Scoped IAM Roles and Permissions

If you must give AI tools any cloud access (even for development), use heavily scoped permissions. The principle is straightforward: “If you’re going to give it AWS SSO, give it read only, or heavily scoped IAMs.”

Here’s an example of a minimal read-only IAM policy for development:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket",
        "ec2:Describe*",
        "lambda:ListFunctions",
        "lambda:GetFunction"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "us-west-2"
        }
      }
    }
  ]
}

Notice what’s missing:

No s3:Delete* or s3:Put*
No ec2:TerminateInstances
No lambda:InvokeFunction on production resources
Region restriction to prevent accidental cross-region access

Strategy 3: Separate Credential Chains

Never store production credentials in the same place as development credentials. Use separate credential chains:

# Development credentials - AI tools can access
export AWS_PROFILE=dev
export AWS_CONFIG_FILE=~/.aws/dev-config
export AWS_SHARED_CREDENTIALS_FILE=~/.aws/dev-credentials

# Production credentials - AI tools NEVER access
# Store in a completely separate location
export PROD_AWS_PROFILE=prod
# These should be accessed only via:
# 1. Separate terminal session
# 2. Hardware security key
# 3. SSO with MFA

The key is physical separation. Your AI assistant shouldn’t even be able to read the file paths where production credentials live.

Strategy 4: CI/CD Pipeline Controls

Your CI/CD pipeline should be the only path to production. AI tools should never have direct deployment access:

name: Production Deployment

on:
  push:
    branches: [main]
  workflow_dispatch:
    inputs:
      environment:
        description: "Target environment"
        required: true
        default: "staging"
        type: choice
        options:
          - staging
          - production

jobs:
  deploy:
    if: inputs.environment == 'production'
    environment: production
    steps:
      - name: Require approval
        if: inputs.environment == 'production'
        uses: hmarr/auto-approve-action@v3
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          review-delay: 5000

This ensures:

Deployments require explicit human approval
AI tools can only push to feature branches
Production deployments go through protected pipelines
No direct access to production credentials in code

Strategy 5: Local Environment Configuration

Configure your local development environment to prevent accidental production access:

# Add to your ~/.bashrc or ~/.zshrc

# Function to prevent accidental prod access
prod() {
    echo "============================================"
    echo "WARNING: You are accessing PRODUCTION"
    echo "AI tools should NEVER use this function"
    echo "============================================"
    read -p "Type 'CONFIRM' to continue: " confirmation
    if [ "$confirmation" = "CONFIRM" ]; then
        export AWS_PROFILE=prod
        echo "Production credentials loaded"
    else
        echo "Aborted"
    fi
}

# Default to dev environment
export AWS_PROFILE=dev

This creates an explicit barrier—you have to consciously choose to access production, and AI tools following your normal workflow will stay in dev.

Strategy 6: Audit Logging and Alerts

Even with all these controls, you should monitor for any attempts to access production:

{
  "AlarmName": "Production-Access-Outside-CICD",
  "AlarmDescription": "Alerts when production is accessed outside of CI/CD pipeline",
  "MetricName": "ConsoleSignIns",
  "Namespace": "AWS/CloudTrail",
  "Statistic": "Sum",
  "Period": 300,
  "EvaluationPeriods": 1,
  "Threshold": 1,
  "ComparisonOperator": "GreaterThanOrEqualToThreshold",
  "AlarmActions": ["arn:aws:sns:us-east-1:123456789:security-alerts"]
}

Set up alerts for:

Direct console logins to production accounts
API calls to production resources outside CI/CD
Any access to sensitive data stores
Changes to IAM policies or roles

Real-World Incident: A Cautionary Tale

A developer shared this experience: “Even without AI, it’s good practice to never have prod credentials for anything. The only experienced developers who have never accidentally run something in production are either lying or they at least have a friend who did so.”

Imagine that same accidental execution, but now with an AI that can process thousands of commands per minute. The potential for damage scales dramatically.

Time    | Action                | Result
--------|----------------------|------------------------
00:00   | AI reads credentials  | Production secrets exposed
00:01   | AI runs 'cleanup'     | Deletes production data
00:02   | No rollback available| Extended outage begins

Time    | Action                | Result
--------|----------------------|------------------------
00:00   | AI reads credentials  | BLOCKED: No access to prod creds
00:01   | AI tries 'cleanup'    | BLOCKED: Runs only in dev
00:02   | Developer deploys     | SAFE: Via approved pipeline

The Golden Rules

Based on the collective wisdom of experienced developers:

Never share production credentials with AI tools - This is non-negotiable
Dev and prod are different, isolated environments - Your LLM is never permitted to touch prod
Use read-only or heavily scoped IAMs - If you must give access, minimize the blast radius
Anything else is professional malpractice - These aren’t opinions, they’re requirements

Quick Reference: Security Checklist

Before giving any AI coding tool access to your systems:

[ ] Production credentials stored separately from dev credentials
[ ] AI tools have no read access to production credential files
[ ] IAM roles are read-only and scoped to specific resources
[ ] CI/CD pipeline is the only path to production deployment
[ ] Manual approval required for production changes
[ ] Audit logging enabled for all production access
[ ] Regular security reviews of AI tool permissions
[ ] No hardcoded secrets in any codebase the AI can access

Summary

Preventing AI coding tools from touching production requires discipline and proper architecture:

Complete environment isolation - Dev and prod are separate worlds
Scoped IAM roles - Read-only, minimal permissions if any access is needed
Separate credential chains - Physical separation of credential storage
CI/CD gatekeeping - All production changes through approved pipelines
Local environment safety - Explicit steps required for production access
Monitoring and alerts - Detect any unauthorized access attempts

The rule is absolute: your AI assistant works in development, not production. This isn’t about limiting AI capabilities—it’s about protecting your business from the inevitable mistakes that happen when powerful tools have unrestricted access.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!