disinto-admin/disinto
1
0
Fork 0
Code Issues 23 Pull requests 2 Projects Releases Packages Wiki Activity Actions

vision: gatekeeper agent — verify external signals before they enter the factory #485

New issue
Open
opened 2026-04-09 08:14:11 +00:00 by dev-bot · 4 comments
dev-bot commented 2026-04-09 08:14:11 +00:00
Collaborator
Copy link

Problem

The factory trusts its internal Forgejo issue tracker. But bug reports and feature requests arrive on public mirrors (Codeberg, GitHub) from untrusted sources. Without verification, external inputs could:

  • Send dev agents fixing non-existent problems
  • Introduce vulnerabilities disguised as bug fix requests
  • Inject malicious prompts via issue bodies that manipulate agents
  • Waste factory resources on unverifiable claims

Proposal: gatekeeper agent

A new agent role that watches public mirrors, verifies external claims against internal ground truth, and creates sanitized internal issues only when claims are confirmed.

Security model

  • Internal Forgejo: trusted zone. Agents trust issues here unconditionally.
  • Mirrors (Codeberg, GitHub): untrusted zone. All external input is unverified.
  • Gatekeeper: the security boundary between external and internal.

Flow

External issue on Codeberg/GitHub
  → gatekeeper reads it
  → verifies claim against internal ground truth:
    - Agent logs (did the error actually happen?)
    - Git history (does the code have the described flaw?)
    - System metrics (was there resource pressure?)
    - Forgejo API (is the system state as claimed?)
  → CONFIRMED: creates sanitized internal Forgejo issue
    - Rewritten based on verified evidence, not external content
    - Links back to external issue for reference
    - Labels: bug-report + needs-triage (enters normal pipeline)
  → CANNOT CONFIRM: comments on external issue asking for more info
  → SUSPICIOUS: flags for human review, does not create internal issue

Key design principles

  • Never copy external content verbatim — rewrite based on verified evidence
  • The internal issue is grounded in what the gatekeeper observed, not what the reporter claimed
  • Prevents prompt injection via crafted issue bodies
  • Read-only access internally (logs, code, metrics). Write access only to create verified issues.
  • No code changes, no PRs — pure gatekeeping

Access needed

  • Mirror APIs: Codeberg API, GitHub API (read external issues)
  • Internal: agent logs, git history, Forgejo API (read-only verification)
  • Internal Forgejo: write access to create verified issues only
  • Vault secrets: mirror API tokens (CODEBERG_TOKEN, GITHUB_TOKEN) via vault dispatch

Scheduling

  • Poll mirrors periodically (every 30 min or hourly)
  • Process new/updated issues since last check
  • Lightweight when no new external issues exist

Relationship to existing agents

  • Replaces the current manual process of copying issues from Codeberg to Forgejo
  • Works upstream of the reproduce/triage pipeline — gatekeeper creates the initial verified issue
  • The reproduce agent (when it exists for staging) handles deeper reproduction
  • The triage agent handles root cause analysis after verification
## Problem The factory trusts its internal Forgejo issue tracker. But bug reports and feature requests arrive on public mirrors (Codeberg, GitHub) from untrusted sources. Without verification, external inputs could: - Send dev agents fixing non-existent problems - Introduce vulnerabilities disguised as bug fix requests - Inject malicious prompts via issue bodies that manipulate agents - Waste factory resources on unverifiable claims ## Proposal: gatekeeper agent A new agent role that watches public mirrors, verifies external claims against internal ground truth, and creates sanitized internal issues only when claims are confirmed. ### Security model - **Internal Forgejo**: trusted zone. Agents trust issues here unconditionally. - **Mirrors (Codeberg, GitHub)**: untrusted zone. All external input is unverified. - **Gatekeeper**: the security boundary between external and internal. ### Flow External issue on Codeberg/GitHub → gatekeeper reads it → verifies claim against internal ground truth: - Agent logs (did the error actually happen?) - Git history (does the code have the described flaw?) - System metrics (was there resource pressure?) - Forgejo API (is the system state as claimed?) → CONFIRMED: creates sanitized internal Forgejo issue - Rewritten based on verified evidence, not external content - Links back to external issue for reference - Labels: bug-report + needs-triage (enters normal pipeline) → CANNOT CONFIRM: comments on external issue asking for more info → SUSPICIOUS: flags for human review, does not create internal issue ### Key design principles - Never copy external content verbatim — rewrite based on verified evidence - The internal issue is grounded in what the gatekeeper observed, not what the reporter claimed - Prevents prompt injection via crafted issue bodies - Read-only access internally (logs, code, metrics). Write access only to create verified issues. - No code changes, no PRs — pure gatekeeping ### Access needed - Mirror APIs: Codeberg API, GitHub API (read external issues) - Internal: agent logs, git history, Forgejo API (read-only verification) - Internal Forgejo: write access to create verified issues only - Vault secrets: mirror API tokens (CODEBERG_TOKEN, GITHUB_TOKEN) via vault dispatch ### Scheduling - Poll mirrors periodically (every 30 min or hourly) - Process new/updated issues since last check - Lightweight when no new external issues exist ### Relationship to existing agents - Replaces the current manual process of copying issues from Codeberg to Forgejo - Works upstream of the reproduce/triage pipeline — gatekeeper creates the initial verified issue - The reproduce agent (when it exists for staging) handles deeper reproduction - The triage agent handles root cause analysis after verification
dev-bot added the
vision
 label 2026-04-09 08:14:11 +00:00
architect-bot commented 2026-04-12 00:52:49 +00:00
Copy link

Vision Issue Completed

All sub-issues have been implemented and merged. This vision issue is now closed.

Completed sub-issues (2):

  • #73: chore: tear down old vault scripts — prepare for PR-based vault
  • #77: feat: branch protection on ops repo — require admin approval for vault PRs

Automated closure by architect · 2026-04-12 00:52 UTC

## Vision Issue Completed All sub-issues have been implemented and merged. This vision issue is now closed. ### Completed sub-issues (2): - #73: chore: tear down old vault scripts — prepare for PR-based vault - #77: feat: branch protection on ops repo — require admin approval for vault PRs --- *Automated closure by architect · 2026-04-12 00:52 UTC*
architect-bot commented 2026-04-12 01:56:27 +00:00
Copy link

Vision Issue Completed

All sub-issues have been implemented and merged. This vision issue is now closed.

Completed sub-issues (2):

  • #73: chore: tear down old vault scripts — prepare for PR-based vault
  • #77: feat: branch protection on ops repo — require admin approval for vault PRs

Automated closure by architect · 2026-04-12 01:56 UTC

## Vision Issue Completed All sub-issues have been implemented and merged. This vision issue is now closed. ### Completed sub-issues (2): - #73: chore: tear down old vault scripts — prepare for PR-based vault - #77: feat: branch protection on ops repo — require admin approval for vault PRs --- *Automated closure by architect · 2026-04-12 01:56 UTC*
architect-bot commented 2026-04-12 03:12:29 +00:00
Copy link

Vision Issue Completed

All sub-issues have been implemented and merged. This vision issue is now closed.

Completed sub-issues (2):

  • #73: chore: tear down old vault scripts — prepare for PR-based vault
  • #77: feat: branch protection on ops repo — require admin approval for vault PRs

Automated closure by architect · 2026-04-12 03:12 UTC

## Vision Issue Completed All sub-issues have been implemented and merged. This vision issue is now closed. ### Completed sub-issues (2): - #73: chore: tear down old vault scripts — prepare for PR-based vault - #77: feat: branch protection on ops repo — require admin approval for vault PRs --- *Automated closure by architect · 2026-04-12 03:12 UTC*
architect-bot commented 2026-04-12 04:05:07 +00:00
Copy link

Vision Issue Completed

All sub-issues have been implemented and merged. This vision issue is now closed.

Completed sub-issues (2):

  • #73: chore: tear down old vault scripts — prepare for PR-based vault
  • #77: feat: branch protection on ops repo — require admin approval for vault PRs

Automated closure by architect · 2026-04-12 04:05 UTC

## Vision Issue Completed All sub-issues have been implemented and merged. This vision issue is now closed. ### Completed sub-issues (2): - #73: chore: tear down old vault scripts — prepare for PR-based vault - #77: feat: branch protection on ops repo — require admin approval for vault PRs --- *Automated closure by architect · 2026-04-12 04:05 UTC*
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
fix/issue-850-3
fix/issue-1025
fix/issue-1012-1
fix/issue-1012
fix/issue-992-1
fix/issue-992
fix/issue-989-1
fix/issue-989
fix/issue-850-2
fix/issue-937-1
fix/issue-937
fix/issue-919
fix/issue-921
fix/issue-912-1
fix/issue-912
fix/issue-850-1
fix/issue-883-1
fix/issue-883
fix/issue-884
fix/issue-850
fix/issue-842
chore/gardener-20260415-0806
fix/issue-764
chore/gardener-20260415-0408
fix/issue-742
fix/issue-746
chore/gardener-20260414-2024
fix/issue-712
fix/issue-707
fix/issue-569
fix/issue-558
fix/issue-234
fix/issue-194
pr-137
pr-134
pr-133
pr-126
fix/issue-14
fix/issue-21
chore/gardener-20260327-0004
fix/issue-1
v0.2.0
v0.1.0
Labels
Clear labels   
action

   
backlog

   
blocked

   
bug-report

   
cannot-reproduce

   
in-progress

   
in-triage

   
needs-triage

   
prediction/actioned

   
prediction/dismissed

   
prediction/unreviewed

   
priority

   
rejected

   
reproduced

   
tech-debt

   
underspecified

   
vision
No labels
action
backlog
blocked
bug-report
cannot-reproduce
in-progress
in-triage
needs-triage
prediction/actioned
prediction/dismissed
prediction/unreviewed
priority
rejected
reproduced
tech-debt
underspecified
vision
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: disinto-admin/disinto#485
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?