Skip to content

feat: add tool surface filtering via env vars#17

Open
alex-feel wants to merge 1 commit into
EmpatDevelopment:mainfrom
alex-feel:alex-feel-dev
Open

feat: add tool surface filtering via env vars#17
alex-feel wants to merge 1 commit into
EmpatDevelopment:mainfrom
alex-feel:alex-feel-dev

Conversation

@alex-feel

Copy link
Copy Markdown

What & why

Add startup-time tool surface filtering controlled by two optional environment variables: PEOPLEFORCE_ENABLED_TOOLS (allowlist) and PEOPLEFORCE_DISABLED_TOOLS (denylist). Both accept comma-separated, case-insensitive tool names with the peopleforce_ prefix optional. When unset, all 28 tools remain exposed (no behavior change).

The filter pipeline applies allow-then-deny composition: tools listed in the allowlist form a candidate set (or all tools when unset), then the denylist subtracts from that set. Unknown tokens log a WARN to stderr and are ignored; an empty result fail-fasts with process.exit(1) and an actionable error.

Both ListToolsRequestSchema and CallToolRequestSchema handlers consult the same filtered exposedTools array, so a disabled tool can be neither listed nor invoked. This structurally mitigates the CVE-2026-46519 / CWE-863 failure mode where filtering applied only at tools/list left tools/call open.

Add five stdio smoke tests covering denylist removal, allowlist narrowing, allow+deny composition with prefix-less and case-insensitive tokens, WARN-and-continue on unknown deny tokens, and the zero-exposed exit-1 guard.

Update README.md with a new "Restricting the tool surface" section, .env.example with the two new variables, CHANGELOG.md under Unreleased, CONTRIBUTING.md to note that new tools automatically participate in filtering with no code change required, and SECURITY.md to recommend denylisting peopleforce_api_request in least-privilege deployments. Bump package.json description tool count from 27 to 28 to match the actual exposed surface.

Type of change

  • Bug fix (non-breaking)
  • New tool (non-breaking read-only addition)
  • New workflow tool or refactor
  • Docs / examples only
  • CI / build / tests only
  • Breaking change (describe below)

Checklist

  • npm run typecheck passes locally
  • npm test passes locally (all 9+ tests)
  • npm run build produces a valid dist/index.js
  • npm run lint passes (or has no new warnings introduced)
  • If I added a tool, it is listed in the server manifest test (test/server.test.ts)
  • CHANGELOG.md updated under ## [Unreleased]
  • README / examples updated if user-facing behaviour changed
  • No API keys, employee PII, or internal IDs included in code, tests, docs, or commit messages

Add startup-time tool surface filtering controlled by two optional environment variables: PEOPLEFORCE_ENABLED_TOOLS (allowlist) and PEOPLEFORCE_DISABLED_TOOLS (denylist).
Both accept comma-separated, case-insensitive tool names with the peopleforce_ prefix optional.
When unset, all 28 tools remain exposed (no behavior change).

The filter pipeline applies allow-then-deny composition: tools listed in the allowlist form a candidate set (or all tools when unset), then the denylist subtracts from that set.
Unknown tokens log a WARN to stderr and are ignored; an empty result fail-fasts with process.exit(1) and an actionable error.

Both ListToolsRequestSchema and CallToolRequestSchema handlers consult the same filtered exposedTools array, so a disabled tool can be neither listed nor invoked.
This structurally mitigates the CVE-2026-46519 / CWE-863 failure mode where filtering applied only at tools/list left tools/call open.

Add five stdio smoke tests covering denylist removal, allowlist narrowing, allow+deny composition with prefix-less and case-insensitive tokens, WARN-and-continue on unknown deny tokens, and the zero-exposed exit-1 guard.

Update README.md with a new "Restricting the tool surface" section, .env.example with the two new variables, CHANGELOG.md under Unreleased, CONTRIBUTING.md to note that new tools automatically participate in filtering with no code change required, and SECURITY.md to recommend denylisting peopleforce_api_request in least-privilege deployments.
Bump package.json description tool count from 27 to 28 to match the actual exposed surface.
@alex-feel alex-feel requested a review from igorepeta as a code owner June 2, 2026 15:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant