The skill — skills/appsec/exploit-replica-isolation-check/SKILL.md

name: exploit-replica-isolation-check
description: >-
  Check that the environment a finding is proved in is a replica rather than
  staging — on egress, credentials, data realism and destructive probes — before
  anything is executed against it. Use before dynamic testing, exploit
  validation, or letting an agent run a proof of concept.
allowed-tools: Read, Grep, Glob, Bash

Staging is production with a different DNS name

The reason exploitation is safe is the environment, and "staging" is not that environment: it holds real credentials, real-shaped customer records, and a route to things that matter. A replica is built to be destroyed, and the four checks that distinguish them take minutes.

When to use this

Before running any probe that could change state, before pointing an agent at a target, and every time somebody offers staging because the replica is not ready.

Procedure

1 — Check egress. The environment should reach its own internal hosts and nothing else. Test the three that matter specifically: a code host, the cloud metadata address, and any private range. A replica that can reach GitHub can exfiltrate.

2 — Check credentials. Every secret in the environment should be synthetic. Grep the environment, the mounted files and the database. One real key makes the whole environment production for the purposes of this decision.

3 — Check the data. Real-shaped is not the same as real. Sample records and confirm they are generated, not copied — a customer row with a real email address is a breach waiting for a log line.

4 — Run the destructive probes. Drop a table, delete a file, exhaust a quota. In a replica these are unremarkable. If you would not do them here, this is not the environment to prove an exploit in, and that is the finding.

5 — Record the verdict per check, not overall. "Isolated: no" sends people looking; "credentials: fail, egress: pass" tells them what to fix.

Example

Input — the fixture committed at the top of scripts/exploit_replica_isolation_check.py. Edit it and re-run: the buckets, counts and verdicts below are derived from it, not hard-coded.

Output — the opening lines of a real run:

ALLOW http://replica.local/reports                   replica-internal
ALLOW http://db.replica.local:5432/                  replica-internal
DENY  https://api.github.com/                        not on the replica allowlist
DENY  http://169.254.169.254/latest/meta-data/       private address outside the replica — blocked
DENY  http://10.0.3.14:9200/_search                  private address outside the replica — blocked
probe                       on staging    on replica
--------------------------------------------------------
drop a table                   REACHES     contained

The run continues past this. test_skills.py executes the script on every build, with no model configured — so what CI proves is that it runs and refuses legibly, not that it prints these lines. The output above is a recorded run against a real model, and nothing re-diffs it: a model's answer is not reproducible, and this repository does not claim otherwise anywhere it can be checked.

Output contract

{
  "environment": "str",
  "checks": {"egress": {"pass": false, "reachable": ["str"]},
             "credentials": {"pass": false, "real_found": ["str"]},
             "data": {"pass": false, "sample_real": ["str"]},
             "destructive": {"pass": false, "refused": ["str"]}},
  "verdict": "replica|not a replica",
  "safe_to_exploit": false
}

Failure modes

• Accepting the name. "staging" and "replica" are labels; the four checks are the definition.
• Testing general egress only. The metadata address is the one that turns a probe into a credential theft.
• Skipping the destructive probes because they are destructive. That reluctance is the answer.