## TL;DR
The agent scores its own QA traffic as fraud because test transactions are built to look suspicious. Fix: tag every test transaction at creation with an unmistakable marker and filter tagged traffic out before scoring, never inside the model. Add a pre-flight gate that refuses to start a run when untagged test traffic is detected.

```text
fraud agent flagged its own test transactions and crashed the run
```

## Use this when
- Flagged transactions trace back to your own test harness or QA team.
- A run crashes or floods alerts right after a load test or QA pass.
- Test card numbers or harness user agents appear in the flag log.

## Not for this skill when
- Real customer traffic looks odd. That is a model tuning question.
- A third party's traffic is misclassified. That is a data problem, not your harness.

## Steps
1. Confirm the cause: check whether the flagged transactions came from your own test sources. Verify: test card numbers, test emails, or harness user agents match the flagged set.
2. Tag every test transaction at creation with a dedicated marker field the scorer cannot miss. Verify: one hundred percent of harness transactions carry the tag.
3. Filter tagged transactions before scoring, not after. Verify: the scorer never sees a tagged transaction id in its input.
4. Add a pre-flight gate: the run refuses to start if it detects untagged traffic from known test sources. Verify: the gate blocks a run when the tag is missing.
5. Quarantine test traffic in a separate environment or merchant account where possible. Verify: production scoring jobs cannot see the test account at all.

## Variant phrasings
### agent flags test transactions as fraud
Common phrasing.
### synthetic traffic flagged by fraud agent
Load-test focused search.
### test card flagged in production run
Card-focused phrasing.

Compatibility: any fraud stack; the marker can be a metadata field, a dedicated test card range, or a separate account, depending on the provider.

## Why it happens
Test transactions are designed to look suspicious: odd amounts, rapid sequences, brand-new devices. That is exactly what the model is tuned to catch. Without a tag, the agent cannot tell your QA from an attack, and it is right to be confused.

## Edge cases / pitfalls
- Third-party load tools that do not tag must be routed through your harness or blocked at the edge.
- Tags that survive into the warehouse can skew training labels; strip or label them in training pipelines.
- A run that crashes on its own traffic should page the harness owner too, not just the fraud team.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_gzCV6Hl-SOW3qtSGura7TQ