[BUG] triage-panel skips external contributor issues due to DIFC integrity policy

[sergio-sisternes-epam]

Describe the bug

The triage-panel agentic workflow silently skips open issues labelled status/needs-triage when authored by external contributors (non-org members). Only issues from org members are being triaged.

To Reproduce

1. Open an issue as an external contributor and label it status/needs-triage
2. Wait for the next scheduled sweep (or trigger triage-panel manually)
3. Observe the issue remains untriaged -- status/needs-triage label stays, no triage comment posted

Expected behaviour

All open issues labelled status/needs-triage should be processed regardless of author origin.

Root cause

gh-aw's DIFC policy assigns LOW integrity to issues from non-org-member authors. Because triage-panel holds safe-outputs write permissions, DIFC auto-raises the minimum required integrity to HIGH for MCP reads:

• search_issues (MCP) silently drops low-integrity issues -- absent from results, no error
• get_issue (MCP) returns McpError: MCP error 0: [Filtered] for low-integrity issues
• gh issue view fails as gh is unauthenticated inside the agent sandbox

Logs

From workflow run 25871323183:

Issue #1225 is not accessible via the GitHub MCP server -- filtered by
integrity policy (DIFC). The gh CLI is also not authenticated.

Evidence: 11 stalled issues (all external contributors)

Audited on 2026-05-15 -- every open status/needs-triage issue is from a non-org-member, zero from org members:

Issue	Author	Title
#1326	edenfunf	[BUG] Cross-repo bare repo on *.ghe.com marketplace silently resolves at github.com on validation success
#1310	Mathf18	[BUG] apm install --target claude writes ${CLAUDE_PLUGIN_ROOT} into ~/...
#1300	wetwicky	[FEATURE] Support handoffs: frontmatter in .agent.md files
#1297	rcollette	[BUG] No way to set target for apm update
#1295	nadav-y	[FEATURE] Add package registry support for dependency resolution
#1293	Alpha200	[BUG] Authentication fails for apm install --update with private Git-R...
#1279	petemounce	[BUG] generating _apm_source into .claude/settings.json invalidates...
#1273	ScottGuymer	Devcontainer feature not published
#1266	hansonkim	[BUG] Codex and Gemini adapters pass self-defined stdio env verbatim
#1231	chkp-roniz	feat: make apm update respect air-gapped environment variables
#1225	kkadete	[FEATURE] Add IntelliJ / JetBrains as an MCP target

The same day's sweep successfully triaged issues authored by org members, confirming the failure is author-origin-specific rather than a general workflow failure.

Environment

• Component: .github/workflows/triage-panel.md
• gh-aw compiler: 0.25.40
• Triggers affected: schedule (daily sweep) and issues.labeled (opt-in retriage)

[github-actions]

Triage decision

needs-design

Proposed labels

theme/governance
area/ci-cd
area/audit-policy
type/bug
status/needs-design

Milestone

null

Suggested next action

Design the read-phase boundary for the triage-panel: decide whether to split issue-body reads into a low-privilege pre-step outside the DIFC-guarded MCP path, add an explicit DIFC exemption in the gh-aw policy config for triage-read operations, or use the GitHub REST API directly (bypassing the MCP layer) for external contributor issue bodies -- and document which DIFC invariants are preserved by the chosen approach.

Suggested issue comment

Thanks for the detailed bug report and the evidence table -- this is a clear and well-scoped issue.

You have correctly identified the DIFC (Data Integrity Flow Control) boundary as the root cause.
Because the triage-panel workflow holds `safe-outputs` write permissions, gh-aw's DIFC policy
auto-raises the minimum required integrity to HIGH for MCP reads, which silently filters out
issues from non-org-member authors. The result is that 11 external contributor issues are stalled
with no triage feedback -- exactly the opposite of what the automation is meant to do.

The direction is clear: restore triage coverage for all open `status/needs-triage` issues
regardless of author origin. However, before code can land safely, we need to settle the design
of the read-phase boundary:

1. Split the read phase into a low-privilege pre-step that runs outside the DIFC-guarded boundary
   (fetches issue title + body at lower integrity) before the write-privileged agent takes over.
2. Add an explicit DIFC exemption in the gh-aw policy config for triage-read operations, scoped
   narrowly to issue body reads (not arbitrary MCP calls).
3. Use the GitHub REST API directly (bypassing the MCP layer entirely) for fetching external
   contributor issue content, with prompt-injection defense applied at the call site.

Each option has different security and maintainability trade-offs. Option 1 is the most
conservative (no DIFC policy change required); option 3 may be the simplest to implement but
requires verifying that the REST API path is within the gh-aw sandbox's allowed network scope.

We are marking this `status/needs-design` and will track the design decision here before
proceeding to implementation. A design doc or a short comment outlining the chosen approach
(and which DIFC invariants it preserves) would unblock the fix.

If you have a preferred approach or can prototype one of the options, that would accelerate
things significantly -- a draft PR linked back here is a great next step.

Per-lens notes (collapsed)

DevX UX Expert -- User-Need Reviewer

The request maps directly to a real operational surface: a contributor files an issue, expects
triage feedback, and instead receives silence. The "failure mode is the product" principle is
violated here -- no error, no comment, no indication of why nothing happened. The affected
cohort (11 open status/needs-triage issues from external contributors) represents exactly the
most valuable signal an OSS project can receive. The bug is well-documented with logs and a
reproduction table. From a UX standpoint the expected behaviour is unambiguous: status/needs-triage
is the explicit opt-in signal that should be processed regardless of author origin.

Supply Chain Security Expert -- Risk-Surface Reviewer

DIFC is a security control, not a bug. It exists to prevent low-integrity content (external
contributor issue bodies) from influencing write operations in a workflow that holds
safe-outputs write permissions -- a legitimate prompt-injection defence. Any fix MUST preserve
this invariant: the agent must not act on arbitrary content from non-org-member authors without
a sanitisation or isolation boundary. The issue is therefore theme/governance (triage
governance process broken for external contributors) with area/audit-policy as a secondary
area (DIFC policy is the governance audit mechanism in play). The fix design must explicitly
state which DIFC invariants are preserved; a fix that bypasses DIFC entirely would be a security
regression and should not land without a written trade-off and a follow-up hardening issue.

OSS Growth Hacker -- Contributor-Tone Reviewer

Not activated -- author is a COLLABORATOR with technical depth; tone tuning for first-time or
low-interaction contributors is not applicable here.

Python Architect -- Architecture Reviewer

The fix requires a design decision about the read-phase boundary inside the triage-panel
gh-aw workflow (compiled from .apm/skills/apm-triage-panel/). Three viable approaches exist:
(a) split reads into a low-privilege pre-step outside DIFC scope; (b) add a narrow DIFC
exemption in the gh-aw compiler policy config for triage-read operations; (c) use the REST API
directly for issue-body fetches, bypassing the MCP/DIFC layer. Each has different cross-cutting
impact: option (a) requires splitting the workflow DAG; option (b) requires understanding and
modifying gh-aw 0.25.40 policy config surface; option (c) requires verifying REST API
reachability from the sandbox and adding a prompt-injection defence call site. None of these
can land safely without the design boundary being settled first. status/needs-design is
the correct disposition.

Doc Writer -- Documentation Reviewer

Not activated -- this is a bug fix to an internal agentic workflow (triage-panel), not a
user-facing CLI change; no documentation in docs/src/content/docs/ or the README is
implicated by the fix.

APM CEO -- Triage Arbiter

"Community over feature count" is the APM operating principle most directly at stake here:
11 external contributor issues are silently stalled, and those contributors are getting no
signal that their issues were received and will be processed. This is a real trust deficit.
The strategic call is needs-design rather than a fast accept: the DIFC policy is a
load-bearing security control in the gh-aw architecture, and the fix must be designed so
that it restores triage coverage without opening a prompt-injection surface. The Supply Chain
Security Expert and Python Architect agree on this disposition; no arbitration tension to
resolve. Milestone is null (needs-design issues are milestone-free per the label rules);
priority is deferred until the design lands and a patch milestone can be assigned.

{
  "decision": "needs-design",
  "decision_detail": "Fix direction is clear but the DIFC read-phase boundary must be designed before code can land safely -- three candidate approaches (split pre-step, DIFC exemption, direct REST API) each carry different security trade-offs that must be evaluated and documented.",
  "theme": "theme/governance",
  "areas": ["area/ci-cd", "area/audit-policy"],
  "type": "type/bug",
  "status": "status/needs-design",
  "priority": null,
  "preserved_labels": [],
  "milestone": null,
  "next_action": "Design the read-phase boundary: document which of the three candidate approaches (low-privilege pre-step, DIFC exemption, REST API bypass) is chosen and which DIFC invariants it preserves, then link the design back here before opening a fix PR.",
  "comment_markdown": "Thanks for the detailed bug report and the evidence table -- this is a clear and well-scoped issue.\n\nYou have correctly identified the DIFC (Data Integrity Flow Control) boundary as the root cause. Because the triage-panel workflow holds `safe-outputs` write permissions, gh-aw's DIFC policy auto-raises the minimum required integrity to HIGH for MCP reads, which silently filters out issues from non-org-member authors. The result is that 11 external contributor issues are stalled with no triage feedback -- exactly the opposite of what the automation is meant to do.\n\nThe direction is clear: restore triage coverage for all open `status/needs-triage` issues regardless of author origin. However, before code can land safely, we need to settle the design of the read-phase boundary:\n\n1. Split the read phase into a low-privilege pre-step that runs outside the DIFC-guarded boundary (fetches issue title + body at lower integrity) before the write-privileged agent takes over.\n2. Add an explicit DIFC exemption in the gh-aw policy config for triage-read operations, scoped narrowly to issue body reads (not arbitrary MCP calls).\n3. Use the GitHub REST API directly (bypassing the MCP layer entirely) for fetching external contributor issue content, with prompt-injection defense applied at the call site.\n\nEach option has different security and maintainability trade-offs. Option 1 is the most conservative (no DIFC policy change required); option 3 may be the simplest to implement but requires verifying that the REST API path is within the gh-aw sandbox's allowed network scope.\n\nWe are marking this `status/needs-design` and will track the design decision here before proceeding to implementation. A design doc or a short comment outlining the chosen approach (and which DIFC invariants it preserves) would unblock the fix.\n\nIf you have a preferred approach or can prototype one of the options, that would accelerate things significantly -- a draft PR linked back here is a great next step."
}

---

Triage status: agentic proposal pending human ratification.
Silence is approval. Maintainers can:

• Override any label or milestone above by editing it directly --
  human edits are authoritative and will not be reverted on
  subsequent runs.
• Re-trigger triage by applying the status/needs-triage label, or
  by removing status/triaged to enroll the issue in the next
  daily sweep.

Posted by the Triage Panel workflow. See .apm/skills/apm-triage-panel for the panel skill.

Generated by Triage Panel for issue #1344 · ● 789.1K · ◷