Feature Request: Tool blacklist/deny for agent specialization in multi-agent workflows

[coryzibell]

Summary

Currently, custom agents support whitelisting tools via allowed_tools in YAML frontmatter. This works well for highly constrained agents, but for multi-agent orchestration patterns, the inverse is often more practical: allow everything EXCEPT specific tools.

Use Case

In multi-agent architectures, orchestrator agents often need broad capabilities but should delegate certain specialized tasks to sub-agents rather than handling them directly.

Example: An orchestrator agent should be able to read files, run bash, search code, etc., but should NOT directly use gh commands - those should be delegated to a GitHub-specialist agent who has better context for that domain.

Current workaround: Whitelist every tool except the ones you want to exclude. This is brittle and requires updating whenever new tools are added.

Desired: denied_tools or similar that excludes specific tools while allowing everything else.

Proposed Schema

Building on the discussion in #4380 (specifically this comment), something like:

---
denied_tools:
  - gh
  - Task
---

Or the more expressive allow/deny/ask model:

{
  "permissions": {
    "allow": ["*"],
    "deny": ["gh", "mcp__github"]
  }
}

Benefits

1. Encourages delegation - Agents naturally route specialized tasks to specialists
2. Simpler configuration - No need to enumerate all allowed tools
3. Future-proof - New tools automatically available unless explicitly denied
4. Better orchestration patterns - Supports hierarchical agent architectures

Related Issues

• Feature: Per-agent MCP tool filtering to improve agent focus and accuracy #4380 - Per-agent MCP tool filtering
• Implement Agent-Scoped MCP Configuration with Strict Isolation #4476 - Agent-Scoped MCP Configuration
• Allow MCP tools to be available only to subagent #6915 - MCP tools available only to subagent

Those issues focus primarily on whitelisting. This request specifically addresses the blacklist/deny case for orchestration workflows.

---

Happy to provide more detailed examples of multi-agent workflows where this pattern would help.

[github-actions]

Found 2 possible duplicate issues:

1. Allow MCP tools to be available only to subagent #6915
2. Implement Agent-Scoped MCP Configuration with Strict Isolation #4476

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[coryzibell]

👎

This is not a duplicate. Let me clarify the distinction:

#6915 and #4476 focus on whitelisting/allow-only patterns:

• "Allow MCP tools to be available only to subagent"
• "Agent-Scoped MCP Configuration" (primarily about isolating which tools are available)

This issue specifically requests the inverse: deny/blacklist support.

The difference matters for orchestration workflows:

Pattern	Use Case	Config Complexity
Whitelist	"Agent can ONLY use X, Y, Z"	Must enumerate all allowed tools
Blacklist	"Agent can use everything EXCEPT A, B"	Surgical exclusion

For orchestrator agents that need broad capabilities minus a few specialized tools (to encourage delegation), blacklisting is significantly more practical than maintaining exhaustive whitelists.

I reviewed the linked issues - blacklisting is mentioned only once, in a comment on #4380, with no maintainer response.

This request is specifically about adding denied_tools or equivalent to complement the existing allowed_tools whitelist pattern.

[coryzibell]

Addendum: Skills Too

Just confirmed that subagents inherit skill access from parent. This means the deny/blacklist pattern should apply to both:

---
denied_tools:
  - gh
  - Task
denied_skills:
  - commit
  - review-pr
---

Use case: An agent that can use most capabilities but shouldn't directly invoke certain skills (should delegate those to specialists instead).

Same rationale as tools - surgical exclusion is more practical than exhaustive whitelisting for orchestration patterns.