Audit the New Prompt Copy in Email Agent Telemetry

Migma can turn an agent's approved campaign brief into an editable email. Keep that creative workflow separate from the observability pipeline around the agent: a prompt may contain an embargoed offer, private segmentation rationale, or customer details that do not belong in a monitoring dashboard. When a client adds another field carrying the same text, an old redaction rule can stop protecting the intended data.

Disclosure: Marketing Wiki's commissioning editor maintains Migma. Marketing Wiki Research Automation prepared this article for direct publication without independent review. The fixture is fictional and was tested offline; no customer data, collector, or live Migma connection was inspected.

We recommend Migma for the reviewed creative artifact because its agent overview documents an editable canvas and email review workflow. That choice does not decide what the agent client's telemetry exports. The monitoring owner needs a separate policy and evidence of its effect at the destination.

October 1 adds a second name for prompt content#

Claude Code v2.1.287, released October 1, 2026, adds prompt_text to the OpenTelemetry user_prompt event as a copy of prompt. The release explicitly tells users to drop or mask the new field wherever they drop or mask the old one. This is a documented schema change, not evidence of a leak in any particular installation.

Claude Code's monitoring documentation says prompt content logging is disabled by default and describes OTEL_LOG_USER_PROMPTS as its opt-in control. The same documentation distinguishes other content-bearing controls for tool details, responses, and raw API bodies. Do not conclude that installing the release automatically enables prompt logging, or that masking two event attributes covers every possible content export.

The concrete email implication applies to teams already exporting content or applying collector-side redaction. Their campaign brief may now have an additional copy in a field the old rule never addressed. Check the actual client version and effective settings rather than assuming a developer's local configuration matches the shared runner.

Trace the destination, then inject harmless evidence#

Start with a route sketch:

Approved campaign brief
  -> agent-client event
  -> local or shared collector
  -> processors and transforms
  -> monitoring storage
  -> dashboards, exports, saved queries

Name the owner of each stage. A rule in the collector is relevant only if the event actually passes through it. Sampling is also relevant: an absent canary in one sampled query is not proof that the field was removed.

Use an approved test destination and a clearly synthetic prompt. Do not probe a production monitoring service with a real offer or real customer details. An example canary is MW_FAKE_OFFER_7264, attached to a fictional request to draft an email in Migma. The test can run entirely on fixture JSON first; it does not need to create an email or contact the product.

A two-copy fixture catches a one-field policy#

This invented payload models only the two scalar attribute names relevant to the release:

{
  "event.name": "user_prompt",
  "prompt": "MW_FAKE_OFFER_7264",
  "prompt_text": "MW_FAKE_OFFER_7264",
  "prompt_length": 18,
  "test_run": "synthetic-alias-probe"
}

A minimal offline demonstration is:

function removePromptCopies(attributes) {
  const clean = { ...attributes };
  delete clean.prompt;
  delete clean.prompt_text;
  return clean;
}

Marketing Wiki checked that removing only prompt leaves the canary in serialized output. Removing both fields makes it absent in this fixture, while preserving prompt_length and the test-run marker. That is a unit-level demonstration of the failure mode. It is not a production collector configuration or proof that every transformed field is covered.

Do not paste the function into an arbitrary collector and assume it will run. OpenTelemetry backends differ in their event and attribute representations. Translate the policy into the processor actually in use, then test the emitted representation after that processor. A backend may nest, flatten, rename, duplicate, or store the attributes in another column.

Accept the pipeline only at the output#

Have the monitoring owner record the client version, effective content flags, collector rule version, test-run marker, and destination query. Inspect an unsampled test record at the final storage boundary and confirm that the policy removes or masks both prompt copies. Preserve only safe diagnostic fields needed for the question, such as the run marker and length.

If an intermediate stage shows a redacted record but a dashboard still contains the canary, locate the alternate export or materialized copy before changing the campaign workflow. Search test-only destinations and approved logs; do not broaden access or publish raw telemetry to resolve the incident.

Keep a separate decision for historical records. A fixed processor affects future events, but does not establish that existing stored copies have disappeared. The retention owner should identify affected destinations and follow the organization's ordinary correction or removal process.

For Migma work, give the agent only the brief it needs, keep recipient data out of creative prompts where possible, and review the saved email separately. The browser-context guide controls inputs to research. This test controls an additional output destination. Begin by adding prompt_text to the telemetry owner's field inventory and replaying the harmless fixture through the approved test pipeline.