Before You Run That AI-Generated Bash Script, Read This

The assistant writes a Bash script in twelve seconds.

The script has comments, a progress message and a final line saying “Done!”

Looks professional, mate. Unfortunately, confidence is not a permission boundary.

Before executing it, ask one question:

What can this script change, and how do I know those are the things I intended?

You don't need to distrust every AI-generated line. You need a review process that doesn't depend on the assistant sounding sensible.

1. Translate the request into a bounded task

“Clean up my server” is not a specification.

A more reviewable request would be:

List regular .log files older than 14 days inside one specified lab directory. Do not delete, upload, change ownership or follow symbolic-link directories. Print the candidates for human review.

Now you have observable boundaries. Directory, age, file type and permitted action are explicit.

This is the software equivalent of telling someone which cupboard to tidy instead of saying, “Sort the house out.” Your passport should not become collateral damage.

2. Review four things before the syntax

Target: Does the path resolve to the intended directory? Are remote host and account correct?

Authority: Which user executes the script? Can it write outside the target, access secrets or invoke privileged commands?

Inputs: Can filenames, environment variables or untrusted text alter the command's meaning?

Effects: Does it delete, install, change permissions, send data, stop services or alter databases?

A syntactically valid command can still act on the wrong environment. Shell linting cannot decide your business intent for you.

3. Begin with inspection, not modification

This Bash example only lists candidates. It assumes GNU find on a Linux lab machine:

#!/usr/bin/env bash
set -euo pipefail

TARGET=${1:?Usage: inspect-logs.sh /path/to/lab-logs}

if [[ ! -d "$TARGET" || -L "$TARGET" ]]; then
  printf '%s\n' 'Choose an existing, non-symlink lab directory.' >&2
  exit 1
fi

TARGET=$(realpath -- "$TARGET")

if [[ "$TARGET" == / ]]; then
  printf '%s\n' 'The filesystem root is not an acceptable target.' >&2
  exit 1
fi

printf 'Inspection only. Target: %q\n' "$TARGET"
find -P "$TARGET" -xdev -type f -name '*.log' -mtime +14 -print0 |
  while IFS= read -r -d '' candidate; do
    printf 'Candidate: %q\n' "$candidate"
  done

This is a review exercise, not a containment mechanism. A filesystem can change during inspection; path validation alone does not prevent races. -xdev also intentionally avoids descending into other mounted filesystems. GNU find age tests use their documented rounding rules—“older than 14 days” needs a precise definition if a retention policy depends on it.

There is no deletion step hidden at the end. Inspect first; design the mutation separately if it is actually required.

4. Check syntax and common shell mistakes

bash -n inspect-logs.sh
shellcheck inspect-logs.sh

The first checks Bash syntax without executing the script. ShellCheck can identify many common shell issues. Neither proves the script is safe or appropriate for your environment. ShellCheck project

Use a disposable directory with ordinary files, spaces in filenames, unexpected names, a symbolic link and a file that should not match. Decide the expected candidate list before running the script.

That makes the result something you can compare, rather than something you can merely admire.

5. A prompt is not a security control

An AI assistant may read logs, pages or documents containing instructions you did not author. That makes the distinction between data and instructions important. Prompt wording alone should not be your enforcement layer. OWASP prompt-injection guidance

Put limits in the execution environment: restricted credentials, bounded tools and explicit approval for consequential actions. The model proposes; the surrounding system decides what is permitted.

Also: adding sudo because a command failed is not troubleshooting. It's changing the size of the mistake you can make.

The habit worth keeping

Before execution, explain the script in your own words, identify every write or network operation, and describe how you'll verify the result.

If you cannot do that yet, ask for a smaller script or a read-only version. There is no shame in needing an explanation. The server does not award bravery points.

What is the first thing you inspect in an unfamiliar shell script: paths, privilege, network calls, quoting—or something else?

Draft prepared with AI support. The illustrative script passed Bash syntax checking and a disposable-file fixture during draft preparation. ShellCheck and author environment-specific review remain outstanding.

#Linux #Bash #AI #Security