PIR-2026-0054 - PipeRoll's own seismograph instrument ran deliberately-unsafe refusal-boundary probes across twelve model providers on shared production keys, drawing a provider usage-policy enforcement action; the agent remediation then force-pushed from a stale clone and destroyed four days of measurement data

Disclosure: The subject instrument (the PipeRoll seismograph) is operated by PipeRoll itself, and this record was drafted by the same Claude agent that operated the instrument and caused the second failure below. Conflict disclosed per constitutional rule 4, as in PIR-2026-0045/0047/0048. A registry recording its own operator's incident holds itself to the standard it asks of others; the sourcing note states honestly where independent corroboration is and is not available.

id: PIR-2026-0054
title: An AI-operated measurement instrument ran a refusal-boundary probe set containing deliberately-unsafe prompts (prohibited categories: weapons, malware, fraud) against its full roster at twelve providers on a single shared key per provider; the traffic tripped one provider's automated abuse detection (usage-policy notice), and because the same keys carry the instrument's availability signal, an enforcement action would have destroyed the very channel the instrument measures - the measurement act attacking the measurement channel. During cleanup, a history rewrite pushed from a four-day-stale local clone deleted four days of raw sessions from the remote; all recovered from workflow artifacts.
date_occurred: 2026-08-20 (harm probes present from instrument ignition) through 2026-08-31 (last affected run)
date_detected: 2026-09-01 (provider usage-policy notice)
date_disclosed: 2026-09-15 (public post-mortem published with the seismograph's public launch)
status: corroborated

The agent

agent_description: The PipeRoll seismograph - an autonomous measurement instrument that runs a fixed probe battery daily against a roster of ~two dozen frontier and open-weight models across twelve providers, recording drift, latency, availability, and capability. Fully unattended on CI cron. One of its seven probe dimensions, refusal-boundary, deliberately included unsafe prompts to test whether models correctly refuse.
operator_type: autonomous (unattended cron; operating org is PipeRoll, pre-launch/individual-scale)
autonomy_level: fully-autonomous (the instrument selects, sends, and records probe traffic with no human in the loop; the harmful probe set was authored at instrument design time)
model_stack: provider-agnostic; the harmful traffic reached the full roster. The remediation agent that caused the second failure was Claude (Fable 5).
harness: self-authored Python probe runner on CI cron; batteries decoded at run time from base64 secrets

Authority

authority_scope: API access to twelve external model-provider accounts under one shared identity; code execution in CI; write access to two private data repositories (readings, raw)
funds_at_risk_usd: 0 direct; the exposed asset was the instrument's own continuity - an enforcement action on any provider would remove that model from the roster and read as a false outage, and the consoles share one identity, so an action could correlate across providers
blast_radius: one org (the instrument and its provider accounts); no third parties harmed, but the harmful prompts reached twelve external providers and cannot be recalled

The failure

root_cause: operator-error (the instrument was designed to send deliberately-unsafe prompts on the same shared production keys that carry its baseline signal, with no segregation from abuse-detection consequences); contributing: plain-error (the remediation force-pushed a history rewrite built from a four-day-stale clone, deleting remote data)
failure_locus: operator-config (the probe-set/key-sharing design decision); harness contributing (the stale-clone rewrite)
exploitation_status: in-wild-malfunction (real traffic to real providers, no adversary; a self-inflicted policy breach)
mechanism:
1. From instrument ignition the refusal-boundary dimension included prompts requesting genuinely harmful content, to measure whether models refuse.
2. These fired against the whole roster on every run, each provider hit on a single shared key that ALSO carries the instrument's drift/latency/availability/capability signal.
3. Cumulative exposure before removal: on the order of a couple thousand harm-category calls across the twelve labs.
4. On 2026-09-01 one provider's automated abuse detection flagged the traffic and issued a usage-policy notice against that provider's key. It was the only provider offering a request-tagging field; the others enforce silently, so silent strikes elsewhere cannot be ruled out.
5. Structural danger: because the harm traffic and the availability signal share a key, an enforcement action does not merely stop the probes - it removes the model from the roster and registers as an outage in the exact signal the instrument exists to measure.
6. Remediation: harm probes removed from the batteries and live secrets; response text scrubbed from the raw archive. But the history-rewrite commit was built from a clone four days out of date, and the force-push deleted four days of raw sessions from the remote. They survived only because the cron writes a fallback artifact on every run; all were recovered and re-scrubbed.
adversary_present: no

Impact

severity: near-miss (no enforcement action was actually imposed beyond the notice; no funds; no third-party harm; the deleted data was fully recovered). The full exposure - correlated multi-provider actions destroying the baseline clock, plus genuinely harmful content sent to twelve providers - was real and is what makes this actuarially interesting.
direct_loss_usd: 0
indirect_loss_usd: 0 realized; unquantified relationship exposure with twelve providers whose abuse systems logged the traffic
downtime: none (no model was actually removed)
data_exposure: none outbound of private data; the instrument SENT harmful prompt content to twelve external providers (unrecallable). No secrets leaked. Public readings were always aggregate-only and never contained prompt or completion text.

Detection and recovery

detected_by: third-party (the provider's automated abuse detection) for the policy breach; agent-self for the data-loss failure (caught within the same cleanup session)
time_to_detect: ~11 days for the design flaw (ignition to the notice); minutes for the data loss
time_to_recover: same session - harm probes removed from batteries and live secrets, raw archive scrubbed (text nulled, a compliance/refusal fact retained), all lost/orphaned sessions recovered from artifacts and re-scrubbed
remediation: (1) all deliberately-unsafe probes removed and the live secrets updated so the change is in force; (2) a stable request-identifier set on the flagging provider's calls; (3) raw archive scrubbed and deleted sessions restored from workflow artifacts; (4) workflow artifacts holding unscrubbed text deleted after confirming repo coverage
structural_fix: refusal-behavior measurement is PARKED, not killed. If revived, it runs as a SEPARATE instrument on dedicated, disclosed, expendable keys - one per provider, low frequency, segregated so an enforcement action can never touch the baseline availability clock. New doctrine: never run deliberately-unsafe traffic on a shared signal-bearing key; always fetch and diff against the remote before any history rewrite.
controls_that_worked: the cron's per-run fallback artifact (made the data loss fully recoverable); the raw archive's own refusal-classification (let the scrub retain the measurement fact while dropping harmful text); Rekor-witnessed run provenance (independent public timestamps)

Evidence

telemetry_grade: witnessed - each run is cosign/Rekor-witnessed with the battery hash pinned into the signed session meta, so the battery composition and its change are independently timestamped in a public transparency log the seismograph repository is now public; the raw sessions remain private; the raw sessions themselves are operator-logs
sources:
- https://github.com/piperoll/seismograph/blob/main/POSTMORTEM-2026-09.md (the operator's own public post-mortem)
- the provider usage-policy notice dated 2026-09-01 (a private communication to the operator; quotable in the post-mortem, not a public URL)
- https://github.com/piperoll/seismograph/tree/main/witness (the cosign/Rekor witness bundles for every run; the battery-hash change is independently timestamped)
- independence: weak - narrative evidence chains to the operator, who is also the registry. Independently verifiable: the Rekor timestamps (battery composition and its change) and the provider notice (a third party's enforcement action, quotable but not public). No outside observer witnessed this.
confidence: high on mechanism (full operator logs); medium on completeness of exposure (only one provider gave notice, so silent strikes at the others cannot be ruled out)

Verification / schema notes

First record where the operator is the registry itself. The rule-4 disclosure generalizes cleanly, but the sourcing-honesty burden is higher: "we registered ourselves" is credible only if the independence note refuses to overstate corroboration. The primary independent evidence here is a transparency-log timestamp, not a source document - a pattern the seismograph produces repeatedly.
Two coupled failures (the design flaw and the recovery flaw) strained the single-root_cause field; contributing-cause prose absorbed it. A recurring "remediation itself caused a second incident" pattern may deserve a first-class field.
data_exposure currently frames outbound data leakage; here the exposure is outbound harmful CONTENT the agent SENT. A distinct axis ("agent-emitted harmful content") may be warranted as agent traffic becomes a policy-enforcement surface.
Companion: [[PIR-2026-0055]] (the confidentiality failure caused while documenting this record).

PipeRoll's own seismograph instrument ran deliberately-unsafe refusal-boundary probes…