PIR-2026-0045 - Autonomous agent leaks its own API key to public GitHub via blanket git add

Disclosure: The subject agent (SEED) is funded by the PipeRoll founder. Recorded first precisely because full forensics are available; the conflict is disclosed per PipeRoll constitutional rule 4.

• id: PIR-2026-0045
• title: Autonomous agent commits its own .env (Anthropic API key) to a public repo via git add -A in a cron heartbeat
• date_occurred: 2026-08-15 ~00:40 UTC (first heartbeat commit containing .env)
• date_detected: 2026-08-15 ~00:50 UTC
• date_disclosed: 2026-08-15 00:52 UTC (public audit log + live dashboard, same hour)
• status: corroborated (public git history, on-chain-adjacent public audit trail, funder confirmation)

The agent

• agent_description: SEED - autonomous survival-economy agent (public experiment); Claude brain invoked headless, cron heartbeat for mechanical tasks, own Solana wallet, self-authored codebase, public repo under its own identity.
• operator_type: autonomous (no operator review; human funder hands-off by design)
• autonomy_level: fully-autonomous (writes and deploys its own code, including the code that failed)
• model_stack: Claude (Fable 5) via capped API key; local qwen3-4b reflex tier (added post-incident, same day)
• harness: self-written Python heartbeat on cron + headless claude -p wakes

Authority

• authority_scope: credentials (own API key in .env), code execution (own repo + server), funds (separate: Solana wallet key on same host - NOT exposed in this incident), external comms (git push to public repo)
• funds_at_risk_usd: 30 (API key spend cap; billing exposure bounded by the cap - the cap functioned as the loss ceiling)
• blast_radius: one org (agent's own compute budget); public exposure of the secret itself

The failure

• root_cause: credential-exposure (primary); contributing policy-violation (agent's own hygiene assumed) and plain-error (blanket staging)
• failure_locus: harness (the self-written cron heartbeat script whose blanket git add -A staged the secret); agent-reasoning contributing - the agent authored the faulty automation itself hours earlier
• exploitation_status: in-wild-malfunction (production incident, no adversary; the agent published its own secret through routine automation)
• mechanism: Agent's self-written heartbeat used git add -A for convenience. The .env file containing the live API key existed in the repo directory before .gitignore covered it. Cron fired, heartbeat staged everything, committed, pushed to the public GitHub repo. No adversary involved; the agent published its own secret through routine automation it had authored hours earlier.
• adversary_present: no

Impact

• severity: near-miss (full exposure of a live credential; zero realized abuse)
• direct_loss_usd: 0 (key disabled before any third-party use)
• indirect_loss_usd: ~0 (brief brain-dark period awaiting replacement key; remediation labor by the agent itself)
• downtime: brain unavailable until key replaced (order of hours)
• data_exposure: one live Anthropic API key, public GitHub, exposure window ~minutes to ~1 hour

Detection and recovery

• detected_by: operator-side (funder had already disabled the key by the time the agent logged the incident; exact detection channel - funder observation vs automated secret-scanning revocation - unconfirmed)
• time_to_detect: ≤ ~10 minutes from push
• time_to_recover: same session - history purged via filter-branch, force-pushed clean, .gitignore hardened, .env untracked
• remediation: full git history rewrite to purge the secret; key rotation (funder-side)
• structural_fix: blanket git add -A banned permanently; all commits switched to explicit file paths (rule embedded in the agent's own tooling comments); incident published to the live public dashboard, not just the repo

Evidence

• telemetry_grade: operator-logs (editable) - and demonstrably so: the remediation itself was a history rewrite. The same power that purged the secret could purge an inconvenient record. The append-only audit JSONL is kept by the same actor. This incident is the canonical argument for witnessed telemetry: even a maximally transparent agent's history is only as trustworthy as its sole custodian.
• sources: https://github.com/seedalive-simulation/experiment (audit log, entry 2026-08-15T00:51:27 UTC; verified resolving); unverified: https://seedalive.ar.io (the public dashboard; URL per the experiment's own docs - could not be fetch-verified at entry time and no archive snapshot found). Funder account is first-party testimony with no URL - noted here, not counted as a source. Independence: weak - all evidence chains to the agent/funder pair; corroborated by the public nature of the exposure window.
• confidence: high on mechanism and remediation (public record); medium on detection channel (unconfirmed whether funder observation or automated revocation)

Schema notes from entering this record (feed back into v0)

1. Near-miss severity class earns its place immediately - realized loss $0, but the exposure and the control that bounded it (the $30 cap) are the actuarially useful facts.
2. Need a controls_that_worked field: the spend cap and the key's revocability bounded this incident, and nothing in the schema currently captures functioning controls - underwriters price on exactly that.
3. detected_by taxonomy is too coarse: "funder had already disabled it" is neither operator-routine nor third-party; possibly automated platform-side secret scanning. Add platform-automated option.
4. The telemetry_grade field writing itself: the incident's remediation (history rewrite) is a live demonstration of why operator-custody logs cap out at "editable."