Feature request: `blocked` deny list for `assign-to-user` safe output

[benvillalobos]

🤖 Filed with agentic-workflows agent mid-design conversation

Problem

The assign-to-user safe output currently supports assignees: [list] (allowlist) and max: N (count cap), but has no way to deny specific users or patterns from being assigned.

In workflows that process untrusted public input (e.g., issue triage on microsoft/vscode), a prompt injection attack could attempt to trick the agent into assigning copilot or other bot accounts to issues — which would trigger Copilot coding agent sessions or other unintended automated actions. Currently this can only be prevented via prompt-level instructions ("never assign copilot"), which is not a reliable defense against adversarial input.

Maintaining an exhaustive allowlist is also impractical when the set of valid assignees changes as team members rotate.

Proposed Solution

Add a blocked: field to assign-to-user (and potentially unassign-from-user) safe outputs:

safe-outputs:
  assign-to-user:
    blocked: ["copilot", "*[bot]"]   # deny specific users or patterns
    max: 1

This should support:

• Exact user matches (e.g., copilot)
• Pattern matching for bot accounts (e.g., *[bot] to deny all bot suffixed accounts)

Why This Matters

For workflows processing untrusted content, the safe-outputs config is the hard security boundary. A compromised agent that assigns copilot to an issue could trigger an autonomous coding agent session on attacker-controlled issue content — escalating a prompt injection from "triage manipulation" to "code execution." Being able to deny dangerous assignees at the infrastructure layer would close this escalation path.

Related

This is the assign-to-user counterpart to #16625 (blocked patterns for add-labels).

Current Workaround

Prompt-level instructions telling the agent not to assign bot accounts. Works under normal conditions but is not a reliable defense against adversarial input.