When a staging job touches production, the first question is usually "why did the job do that?" I think the better question is "why could it?"

The answer is often boring. A production token was sitting in a file the job had no reason to read.

A hypothetical example

This is a demo scenario, not a client story.

Say a team builds an internal workflow that drafts weekly summaries of support tickets for a human to review. It runs in staging against a copy of the data. The task reads a config folder to find the staging database address.

In that same folder, someone left an old .env.backup file. It holds a production token from a migration months ago. The task is not malicious. It just loads every file in the folder, and one of them has a credential that works.

The draft goes to the wrong place, or a lookup hits the live system. Either way, the job did what its access allowed.

Why the token is the failure

The task's instructions said "staging." But instructions are not a boundary. Access is.

If a staging task can reach a production credential, then the environment split is a label, not a control. Fixing the one task does nothing. The next task that reads that folder has the same reach.

Checks for one bounded workflow

Pick a single workflow, like the ticket summary draft, and check these:

  • Search the folders it can read for credentials that are not meant for it, including backups, old exports and sample configs.
  • Give the staging job its own credentials that are valid only in staging, and confirm a production call fails.
  • Keep the first version read-only, with output going to a draft a person approves.

Make the handoff understandable

Write down, in a page or less, what the workflow can read, what it can write, and who reviews the output. Someone who did not build it should be able to read that page and find a mismatch.

Then test it. Run the staging job with a production-looking URL and see what stops it. If nothing stops it, you have learned something cheap.

None of this needs a company-wide program. Non-regulated internal work still carries privacy and security obligations, and a stray token is an easy way to miss them.

If the workflow uses MCP, the same question applies to the server's permissions: what can it reach with the credentials it was given? If it does not use MCP, the folder and the token are still the place to look.

The goal is simple. A staging task should fail loudly when it tries to touch production, because nothing it holds will work there.

I'm Jonathan Melton. I run FusionAL, focused on reviewing and integrating lower-risk internal AI workflows, one bounded workflow at a time.