This document defines the security rules engineers must follow when using AI agents — not just AI assistants — in client work. Read it before starting any agentic workflow on a project.

An AI assistant waits for you and responds. An AI agent acts: it reads files, writes code, runs commands, calls APIs, and makes commits — sometimes in a chain, without waiting for you to approve each step.

That autonomy is powerful, but it introduces risks that don't exist with a passive assistant. This document defines the guardrails that keep those risks from becoming client incidents.

These rules have no exceptions. If a situation makes one of these hard to follow, stop and ask in #engineers before proceeding.

Agents operate in dev or staging environments only. No production database credentials, no production SSH keys, no production Pantheon/Acquia/Platform.sh environments in an agentic session.

This includes:

• .env files containing prod credentials
• SSH config entries that point to prod
• Drush aliases targeting @prod or @live
• Admin credentials to client production CMS instances

Agents read everything in their working directory and everything you paste into the prompt. Before starting an agentic session:

• Confirm your .env file is gitignored and not being passed to the agent explicitly
• Do not paste API keys, passwords, or tokens into the prompt
• Do not ask the agent to read a file that contains secrets
• Use environment variable references ($DATABASE_URL) rather than inline values when writing config

If an agent needs to call an external API during a session, use a development/sandbox key, never a production key.

An agent must not autonomously execute the following without explicit human confirmation in the same session:

• Any drush sql-drop, drush sql-sanitize, or database-altering command
• Any deletion of files outside the working repo
• Any git push to a shared branch (main, develop, staging)
• Any deployment command
• Any operation that writes to a client's environment

If you are using Claude Code or a similar tool that supports confirmation steps, configure it to pause before these operations. Do not disable that behavior.

Client data includes: user PII, form submissions, database exports, analytics data, CRM records, or any content covered by an NDA or data processing agreement.

Before using real client data in an agentic session:

• Check the client's contract and DPA (Data Processing Agreement)
• If uncertain, sanitize or anonymize the data first
• When in doubt, use synthetic/seed data instead

HIPAA-adjacent projects (healthcare clients) require explicit lead review before any data is used in AI context.

Keep agent access as narrow as possible for the task at hand.

• File system: Point the agent at the repo root only. Avoid giving it access to parent directories that contain other project credentials or config.
• Drush: Only run drush commands against local or dev environments. Confirm the active environment with drush status at the start of a session.
• Git: Prefer committing to feature branches. Avoid giving an agent write access to protected branches.
• MCP servers: If using MCP tool integrations (e.g., GitHub MCP, Pantheon MCP), only connect to the project-relevant workspace. Disconnect when the session is done.

If an agent executes an unintended action — commits to the wrong branch, touches a file it shouldn't have, or you suspect credentials were exposed:

1. Stop the session immediately
2. Assess what was done (check git log, shell history, network calls if visible)
3. Rotate any credentials that may have been in context
4. Notify your project lead and #engineers the same day
5. Document what happened in the project's incident log

Do not wait to see if the problem surfaces on its own.

Four Kitchens provides company accounts for a set of AI platforms — use those for client work whenever possible. Engineers are also free to use other AI tools paid for out of pocket, as long as those tools are subject to the same rules in this document.

There is no approved/unapproved list by tool name. The line is the rules themselves: any platform you use for agentic work on client projects must be one you can operate within these guidelines. If you are unsure whether a tool can meet them (e.g., unclear data retention policies, no way to limit scope), ask in #engineers before using it on a project.

A practical pre-flight checklist for starting an agentic session:

• I am connected to a dev or staging environment, not production
• My .env contains no production credentials
• I have not pasted any secrets into the agent prompt
• No client PII or sensitive data is in the working directory or prompt context
• I know what drush alias is active (drush status)
• I will review diffs before any commit is pushed to a shared branch
• I have not disabled confirmation prompts for destructive operations

This is a living document. If you hit a scenario these guidelines don't cover, or if a rule feels wrong for a specific situation, raise it in #engineers. Updates go through a PR to this repo.

Owner: Engineering team Last reviewed: May 2026