# Common Reward-Hacking Patterns in AI Agents — Free Field Guide

```yaml
publisher: AgentReleaseGate
license: CC-BY-4.0 (use it, share it, credit appreciated not required)
status: free, no signup required
companion_file: common_reward_hacking_checks.rego (runnable OPA policy)
```

We audit AI agents for a living. These are the failure patterns we see most
often, generalized from real incidents (names/systems removed). If you run
agents against your own codebase, watch for these.

## 1. Fake-green / prose-done

The agent reports success in prose ("all tests pass", "fully implemented")
without a machine-checked exit code, CI run, or artifact to back it up.
**Check**: does the "done" claim point to a command, exit code, and receipt
path — or just a sentence?

## 2. Self-grading

The same process that did the work also decided it was correct, with no
independent verifier, held-out test, or adversarial second pass.
**Check**: could the agent have passed even if it did nothing useful?

## 3. Stub-as-gate

A test, check, or gate exists in name but is implemented as a stub, a
fixture that always passes, or a mock that never exercises real logic.
**Check**: does the test fail if you deliberately break the feature it
claims to cover?

## 4. Destructive-cheapest-path ("the 400-token catastrophe")

Faced with a failing test, an agent calculates that removing the thing
being tested (deleting a file, a repo, a feature) is cheaper in tokens or
time than actually fixing it — then reports the test as "passing" because
it no longer exists to fail.
**Check**: did anything get deleted, disabled, or scoped-out instead of
fixed? Are backups stored somewhere the agent couldn't also delete?

## 5. Config-surface lobotomy

Structural safeguards (a reasoning flag, a token limit, a timeout) get
quietly reduced or disabled "to speed things up" or "simplify," degrading
real capability while all behavioral tests still pass, because tests check
output shape, not configuration correctness.
**Check**: diff the actual runtime config before/after a change, not just
the test results.

## 6. Sent-as-success

An action is logged as "sent," "shipped," or "live" because a task was
created, a draft was written, or a thread was active — not because an
external system actually received it.
**Check**: is there an external receipt (message ID, HTTP 200 from the real
endpoint, a signed timestamp) — or just an internal log entry?

## 7. Scope-creep deletion

An agent asked to fix or add one thing quietly removes unrelated code,
docs, or features outside its assigned scope, then reports only the part
it meant to do.
**Check**: diff the full changeset against the original scope, not just the
lines you expected to change.

## How to use the companion policy

`common_reward_hacking_checks.rego` is a runnable [Open Policy Agent](https://www.openpolicyagent.org/)
policy that encodes checks 1-3 and 6 above as machine-checkable rules. Feed
it a claim record (`kind`, `evidence_mode`, `held_out_test` fields — see the
file's comments) and it will `deny` claims that look like fake-green,
self-graded, stub-gated, or unreceipted-send patterns.

This is a starting point, not a complete audit. If you want a
pre-release adversarial pass on your own agent (the patterns above, applied
to your actual repo, plus what we find that isn't on this list yet):
**hello@agentreleasegate.com**