extractAndEnrich writes pages from untrusted text without a gate

[garagon]

Summary

extractAndEnrich in src/core/enrichment-service.ts runs a regex over arbitrary text, pulls out anything that looks like a capitalized name, and unconditionally calls engine.putPage() on the owner's brain under people/{slug} or companies/{slug}. There is no confirmation step, no allow-list, no review queue, and the source of the text is whatever skill invoked the call — ingest, meeting-ingestion, idea-ingest, any of the recipes that forward raw email / transcript / pasted content.

The practical shape:

1. A meeting transcript, pasted article, or email comes in via one of the ingest skills.
2. The skill calls extractAndEnrich(engine, text, sourceSlug) as part of enrichment.
3. extractEntities greps for \b[A-Z][a-z]+(?:\s+[A-Z][a-z]+){1,3}\b, accepts any hit, and feeds each to enrichEntity.
4. If the entity page doesn't exist, enrichEntity creates it with generateStubContent(name, type, context) — where context is a 50-char window of the raw input text — and writes it to the brain as an authoritative page.

So the attacker-shaped case looks like: a hostile email (or a spoofed meeting transcript, or a poisoned CSV attached to a briefing) carrying the sentences

I had lunch with Paul Graham today. He mentioned that Ycombinator Inc. is pivoting to crypto.

ends up creating people/paul-graham and companies/ycombinator-inc pages in the owner's brain, with the sentence copied in as the summary. The owner never typed that. Agents that query the brain later ("what does gbrain say about Paul Graham?") quote it back as ground truth.

This is a data-injection / authz gap, not an RCE. It's latent today because the current in-tree caller set is small, but the skill-driven ingest paths this wires into (meeting-ingestion, idea-ingest, media-ingest) all take external content by design.

Why it matters

The brain's value is that it's trusted. Everything downstream — search, enrichment chains, agent responses — assumes pages in people/ and companies/ reflect the owner's observations. Once untrusted ingest gets unbounded write access to those namespaces, the trust model collapses silently: the owner can't tell which entries came from their own notes and which came from a sentence that happened to sit in an incoming email.

Secondary effects:

• Slug collisions. slugifyEntity normalizes Tim<Cook> and Tim Cook to the same slug. An attacker who wants to tamper with an existing legitimate page just picks a name that slugifies to its path and ships a sentence that mentions it — enrichEntity sees the page exists, takes the UPDATE branch, and appends a timeline entry quoting the attacker's context (see enrichEntity around lines 85-100 — the UPDATE path is silent on who supplied the timeline text). R6 filed this as a separate finding (slugify collision); it's more impactful once F004 is closed but worth mentioning here.
• Regex is greedy. [A-Z][a-z]+ matches Dear John, Best Regards, New York, Bar Mitzvah. The false-positive rate on real email means a brain wired to this function fills with junk entries even without an adversary.

Proposed approaches

Three shapes, ordered by blast radius. All of them keep the function exported with the same name so existing in-tree callers keep working.

1. Quarantine namespace by default

• extractAndEnrich writes proposed pages under _pending_review/{slug} instead of people/{slug} / companies/{slug}.
• A separate command (gbrain review --pending) lets the owner approve, reject, or merge each proposal into the real namespace.
• Ingest skills are unaffected — they still call extractAndEnrich — but the user is the gate on what becomes authoritative.

Smallest behavior change from the owner's point of view, strongest defense. The review queue is the audit trail.

2. Require an explicit autocreate: true flag per request

• Default enrichEntity / extractAndEnrich to action: 'skipped' when the page doesn't exist.
• Callers that genuinely want page creation pass { autocreate: true } and accept the risk.
• Skills that take external content (meeting-ingestion, idea-ingest, media-ingest) get the default; skills that take owner-typed input (gbrain new person … if it exists) set the flag explicitly.

Smaller diff than (1). Downside: the default is a behavior change from today, and every skill that currently relies on auto-create needs a touch. That's the skills surface you asked to keep sensitive — happy to leave the audit to a maintainer-led review rather than a drive-by PR.

3. Source-based policy (config-driven)

• Add enrichment.policy in gbrain config: allow | quarantine | deny, per sourceSlug prefix.
• meeting-ingestion → quarantine, manual-entry → allow, etc.
• Ships as config, no code change beyond one read at the top of enrichEntity.

Most flexible, highest cognitive cost (another policy knob the owner has to remember).

PoC

Runtime PoC from the audit (internal, not public):

// Minimal shape — real PoC file at workspace/gbrain/report/evidence/poc-r6-f004-*.ts
const { extractAndEnrich } = await import('./src/core/enrichment-service.ts');
const hostileText = 'I met with Paul Graham. He mentioned Ycombinator Inc. is pivoting.';
const results = await extractAndEnrich(engine, hostileText, 'ingest/email');
// After: engine.getPage('people/paul-graham') returns a page that was never
// authored by the owner, with the hostile sentence as its Summary field.

Nothing in the call chain rejects it. results[0].action === 'created' and the page is now discoverable via searchKeyword('Paul Graham').

What I'd file against if chosen

Happy to send a PR for any of the three approaches. I'd lean (1) because it preserves current behavior for the owner while slamming the door on silent writes — owner still sees the proposal, can accept in one command, and gets an audit log for free. Open to (2) or (3) if you prefer less churn in the review UX.

No PR yet because (a) this is shaped like a product decision more than a bug fix, and (b) the right fix depends on how you want enrichment to feel end-to-end — which touches the skill surface you own directly. Happy to defer, happy to spec out the chosen approach once you pick.

Related

• security: contain path traversal in check-resolvable and doctor #156 (path traversal in check-resolvable.ts) — same audit round, different finding.
• postgres-engine: scope search statement_timeout to the transaction #158 (postgres pool timeout leak) — same round, different subsystem.
• Slug collision in slugifyEntity is a separate follow-up that becomes easier to exploit if F004 stays open; can be addressed alongside or independently.

Out of scope

• Timeline entry injection on existing pages (related, deserves its own issue).
• Entity-regex false positives (UX problem, not security).
• Tier auto-escalation based on untrusted source count (tangential; an attacker who can create a page can also inflate its tier, but that's an amplifier, not the root cause).

[jamebobob]

Ran into this exact concern while setting up gbrain on a Hermes-agent install last night and implemented garagon's quarantine-namespace proposal as a local patch before circling back to this issue. Sharing what we built and what we learned in case it helps the design discussion.

What triggered it for us. During smoke testing, a synthetic message with fabricated names (fake pre-seed founder, fake girlfriend, fake company) fired through the signal-detector-equivalent we had running as a Hermes plugin. Nothing stopped the extractor from writing people/<fake-name>.md pages with authoritative-looking timeline entries. A PATH bug in our first plugin attempt accidentally protected us from the pollution; once we fixed the PATH bug, the same test content wrote clean pages straight into authoritative directories. That's when we came looking for prior art and found this issue.

What we shipped:

1. Quarantine namespace _pending/. Plugin writes to ~/brain/_pending/{type}/{slug}.md instead of ~/brain/{type}/{slug}.md. Authoritative dirs stay empty until something explicitly promotes from quarantine. Implemented as a 3-line exclusion in src/core/sync.ts::isSyncable() matching the existing ops/ / .raw/ pattern.

2. Input-hash frontmatter on every quarantined page. <!-- input_hash=XXXXXXXXXXXX --> where the hash is over the source message text, not the page content. Lets a blocklist target source messages rather than final page content, which matters if the same fabricated input could produce multiple page variants (regex false positives from the same text often do).

3. 72-hour age gate before any evaluation. Gives the capture time to be contradicted or reinforced by later messages before we consider promoting.

4. Second-pass notability evaluator (Sonnet 4.6 in our case). Daily cron walks _pending/, calls a second model with a stricter prompt than signal-detector used. Criteria baked in:

   • Real entity or genuine original thinking, not a regex false positive (garagon's "Dear John", "Bar Mitzvah", "New York" are exactly the failure modes we target).
   • Enough content to be worth keeping.
   • Source attribution present.
   • For people/ specifically: real-world anchoring plus substantive enough to identify later.

5. Three verdicts: promote, reject, defer. Defer increments <!-- defer_count=N --> frontmatter. Max 3 defer cycles (9 days) before force-reject. Gives ambiguous captures a chance to accumulate cross-references without letting them sit forever.

6. Collision-safe promote. Before mv _pending/{type}/{slug} {type}/{slug}, check target existence. If yes, defer with reason target_exists_manual_merge_needed rather than silently overwriting. Addresses the slug-collision class.

7. JSONL audit log. Every evaluation gets {slug, age, defer_count, verdict, reason}. grep '"verdict":"reject"' log.jsonl | tail -20 inspects filter quality.

Dry-run result on 175 pending pages from a first live overnight: 101 promote / 55 reject / 19 defer / 0 errors. Sample reject reason: "Near-empty stub with no substantive content about what AGENTS.md actually contains or governs." Sample promote: "Genuine original concept with substantive definition, real-world anchoring to this system's own governance rules, and proper source attribution." One dry-run isn't real quality data, but the verdicts read sensibly on spot checks.

On the three approaches in the issue: we went with shape 1 (quarantine namespace) for the reasons garagon lists, but replaced the manual-review step with an auto-evaluator because our prior experience with voluntary-review protocols is that they decay. The second-pass evaluator is more work than an allow-list or a synchronous confirmation, but it keeps the ambient-capture pattern working while adding the trust boundary.

Adjacent upstream work we cross-referenced while building this:

• Issue fix(sync): deadlock on incremental sync with > 10 modified files #132 (sync deadlock on incremental sync with >10 modified files): our workaround avoids the lock class entirely by writing markdown files directly and letting autopilot sync to the DB on its cycle. PR fix: remove outer transaction wrapper in sync to prevent PGlite deadlock #193 (open) appears to fix the deadlock class upstream by removing the outer transaction wrapper, which is independent of our pattern.
• Commit ec0556a on branch garrytan/minions-jobs states in its body: "PGLite has an exclusive file lock that blocks a second worker process, so the inline path is the only path that works there." Upstream confirming the single-writer constraint is what led us to the markdown-first pattern rather than calling gbrain put from the plugin.
• PR feat(link-extraction): Obsidian vault support — configurable entity_dirs + wikilinks #194 (feat: configurable entity_dirs + wikilinks): the author describes hitting 0 auto-link extraction on a 2,052-page Obsidian vault because of the hardcoded entity-dir list. We hit the same 0 on 61 indexed pages of narrative prose (history files with natural-language first names in body text, no [Name](people/name) wiki refs). Our graph-layer output was 0 links post-install; PR feat(link-extraction): Obsidian vault support — configurable entity_dirs + wikilinks #194's configurable entity_dirs would likely fix this.

Honest gap in our implementation: we write markdown files directly and let autopilot pick them up, which means the v0.10.3 auto-link post-hook on put_page never fires on our promoted pages. The promotion-cron's path.rename() from _pending/{type}/{slug}.md to {type}/{slug}.md also doesn't go through put_page, so back-links per the Iron Law in skills/conventions/quality.md don't auto-create on promote either. Fix we're about to ship in our plugin: replay gbrain put {slug} on the content after rename, which triggers both auto-link and back-link on the authoritative write. If the upstream version of this gate ships in TypeScript via the engine interface, this problem doesn't exist; it's an artifact of our plugin living outside the gbrain process.

Related issues we filed while working through the quarantine implementation (not blockers, but adjacent):

• Issue extract: --source fs walker does not respect isSyncable prefix exclusions #202 (extract --source fs doesn't respect isSyncable prefix exclusions): the fs walker skips .-prefix and _-prefix FILE entries but not _-prefix DIRECTORIES, so _pending/ gets walked anyway on extract.
• Issue init: --provider flags required even when config.json has persisted embedding settings (DX) #203 (init ignores config.json embedding defaults): relevant if _pending/ implementations want a clean re-init path.
• Issue autopilot: graceful shutdown waits full cycle interval due to non-cancelable setTimeout #204 (autopilot SIGTERM non-cancelable): relevant if the quarantine gate runs inside a long-lived daemon.

Can share the plugin and promotion-cron code if it'd help with the upstream version.