[Question] Subagent Spawn Permission Control

Problem

There's no way to restrict which subagents an agent can spawn. This creates security issues in multi-tenant environments.

Current SubagentsConfig only has:

{
  maxConcurrent?: number;
  maxSpawnDepth?: number;
  maxChildrenPerAgent?: number;
  // No allowedAgents or deniedAgents fields
}

Use case:

• sales-agent should only spawn inventory-specialist and reporting-specialist
• sales-agent should NOT spawn hr-agent or finance-agent (sensitive data)

Current workarounds don't work:

• ❌ AGENTS.md instructions = soft enforcement, LLM can be jailbroken
• ❌ Tool Policy deny spawn = too restrictive, blocks ALL spawning
• ❓ Agent Links = exists in code but no UI/docs

Proposed Solution

Add whitelist/blacklist to SubagentsConfig:

export interface SubagentsConfig {
  // ... existing fields
  allowedAgents?: string[];   // Whitelist
  deniedAgents?: string[];    // Blacklist
}

With backend validation before spawn.

Questions

1. Is AgentLinkData meant for this? If yes, where's the UI and how do we use it?
2. Would you accept a PR to add allowedAgents/deniedAgents?
3. What's the recommended pattern for spawn access control?

Context

Critical for production deployments with sensitive data. Soft enforcement via prompts is insufficient for security.

Source: ui/web/src/types/agent.ts

Start with ui/web/src/types/agent.ts and inspect the existing AgentLinkData references, then trace the backend spawn-validation path. Clarify how Agent Links, allowlists, and denylists should interact before changing the configuration. Done means the accepted access-control behavior is documented and enforced before a subagent is spawned, with coverage for permitted and denied agents.