# Sample readiness review: outbound support replies

**MERCY KEY · synthetic demonstration v1.1 · September 4, 2026**

This AI-assisted educational sample shows how an operational finding connects to a concrete control and reproducible evidence. It is not a client case study. No live model, customer system, credential, payment, or email service was used by the fixture. AI tools assisted in writing and reviewing this report and code; no independent human audit is claimed.

## Decision

**Local control demonstration passes; production readiness is not established.**

The fixture prevents an unapproved outbound reply from entering its mock queue in the tested cases. Fifteen checks passed on the version accompanying this report. These results establish only the tested behavior of this single-process fixture. Before deploying the pattern, a real system needs authenticated reviewer identity, durable atomic state, enforcement on every send path, and provider-specific recovery tests.

## Scope and authority

Scenario: an AI support workflow proposes a reply for one customer ticket. A human reviews the exact message. A worker later attempts delivery.

| Actor | Allowed action | Boundary |
|---|---|---|
| Model-visible proposal tool | Propose one reply | Cannot create reviewer approvals; tenant and ticket must match trusted records |
| Trusted reviewer surface | Approve exact content for 60 seconds | Approval binds action ID, tenant, ticket, recipient, subject, and body |
| Queue worker | Deliver approved queued content | Checks pause state before processing; retains unknown outcomes for reconciliation |
| Mock transport | Append a reply to a local array | Makes zero external calls |

All names and addresses are synthetic. The fixture fixes the agent identity and ticket ownership inside the trusted test boundary. It does not authenticate a real user or obtain those records from an application database.

## Material findings and verification

### F01 — An approval must identify the exact action

A generic “approved” flag permits content or destination changes after review. In the fixture, an approval token is generated outside the model-facing tool and bound to the action's full field set. A changed body invalidates it; expired approvals are denied; recipient and tenant checks operate independently of the token. Relevant evidence: T02–T06.

**Production requirement:** authenticate the reviewer, scope the approval API to that reviewer, bind a canonical payload and version, and consume the approval atomically with queue creation. The in-memory map in this sample is not a substitute for that implementation.

### F02 — A timeout must not become a duplicate send

The fixture delivers a mock message, loses the acknowledgement, and records an unknown result. Repeating the same action does not deliver a second message. The unknown state remains unresolved until an operator or integration can reconcile it. Relevant evidence: T07, T08, T11.

**Production requirement:** use durable idempotency records and provider-supported deduplication when available. Test concurrent workers, crash recovery, retention expiry, and a provider that cannot confirm whether a request succeeded. The sample does not prove exactly-once delivery across systems.

### F03 — Stopping proposals does not stop queued actions

The pause control is checked at proposal time and again before the mock worker processes queued work. A queued reply remains unsent after pause. Relevant evidence: T09.

**Production requirement:** inventory all queue consumers, schedulers, retries, and restart paths. An in-flight external request may already have taken effect when pause is triggered. This synchronous fixture cannot cancel that request or prove distributed containment.

### F04 — Mutable payloads and verbose logs create secondary exposure

The input is copied and frozen before validation or approval hashing. Those checks and queue insertion use the same snapshot. Changing the caller's object or returning different text from a JavaScript getter cannot swap queued content in the tested cases. Audit events use independently generated identifiers and state transitions, not model-provided action IDs. The tested body, recipient and sensitive ID values do not appear in those audit events. Relevant evidence: T10, T12, T14 and T15.

An adversarial review of v1 exposed two gaps despite its 13 passing tests: a getter could change the body between validation and copying, and a model-provided ID could copy sensitive text into audit. Version 1.1 fixes these and adds reproductions. The getter issue concerns the JavaScript function boundary; a JSON request cannot directly carry an accessor. This finding is not evidence of compromise in a real customer system.

**Production requirement:** define retention and access for full evidence separately. Redacting a short audit event does not establish that application traces, providers, crash dumps, or other logs avoid sensitive data.

## Reproduce

With Node.js 22 or later, run from the repository root:

```sh
node services/sample-review/outbound-boundary-demo.mjs
```

If using the script as a standalone attachment, run `node outbound-boundary-demo.mjs`. It uses only Node built-ins and has no installation step. The JSON output includes every result and returns a nonzero exit code if any check fails.

| Evidence | Expected behavior | Observed |
|---|---|---|
| T01 | Exact approved reply is delivered once | Pass |
| T02 | Model-authored approval text grants no authority | Pass |
| T03 | Changed recipient is denied | Pass |
| T04 | Cross-tenant action is denied | Pass |
| T05 | Changed body invalidates approval | Pass |
| T06 | Approval expires at the boundary | Pass |
| T07 | Repeated action does not duplicate delivery | Pass |
| T08 | Same ID with changed content is rejected | Pass |
| T09 | Pause blocks queued and new work | Pass |
| T10 | Caller mutation cannot alter queued content | Pass |
| T11 | Lost acknowledgement remains unknown without automatic retry | Pass |
| T12 | Audit events omit message body and recipient | Pass |
| T13 | Malformed payloads and extra flags are rejected | Pass |
| T14 | A changing getter cannot replace approved content during queue insertion | Pass |
| T15 | Sensitive model-provided IDs do not enter audit events | Pass |

## What remains untested

Model behavior, real prompt-injection resistance, retrieval isolation, data-leak detection, authentication, credential lifecycle, durable storage, multi-worker races, provider integration, incident ownership, and customer recovery are not evaluated here. A model that produces an unauthorized proposal can still behave undesirably; this fixture only checks whether a particular proposed side effect is accepted by a wrapper.

## Basis

The use of narrow tools, downstream authorization, and approval for consequential actions is consistent with [OWASP Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/). [OWASP Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) explains why content entering a model can alter its behavior. The implementation and test cases here are original examples, not an OWASP certification or endorsement.

A paid readiness review applies an evidence-to-finding-to-verification process to the customer's agreed workflow. This sample makes no claim of completed customer work or customer revenue.

## Discuss your workflow

The [MERCY KEY readiness review](https://mercy-key.codex507411.chatgpt.site/readiness-review#request-review) starts with a minimal inquiry, not payment. The US$950 review covers one workflow and up to three connected tools; evidence, scope, timing, and payment must be agreed in writing before work begins. Do not submit production credentials or customer data through the inquiry form.

This free demonstration is separate from the US$19 AI Incident Field Manual license. Downloading or running it requires no purchase.