Skip to content

feat(security): per-tool blocking for unsafe tools (#1623) - #1719

Open
vrindabhandari wants to merge 8 commits into
agentic-community:mainfrom
vrindabhandari:feat/1623-per-tool-blocking
Open

feat(security): per-tool blocking for unsafe tools (#1623)#1719
vrindabhandari wants to merge 8 commits into
agentic-community:mainfrom
vrindabhandari:feat/1623-per-tool-blocking

Conversation

@vrindabhandari

@vrindabhandari vrindabhandari commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Closes #1623 (backend enforcement; UI to follow)

What this does

Implements opt-in per-tool blocking per the behavior model in the issue. When allow_unsafe_servers is enabled, a server with HIGH/CRITICAL findings registers as enabled with its unsafe tools individually blocked, rather than the whole server being disabled. Default-off, so existing deployments are unaffected.

  • Config flag + ToolOverride schema
  • Repository methods for per-tool overrides
  • set_tool_blocked service method with Mongo key validation
  • Scan reconciliation: auto-blocks reapply on rescan, admin decisions survive
  • POST /toggle-tool/{service_path} admin route
  • Enforcement on tools/call (403 for blocked tools)

Scope

Backend enforcement only. Agreed with @aarora79 to land this first and do the UI as a separate PR. Deliberately left for that follow-up:

  • CLI methods for per-tool blocks
  • include_blocked flagging on GET /api/tools
  • Auto-block wiring at registration time
  • Frontend per-tool toggle

Known limitation: rename evasion

Blocks are keyed on tool name. A server that renames a blocked tool presents a name that isn't in the blocklist, so it passes both the tools/list filter and tools/call enforcement until the next scan reconciles. Auto-blocks self-heal on
rescan; admin-set blocks are the exposed case.

Raised by @Santoshkumarpuppala on the issue. His content-hash suggestion includes the tool name in the hash, which a rename also changes — so it matches on neither name nor hash. The stronger version is his second point: treat an unrecognized tool name on a server that already has scan state as unscanned and fail closed. The tool then doesn't need to match a block, it needs to have been scanned, which closes the rename path regardless of the tool body. Consistent with the fail-closed posture already in validate_server_tool_access.

Testing

TestToggleTool and TestReconcileSecurityBlocks cover the route and the reconciliation matrix (auto-block applied, stale auto-block cleared, admin block survives clean rescan, admin unblock not re-blocked). Merged current main; full suite green (7389 passed, 31 skipped).

@vrindabhandari
vrindabhandari marked this pull request as ready for review September 2, 2026 23:52
@codecov-commenter

Copy link
Copy Markdown

⚠️ Please install the 'codecov app svg image' to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 50.00000% with 68 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
registry/services/server_service.py 58.92% 14 Missing and 9 partials ⚠️
...istry/repositories/documentdb/server_repository.py 21.42% 22 Missing ⚠️
auth_server/server.py 33.33% 11 Missing and 1 partial ⚠️
registry/api/server_routes.py 57.69% 6 Missing and 5 partials ⚠️

📢 Thoughts on this report? Let us know!

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.

Feature request: Per-tool blocking and enable/disable toggles

2 participants