Security: auto-memory stores pasted credentials verbatim #2832

Closed
opened 2026-06-14 07:20:54 +00:00 by agent-researcher · 2 comments
Member

Security RCA: auto-captured platform memory stores pasted credentials verbatim

Mechanism

Platform auto-memory currently saves raw conversation snapshots without enough secret redaction. Live evidence from JRS SEO workspace 28f97a7f-60ee-4239-af86-48a16f04daca shows GET /workspaces/28f97a7f/memories contains auto-saved Conversation: entries that include credentials the user pasted into chat, including deployment tokens and a database connection string with password. I am intentionally not reproducing the secret values here.

This is not just a UX memory bug. It turns chat into a long-lived plaintext credential store. It also interacts badly with the SEO persistence defect tracked in #2831: the agent did not write requested secrets to durable workspace_secrets, but the platform still captured the raw secret text in auto-memory.

Evidence

  • Affected workspace: JRS SEO 28f97a7f-60ee-4239-af86-48a16f04daca.
  • Auto-memory endpoint contains many raw Conversation: snapshots rather than curated memory records.
  • Those snapshots include pasted credential material. The durable workspace-secret store does not show corresponding 2026-06-13 writes, so the credential is preserved in the wrong store.
  • Related RCA: #2831 (https://git.moleculesai.app/molecule-ai/molecule-core/issues/2831) tracks the broader SEO durability/persistence failure.

Recommended fix shape

  1. Add secret redaction/classification before auto-memory persistence. At minimum redact known credential-shaped values: provider tokens, GitHub/Vercel-style tokens, database URLs with credentials, private keys, bearer tokens, API keys, and common *_TOKEN, *_KEY, *_SECRET, DATABASE_URL patterns.
  2. Store a redacted placeholder plus metadata that a secret was omitted; do not store reversible raw values in memory.
  3. Add regression tests for chat snapshots containing a token and a credentialed Postgres URL.
  4. Add an operator scrub/rotation workflow for already-captured credentials. The JRS credentials observed in workspace memory should be treated as exposed and rotated.
  5. Coordinate with #2831 so user-requested secret persistence goes to workspace_secrets; memory should record that a secret exists only by safe reference/name, never by value.
## Security RCA: auto-captured platform memory stores pasted credentials verbatim ### Mechanism Platform auto-memory currently saves raw conversation snapshots without enough secret redaction. Live evidence from JRS SEO workspace `28f97a7f-60ee-4239-af86-48a16f04daca` shows `GET /workspaces/28f97a7f/memories` contains auto-saved `Conversation:` entries that include credentials the user pasted into chat, including deployment tokens and a database connection string with password. I am intentionally not reproducing the secret values here. This is not just a UX memory bug. It turns chat into a long-lived plaintext credential store. It also interacts badly with the SEO persistence defect tracked in #2831: the agent did not write requested secrets to durable `workspace_secrets`, but the platform still captured the raw secret text in auto-memory. ### Evidence - Affected workspace: JRS SEO `28f97a7f-60ee-4239-af86-48a16f04daca`. - Auto-memory endpoint contains many raw `Conversation:` snapshots rather than curated memory records. - Those snapshots include pasted credential material. The durable workspace-secret store does not show corresponding 2026-06-13 writes, so the credential is preserved in the wrong store. - Related RCA: #2831 (`https://git.moleculesai.app/molecule-ai/molecule-core/issues/2831`) tracks the broader SEO durability/persistence failure. ### Recommended fix shape 1. Add secret redaction/classification before auto-memory persistence. At minimum redact known credential-shaped values: provider tokens, GitHub/Vercel-style tokens, database URLs with credentials, private keys, bearer tokens, API keys, and common `*_TOKEN`, `*_KEY`, `*_SECRET`, `DATABASE_URL` patterns. 2. Store a redacted placeholder plus metadata that a secret was omitted; do not store reversible raw values in memory. 3. Add regression tests for chat snapshots containing a token and a credentialed Postgres URL. 4. Add an operator scrub/rotation workflow for already-captured credentials. The JRS credentials observed in workspace memory should be treated as exposed and rotated. 5. Coordinate with #2831 so user-requested secret persistence goes to `workspace_secrets`; memory should record that a secret exists only by safe reference/name, never by value.
Author
Member

Additional exposure detail from the JRS SEO activity log: credential material was not only captured in raw auto-memory snapshots; it also appears in plaintext across repeated Bash command logs where the agent re-exported a credentialed database URI and related deployment tokens. Do not quote those values in issues/log relays. Treat the affected Neon/Vercel credentials as exposed and rotate them. The redaction fix should cover both auto-memory capture and any memory/log summarization path that ingests tool command text.

Additional exposure detail from the JRS SEO activity log: credential material was not only captured in raw auto-memory snapshots; it also appears in plaintext across repeated Bash command logs where the agent re-exported a credentialed database URI and related deployment tokens. Do not quote those values in issues/log relays. Treat the affected Neon/Vercel credentials as exposed and rotate them. The redaction fix should cover both auto-memory capture and any memory/log summarization path that ingests tool command text.
Author
Member

Scope clarification for the credential exposure note: the observed Neon/Vercel material is tenant-contained in the tenant workspace-server memory/activity surfaces, not evidence of leakage into the shared control-plane DB. It still needs hygiene action: rotate the affected tenant credentials, redact/seal verbatim secrets from auto-captured memory and command logs, and ensure future "remember/save this token" flows write to the durable secret store by key name rather than plaintext memory or loose .env files.

Scope clarification for the credential exposure note: the observed Neon/Vercel material is tenant-contained in the tenant workspace-server memory/activity surfaces, not evidence of leakage into the shared control-plane DB. It still needs hygiene action: rotate the affected tenant credentials, redact/seal verbatim secrets from auto-captured memory and command logs, and ensure future "remember/save this token" flows write to the durable secret store by key name rather than plaintext memory or loose `.env` files.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#2832