🔐 AI-Assisted Secret Handling in Bash and Python Automation

Ask an AI to “write a script that calls the Stripe API” and watch what it does with the key. More often than not it generates API_KEY = "sk_live_..." right in the source, or accepts the token as a command-line flag, or — my favorite — logs the full request including the Authorization header. AI is a fast junior engineer, and secret handling is exactly the kind of security nuance a junior gets wrong by default. This is the area where reviewing every line before it runs on prod, and never handing the AI a real secret, matters most.

The cardinal rule: the AI never sees a real secret

Before anything else: when you share a script with an AI for review or extension, scrub every credential to a placeholder first. sk_live_abc123 becomes __STRIPE_KEY__. Real hostnames become __DB_HOST__. The AI can design correct secret handling from placeholders alone — it never needs the real value, and pasting one into a chat means it now lives in a transcript you don’t control.

This isn’t paranoia; it’s the same boundary you’d keep with any external contractor. You give a junior the architecture, not the production vault. The whole bash and Python automation category assumes this discipline.

Reject hardcoded secrets in the prompt

I state it explicitly: “Never hardcode credentials. Read all secrets from the environment or a secrets manager.” Even then I review, because the AI sometimes leaves a “default” fallback that’s a real-looking placeholder.

import os

api_key = os.environ.get("STRIPE_API_KEY")
if not api_key:
    raise SystemExit("error: STRIPE_API_KEY is not set")

Fail fast and loud when the secret is missing. The AI’s first draft often does os.environ.get("STRIPE_API_KEY", "") and then proceeds with an empty key, producing a confusing auth error downstream. I always change the default-empty pattern to an explicit check. This pairs with Python config management using pydantic and env vars for validating required secrets at startup.

Keep secrets off the command line

A --token flag leaks into ps, shell history, and process listings. In bash the safe pattern is reading from the environment or stdin, never an argument.

: "${GITHUB_TOKEN:?GITHUB_TOKEN must be set}"

curl -fsS -H "Authorization: Bearer $GITHUB_TOKEN" \
     https://api.github.com/user

The :? parameter expansion aborts with a message if the variable is unset. The AI will happily generate --token "$1" if you don’t forbid it — I tell it “secrets come from the environment, never as positional or flag arguments,” and then check the result.

Pro Tip: search the AI’s output for the literal strings password, token, secret, key, and Bearer followed by anything that isn’t a variable reference. A quick grep -iE '(password|token|secret|api[_-]?key)\s*=\s*["'\'']' script.py catches the hardcoded-credential pattern before it reaches a commit.

Pull from a real secrets manager

For production, environment variables are a floor, not a ceiling. The AI can wire up a secrets manager cleanly when asked — it just won’t volunteer it.

import boto3

def get_secret(name):
    client = boto3.client("secretsmanager")
    resp = client.get_secret_value(SecretId=name)
    return resp["SecretString"]

db_password = get_secret("prod/app/db_password")

I review the IAM scope this implies — the AI doesn’t reason about least privilege unless prompted, and its example policies tend to grant secretsmanager:* on *. The boto3 guide covers the credential chain so you’re not passing keys around at all.

Never log the secret

The sneakiest leak is logging. Debug logging that dumps a request object, a full URL with a token query param, or an exception that includes the auth header — all of these write secrets to disk where they’re searchable forever. I prompt: “Ensure no secret is ever written to logs, including in error messages and request dumps.”

def redact(value, keep=4):
    if not value:
        return value
    return value[:keep] + "…" + "[redacted]"

log.info("authenticating with key %s", redact(api_key))

The AI writes redaction helpers well, but its default logging is dangerous — I’ve seen it generate log.debug("request: %s", request.__dict__) which dumps headers and all. Review every log line that touches a request or credential. Structured logging makes redaction enforceable — see structured logging in bash and Python.

Avoid secrets in temp files and subprocess args

Two more leak paths the AI overlooks. Writing a secret to a temp file leaves it on disk; passing it as a subprocess argument exposes it in the process table. For subprocesses, pass secrets via the environment of the child, not as an argument.

import subprocess, os

env = {**os.environ, "VAULT_TOKEN": token}
subprocess.run(["vault", "kv", "get", "secret/app"], env=env, check=True)

The token rides in the child’s environment, invisible to ps. The AI’s instinct is subprocess.run(["vault", "login", token]), which exposes it. I correct this every time it comes up.

Verify before it ships

Before any secret-handling script runs on prod, I run it through review — both my own read and the code review dashboard, which flags hardcoded credentials and risky logging via its static pre-scan and risk floor. For broader secret-safety patterns in AI-generated shell, see securing AI-generated bash scripts and using AI safely with bash.

Conclusion

Secret handling is where the fast-junior-engineer framing earns its keep. The AI hardcodes keys, accepts them as flags, logs them in request dumps, and grants wildcard IAM — every default it reaches for is the insecure one. Scrub secrets to placeholders before sharing, forbid hardcoding and flag-passing in the prompt, pull from a real secrets manager with scoped access, redact every log line, and keep credentials out of temp files and process args. Then review every line, because this is the one area where a single missed default ends up in a breach report. Never hand the AI a real secret. Reusable secret-safety prompts are in the prompts library and the prompt packs.