Uncategorized

How to Use Agentic AI Safely Without Breaking Your Website

By daniel · May 27, 2026

Agentic AI is useful because it can do more than answer questions. It can inspect files, run commands, edit code, update content, use APIs, and sometimes deploy changes. That is also why it is dangerous.

The risk is not only that the model writes bad code. The bigger risk is that it takes real actions with real permissions: overwriting content, deleting data, restoring the wrong backup, changing the wrong environment, or “fixing” one issue by breaking five others.

OpenAI describes agentic AI systems as systems that can pursue complex goals with limited direct supervision, and its governance paper emphasizes the need for safe and accountable agent operations. OpenAI: Practices for Governing Agentic AI Systems NIST’s AI Risk Management Framework also treats generative AI as a risk-management problem, not just a productivity tool. NIST: AI Risk Management Framework: Generative AI Profile

For solo builders, developers, affiliate site owners, and small teams, the practical lesson is simple:

Do not give an AI agent broad access and vague instructions. Give it a narrow mission, a safe environment, a backup requirement, stop conditions, and a verification checklist.

This article gives you a safety framework and reusable prompts for using coding agents without creating avoidable disasters.

—

The real problem: excessive agency

OWASP lists “Excessive Agency” as a major LLM application risk. The issue is not just that an AI system can make a mistake. The issue is that the system may have too much functionality, too many permissions, or too much autonomy, allowing a mistake to become an actual damaging action. OWASP GenAI: Excessive Agency

In normal software, a bug is usually constrained by the code path where it appears. With agentic AI, the “code path” can be flexible. The agent may decide to search files, rewrite a script, run a shell command, edit a database, or call a tool. If the permissions are broad and the instruction is vague, the blast radius is large.

Common failure modes include:

Editing production instead of staging
Creating duplicate content instead of updating the right item
Overwriting long-form content with a short stub
Running a full database restore to fix one broken post
Deleting files outside the intended folder
Installing unnecessary packages or plugins
Changing configuration without documenting it
Making a UI change without mobile testing
Fixing the symptom while ignoring the underlying error log
Continuing after a critical error instead of stopping

These are not “AI hallucination” problems only. They are workflow design problems.

—

The safety model: constrain, snapshot, verify, rollback

AWS’s agentic AI security guidance recommends applying standard secure development practices to agents, with extra attention to threat modeling, prompt management, access control, data governance, infrastructure security, detection, incident response, and continuity. AWS Prescriptive Guidance: Agentic AI Security

For practical web development, the agent safety model should have five layers.

1. Constrain the environment

The agent should know exactly where it is allowed to work.

Bad instruction:

Fix the site.

Better instruction:

Work only on the staging site at this specific path. Do not touch production, DNS, email, billing, users, or unrelated projects.

Always define:

project name
environment
domain
site root
allowed files or folders
forbidden systems
whether production is off-limits

The default should be staging or development. Production should require explicit permission.

—

2. Snapshot before action

A daily backup is not enough. Daily backups protect against total disaster, but they do not protect same-day content, active edits, or small mistakes.

Before an agent changes anything, require a task-specific backup:

database export before database work
file copy before editing files
content export before changing posts, pages, or CMS records
configuration dump before changing server or app settings

The backup should be easy to find and tied to the task.

Example:

“`text
/backups/pre-task/YYYYMMDD-HHMM-task-name/
database.sql.gz
changed-files.tar.gz
target-content.json
manifest.txt
“`

The manifest should include what was backed up, why, when, and from which environment.

—

3. Make destructive actions explicit

Agents should not infer permission to delete, restore, overwrite, migrate, or deploy.

A safe prompt should say:

“`text
Do not delete, restore, deploy, publish, or overwrite existing content unless explicitly instructed.
“`

For CMS work, add:

“`text
If existing content would become shorter by more than 20%, stop and ask.
“`

This single rule prevents a common catastrophe: replacing a full article with a stub, excerpt, outline, or generated placeholder.

—

4. Verify with commands, not vibes

Every agent task should end with objective verification.

For code:

syntax checks
tests
linting
git diff
git status
error logs
HTTP checks
browser checks if UI changed

For WordPress or CMS content:

post exists
slug is correct
status is correct
content length is reasonable
metadata is intact
page renders
no critical errors in logs

For server tasks:

service status
cron status
backup file exists
backup file is non-empty
archive integrity check passes
logs show success

Do not accept “done” as a final report. Require evidence.

—

5. Prefer selective recovery over full restore

A full database restore should be a last resort. If one post, page, product, or setting was damaged, restore only that item where possible.

A bad recovery plan:

Restore yesterday’s database.

A better recovery plan:

Find the damaged post, export the current state, extract the matching post and postmeta rows from backup, restore only those rows, then verify the page.

Full restores can erase newer content, users, orders, comments, analytics, and settings created after the backup. The smaller the failure, the smaller the rollback should be.

—

The agent prompt structure that actually works

A safe agent prompt should include these sections:

1. Role and project
2. Exact environment
3. Objective
4. Allowed scope
5. Forbidden actions
6. Preflight checks
7. Backup requirements
8. Implementation instructions
9. Stop conditions
10. Verification checklist
11. Final report format
12. Rollback notes

Treat prompts as operational runbooks, not casual chat messages. AWS explicitly recommends treating prompts as code artifacts in agentic AI development workflows. AWS Prescriptive Guidance: Best Practices for Development

—

Prompt 1: Safe coding task prompt

Use this when asking an agent to edit code.

“`text
You are working on a web application.

Environment:

Project: [PROJECT NAME]
Environment: STAGING/DEV ONLY
Domain: [STAGING DOMAIN]
Site/app root: [ABSOLUTE PATH]

Do not touch production unless explicitly instructed.
Do not modify DNS, billing, email, users, secrets, deployment pipelines, or unrelated projects.

Objective:
[DESCRIBE THE EXACT CHANGE]

Allowed scope:

You may inspect the app root.
You may edit only files directly required for this task.
Prefer small targeted patches over broad rewrites.

Preflight:
1. Print current directory.
2. Confirm environment/domain.
3. Run git status.
4. Identify files likely to change.
5. Inspect relevant logs if fixing an error.
6. Create a timestamped pre-task backup of every file you may edit.

Backup:

Save backups under: [BACKUP PATH]
Include a manifest with timestamp, files copied, command history, and current git status.
Stop if backup creation fails.

Implementation rules:

Make the smallest safe change.
Do not install packages unless explicitly allowed.
Do not remove existing functionality unless required.
Do not rewrite large files if a targeted patch will work.

Stop conditions:

Stop if you detect production.
Stop if the task requires credentials.
Stop if a destructive action appears necessary.
Stop if tests or syntax checks fail.
Stop if the fix requires changing files outside the allowed scope.

Verification:

Run syntax/lint checks for changed files.
Run existing tests if available.
Check application logs.
Verify the affected URL or feature.
Run git diff and git status.

Final report:

Environment confirmed
Files changed
Commands run
Backup path
Tests/checks performed
URLs tested
Git status after changes
Blockers
Rollback instructions

“`

—

Prompt 2: Safe CMS content edit prompt

Use this before letting an agent create or update posts, pages, products, reviews, documentation pages, or other CMS records.

“`text
You are working on a CMS-backed website.

Environment:

Project: [PROJECT NAME]
Environment: STAGING/DEV ONLY
CMS root: [ABSOLUTE PATH]
Domain: [DOMAIN]

Objective:
Update only the following content:

[POST/PAGE/CPT TITLE OR ID]
[POST/PAGE/CPT TITLE OR ID]

Forbidden:

Do not touch production.
Do not delete content.
Do not publish drafts unless explicitly instructed.
Do not create duplicate posts if a matching slug/title already exists.
Do not overwrite full content with a stub, outline, excerpt, or placeholder.
Do not restore the full database.

Preflight:
1. Confirm site URL and environment.
2. Search for existing content by title and slug.
3. Record each target item’s ID, title, slug, status, type, modified date, and content byte size.
4. Export each target item and its metadata to a timestamped backup folder.
5. Save a manifest.

Content safety rule:

If an existing item has more than 500 bytes of content and the new version is shorter by more than 20%, stop and ask.
If the target item already exists, update that item. Do not create a duplicate.
If there is ambiguity between two similar items, stop and ask.

Implementation:

Make only the requested content changes.
Preserve existing metadata unless explicitly instructed.
Preserve slugs unless explicitly instructed.
Preserve affiliate links, canonical URLs, schema, categories, tags, and status unless explicitly instructed.

Verification:

Confirm the target item exists.
Confirm title, slug, status, and type.
Confirm content byte size did not unexpectedly shrink.
Confirm the public/staging URL renders.
Check logs for errors.

Final report:

Items found
Items backed up
Backup path
Items changed
Content size before/after
URLs tested
Any skipped or ambiguous items
Rollback notes

“`

—

Prompt 3: Safe backup system prompt

Use this when asking an agent to improve backups.

“`text
You are improving the backup system for a web application.

Environment:

Project: [PROJECT NAME]
Environment: STAGING/DEV FIRST
App root: [ABSOLUTE PATH]
Backup root: [ABSOLUTE PATH]

Objective:
Create a layered backup workflow that protects against:

server failure
bad code edits
accidental content overwrite
database mistakes
same-day work loss

Forbidden:

Do not restore any database.
Do not delete existing backups.
Do not modify production.
Do not modify DNS, SSL, email, billing, or users.
Do not overwrite existing backup scripts without copying them first.

Preflight:
1. Confirm app root and environment.
2. List current backup scripts.
3. List current cron jobs.
4. List existing backup folders.
5. Create a pre-change backup folder.
6. Export the current database before changing backup scripts.
7. Copy existing backup scripts into the pre-change folder.

Implementation:
Create:
1. Hourly database backup script
2. Content transaction backup helper
3. Backup healthcheck script
4. Cron job for hourly backups
5. Documentation explaining restore policy

Requirements:

Hourly DB backups should be compressed.
Backup files must be integrity-checked.
Retention must only delete matching backup files in the intended backup folder.
Healthcheck must fail if the latest backup is missing, empty, corrupt, or too old.
Content backup helper must export target content and metadata before editing.

Restore policy:

Full database restore is last resort.
Prefer selective restore for isolated content loss.
Never restore without explicit instruction.

Verification:

Run shell syntax checks.
Run backup script manually once.
Run healthcheck manually once.
Confirm latest backup file exists and is non-empty.
Confirm compressed backup passes integrity check.
Show created cron entries.

Final report:

Files created/changed
Cron entries added
Backup folder created
Latest backup file and size
Healthcheck result
Commands run
Rollback notes

“`

—

Prompt 4: Safe incident recovery prompt

Use this after an agent breaks something.

“`text
You are investigating a recent site/application breakage.

Objective:
Find the cause and propose the smallest safe recovery. Do not make changes until the cause is identified.

Forbidden:

Do not restore the full database.
Do not delete files.
Do not overwrite files.
Do not deploy.
Do not clear all caches as a substitute for diagnosis.
Do not continue feature work until site health is restored.

Triage:
1. Confirm environment.
2. Record current git status.
3. Record current time.
4. Check application error logs.
5. Check web server logs if relevant.
6. Identify recently modified files.
7. Identify recently modified content records if CMS-backed.
8. Check whether backups exist.
9. Create a current-state backup before any recovery attempt.

Diagnosis:

Identify the exact failing URL, command, feature, or file.
Identify the exact error message.
Identify the smallest likely cause.
Identify whether the issue is code, content, database, cache, config, or external service.

Recovery plan:

Propose the smallest safe rollback.
Prefer reverting one file or one content record.
Prefer selective database row recovery over full database restore.
Explain what data could be lost before any restore.

Stop and ask before:

restoring a database
deleting anything
changing production
disabling security plugins
changing DNS or SSL
touching user/customer/order data

Final report:

Root cause
Evidence
Recommended fix
Backup state
Risk of data loss
Exact commands proposed

“`

—

Prompt 5: Safe UI change prompt

Use this when asking an agent to fix layout, styling, cards, navigation, headers, or mobile issues.

“`text
You are making a UI change on a staging site.

Environment:

Project: [PROJECT NAME]
Environment: STAGING/DEV ONLY
URL(s): [URL LIST]
Theme/app root: [ABSOLUTE PATH]

Objective:
[DESCRIBE UI CHANGE]

Allowed scope:

CSS and template files directly related to this component.
No unrelated redesign.
No content strategy changes.
No production changes.

Preflight:
1. Confirm environment.
2. Run git status.
3. Identify the component/template responsible.
4. Back up files before editing.
5. Take or record baseline screenshots if browser tools are available.

Implementation:

Make the smallest targeted change.
Preserve existing desktop/mobile behavior unless the task says otherwise.
Avoid global CSS rules unless necessary.
Do not change unrelated components.

Verification:

Test desktop width.
Test mobile width.
Test at least one page where the component appears.
Check for overflow, broken wrapping, missing buttons, contrast issues, and layout shifts.
Check logs if templates changed.
Run syntax checks if PHP/JS changed.

Final report:

Files changed
URLs tested
Desktop result
Mobile result
Screenshots or observations
Commands run
Git status
Rollback notes

“`

—

Prompt 6: Safe production deployment prompt

Use this only when production deployment is actually intended.

“`text
You are preparing a production deployment.

Production changes are allowed only for the exact scope below.

Project:

[PROJECT NAME]

Staging source:

[STAGING DOMAIN]
[STAGING ROOT]

Production target:

[PRODUCTION DOMAIN]
[PRODUCTION ROOT]

Objective:
Deploy only the already-tested changes from staging to production.

Forbidden:

Do not make new feature changes directly on production.
Do not change DNS, email, SSL, users, billing, or unrelated projects.
Do not run full database restore.
Do not overwrite production uploads or content unless explicitly instructed.
Do not deploy if staging has uncommitted or unverified changes.

Preflight:
1. Confirm staging and production roots.
2. Confirm production domain.
3. Run git status on staging and production.
4. Confirm exact files to deploy.
5. Create production pre-deploy backup:
– database export
– changed files backup
– manifest
6. Stop if backup fails.

Deployment:

Copy only approved files.
Do not copy wp-config, uploads, cache, or environment-specific files unless explicitly instructed.
Preserve file ownership and permissions.

Verification:

Run syntax checks.
Check production homepage.
Check affected production URLs.
Check logs.
Confirm no critical errors.
Confirm git status.

Rollback:

Document exact rollback commands.
Keep pre-deploy backup path visible.

Final report:

Files deployed
Backup path
Commands run
Production URLs tested
Errors found
Rollback instructions

“`

—

Practical rules for humans using AI agents

A good agent prompt is not enough. The human operator also needs rules.

Rule 1: Never start with production

Even if the change looks simple, staging should be the default. Production is where verified changes go, not where agents experiment.

Rule 2: Never let the agent “figure out” the scope

Agents are good at filling gaps. That is useful for writing and debugging, but dangerous for operations. Give exact paths, domains, and allowed files.

Rule 3: Never accept a backup claim without a path

“Backup created” is not enough. Require the exact file path, file size, timestamp, and verification result.

Rule 4: Never let a full restore be the first fix

Full restores are blunt instruments. They can erase newer work. Use selective recovery first.

Rule 5: Never ignore content size

For CMS websites, content length is a simple but powerful safety check. If a 3,000-word article becomes 200 bytes, the agent should stop.

Rule 6: Never mix projects

If one workspace contains multiple sites, brands, repositories, or clients, every prompt should explicitly identify the target project and forbid cross-project changes.

Rule 7: Never skip the final report

The report is not admin overhead. It is your audit trail. Without it, you do not know what changed, what was tested, or how to roll back.

—

Minimum safe agent prompt

If you do not want to write a long prompt every time, use this minimum version:

“`text
Work only on [PROJECT] in [DEV/STAGING ENVIRONMENT] at [EXACT PATH].

Objective:
[ONE CLEAR TASK]

Before changing anything:

confirm current directory and site/app URL
run git status
identify files/content that may change
create a timestamped backup of anything you will edit
stop if backup fails

Rules:

do not touch production
do not delete anything
do not restore any database
do not modify unrelated files
do not install packages/plugins unless explicitly allowed
if existing content would shrink by more than 20%, stop and ask

After changes:

run syntax/tests/checks
verify affected URL/feature
check logs
show git diff summary and git status

Final report:

files changed
commands run
backup path
checks performed
URLs tested
blockers
rollback notes

“`

—

Final verdict

Agentic AI is not unsafe by default. Unscoped agentic AI is unsafe.

The difference between a useful AI coding assistant and a disaster machine is usually not the model. It is the operating system around the model: permissions, backups, prompts, logs, verification, and rollback discipline.

Use agents like junior operators with superhuman speed:

give them narrow access
make them prove where they are
force them to back up before acting
forbid destructive shortcuts
require verification
make them report everything

The goal is not to stop using agentic AI. The goal is to make it boringly recoverable when it makes a mistake.

—