feat: add tool allowlist, denylist, preset list#83
Merged
JackChen-me merged 4 commits intoApr 7, 2026
Conversation
10 tasks
Member
|
Looks good overall, the three-layer resolution logic is clean. One thing missing before merge: Custom tools aren't exempted from filtering. Issue spec says "Custom tools always included regardless of filtering" and the README claims const customTools = this.options.customTools ?? []
return [...tools, ...customTools.map(t => t.toDefinition())]The Minor:
|
Member
Author
|
@JackChen-me I've just addressed the issues you mentioned. Thanks for the review. Btw, I slightly updated resolveTools in the latest commit. However, even before that, it was already exempting custom tools by appending them at the end. |
This was referenced Apr 9, 2026
This was referenced Apr 19, 2026
JackChen-me
added a commit
that referenced
this pull request
Jun 7, 2026
A no-tools agent received every registered built-in, including an unsandboxed bash, on the default path (runAgent, runTeam/runTasks, and the runTeam short-circuit). Tool output flows back to the model provider, so under prompt injection this was a remotely triggerable exec + exfiltration primitive. #83 added the allowlist/preset mechanism but kept default-allow; #264 sandboxed the filesystem tools but left bash unsandboxed; together they opened this. Built-in tools now require a positive grant via tools or toolPreset; with neither, an agent resolves to zero. resolveTools() is the chokepoint and the runner gates execution on the granted set, so a registered-but-ungranted call returns a "not granted" error instead of running. Custom/runtime tools (customTools/addTool) stay available since registration is the grant, and still honor disallowedTools. delegate_to_agent follows the same rule. Same default-deny model #87 enforces for cross-agent context. OrchestratorConfig.defaultToolPreset restores the old allow-all in one line; per-agent tools/toolPreset override it. BREAKING CHANGE: agents relying on implicit built-in tools get none until granted. Restore with defaultToolPreset: 'full', or grant per agent via tools/toolPreset.
JackChen-me
added a commit
that referenced
this pull request
Jun 7, 2026
* fix(tools)!: make built-in tools opt-in (default-deny) A no-tools agent received every registered built-in, including an unsandboxed bash, on the default path (runAgent, runTeam/runTasks, and the runTeam short-circuit). Tool output flows back to the model provider, so under prompt injection this was a remotely triggerable exec + exfiltration primitive. #83 added the allowlist/preset mechanism but kept default-allow; #264 sandboxed the filesystem tools but left bash unsandboxed; together they opened this. Built-in tools now require a positive grant via tools or toolPreset; with neither, an agent resolves to zero. resolveTools() is the chokepoint and the runner gates execution on the granted set, so a registered-but-ungranted call returns a "not granted" error instead of running. Custom/runtime tools (customTools/addTool) stay available since registration is the grant, and still honor disallowedTools. delegate_to_agent follows the same rule. Same default-deny model #87 enforces for cross-agent context. OrchestratorConfig.defaultToolPreset restores the old allow-all in one line; per-agent tools/toolPreset override it. BREAKING CHANGE: agents relying on implicit built-in tools get none until granted. Restore with defaultToolPreset: 'full', or grant per agent via tools/toolPreset. * docs: clarify defaultToolPreset excludes coordinator, synthesis, and consensus agents
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds denylist support (disallowedTools) and predefined tool presets (toolPreset) to AgentConfig, and introduces a layered tool resolution system (preset → allowlist → denylist) with validation warnings.
Why
The current default-allow model is too permissive and lacks flexibility. Agents cannot explicitly exclude tools, must manually define full allowlists, and have no built-in safety constraints.
Closes #74
Checklist
npm run lintpassesnpm testpasses