Summary

Add the ability to configure tool allow/deny policies at the group level, not just the agent level.

Current Behavior

Tool restrictions are configured per-agent:

{
  agents: {
    list: [{
      id: "my-bot",
      tools: {
        allow: ["read", "message"],
        deny: ["exec", "write", "browser"]
      }
    }]
  }
}

To have different tool access for different groups, you must:

1. Create multiple agents with different tool profiles
2. Use bindings to route each group to the appropriate agent

Proposed Behavior

Allow tool policies to be specified per-group within channels.*.groups:

{
  channels: {
    whatsapp: {
      groups: {
        "[email protected]": {
          requireMention: true,
          tools: {
            allow: ["read", "write", "exec", "browser"],
            deny: []
          }
        },
        "[email protected]": {
          requireMention: true,
          tools: {
            allow: ["read", "message"],
            deny: ["exec", "write", "browser", "gateway"]
          }
        },
        "*": {
          requireMention: true,
          tools: {
            allow: ["read"],
            deny: ["exec", "write", "browser", "gateway", "nodes"]
          }
        }
      }
    }
  }
}

Use Cases

1. Trusted internal group — Full tool access for a team workspace
2. Semi-trusted partner group — Read + messaging tools only
3. Public/open groups — Minimal tools, no filesystem/shell access
4. Default fallback — Restrictive baseline for any unlisted group

Why This Matters

The current workaround (multiple agents + bindings) works but adds complexity:

• Each agent needs its own config, workspace, potentially auth
• Bindings scale poorly with many groups
• Mental overhead of mapping "which agent handles which group"

Per-group tool policies would keep a single agent while varying permissions by context — closer to how admins think about access control.

Alternatives Considered

1. Multi-agent bindings — Works today, but complex
2. Sandbox tool policies for non-main — Gives one "restricted" tier, but no granularity between groups
3. groupAllowFrom — Controls who triggers, not what tools they can use

Additional Context

This would complement existing group config options (requireMention, groupAllowFrom) and fit naturally in the channels.*.groups.* schema.