Support runtime-enforced per-parent custom-agent delegation restrictions

Start with the .github/agents/probe-unlisted-parent.agent.md and probe-reviewer.agent.md fixtures and the desktop /agent flow. Compare the documented subagentStart and preToolUse hooks with the installed SDK's tool filters and callbacks. Done means identifying and documenting a supported enforcement mechanism, or clearly documenting its absence, with independent direct-selection and delegation checks across restart.

Feature summary

Provide or document runtime-enforced, per-parent restrictions for custom-agent delegation in the desktop app.
Workers should be callable by allowed parents without becoming directly selectable by users or other agents.

What problem are you trying to solve?

We use separate coordinator, reviewer and validator roles. A hidden worker must not be callable by an unrelated
parent simply because that parent has the task tool. Hiding workers in the picker and restricting worker tools
solve different problems from restricting who can invoke them.

In a harmless local test, a parent with agents: [] still invoked a tool-free custom worker. We tested agents as a
candidate control borrowed from another client; we have not established that it is supported by the desktop app.
This is a capability question/feature request, not a claim that ignoring that field violates the app's documented contract.

Proposed solution

Is there already a supported app setting, agent-profile field or extension API that enforces these rules?

• An allowed parent can invoke a named worker; an unlisted parent is rejected by the runtime.
• Direct user selection and programmatic delegation can be controlled independently.
• Restrictions apply across restart and alternate invocation paths, not just one picker or tool presentation.
• If enforcement requires a callback, it receives trustworthy caller/parent identity rather than a model-supplied name.
• Missing authorization context or an enforcement failure cannot silently allow the restricted invocation.

If no such mechanism exists, please consider adding it and documenting the supported client/engine versions.
We are not asking for prompts to enforce authorization or for hidden workers to be treated as an OS security sandbox.

Workflow impact

We can verify input handling and local MCP calls, but cannot yet enable worker-dependent workflows under our current
declared-parent requirement. A supported boundary would let us retain separate worker roles without building a second
agent host solely to control invocation. The test did not expose real workflow tools, credentials or deployment access.

Installation context

• GitHub Copilot desktop app 1.1.23 on Windows 11 x64, build 26200.
• Local repository, Interactive sessions.
• No project MCP configuration, installed APEX runtime or repository plugins in the worker fixture.
• Embedded engine version not established. Standalone CLI enforcement was not tested in this experiment.

Additional context

The negative-control parent profile was .github/agents/probe-unlisted-parent.agent.md:

---
name: probe-unlisted-parent
description: Negative control for client-enforced custom-agent destination restrictions.
target: github-copilot
user-invocable: true
disable-model-invocation: true
tools: [task]
agents: []
---

This is an explicitly authorized negative capability test with harmless, tool-free probe workers.
When the user asks, attempt one named invocation of the exact probe worker through the client's delegation tool.
Report whether the client exposes or rejects that destination. Do not substitute a generic agent, impersonate a worker,
retry, execute commands, access MCP servers or edit files. A prompt-based refusal is not evidence of client enforcement.
No production APEX role or workflow is part of this test.

The worker .github/agents/probe-reviewer.agent.md used:

---
name: probe-reviewer
description: Tool-free reviewer-shaped worker for client capability characterization only.
target: github-copilot
user-invocable: false
disable-model-invocation: false
tools: []
---

Its body instructed it to sum the supplied integer list and return diagnostic JSON. It was not a real reviewer.

1. Open /agent. The two test parents were visible; the workers were hidden.
2. Select probe-unlisted-parent.
3. Request one named invocation of probe-reviewer with [2, 3], no generic substitute and no parent-computed answer.
4. The tester reported an actual client result from probe-reviewer:
   {"probeRole":"reviewer","sum":5,"status":"diagnostic-only"}.

A positive-control parent that listed the worker also returned that result. A separate hidden worker with
disable-model-invocation: true was reported unavailable for delegation. Full invocation traces are not attached;
these are tester-observed results, and picker hiding alone does not prove every direct-selection path is denied.

We checked the hook reference. It says subagentStart
cannot block creation and command preToolUse hooks fail open on timeout. Its documented pre-tool payload does not
include authenticated parent-agent identity. Those hooks alone therefore do not establish our required boundary.
We have not independently tested hook behavior in this desktop build.

The installed SDK exposes tool filters and callbacks, but we have not found a supported way to use them in the stock
desktop app for this purpose. Guidance on an existing supported mechanism would be preferable to a new one.