Repository navigation
Allow approved plugin MCP tools in private automation runs #4997
Replies: 3 comments
|
Could the approval bind to the workspace, plugin identity and exact allowed tools, and expire when that configuration changes? I would test an automation approved for read-only findings, then update the plugin to add administrative tools: the next run should retain no implicit access to those additions. This preserves the restriction you describe without creating a Kanban task. AI-assisted proposal. |
|
We plan to add an optional plugin-tool checklist to the existing private automation editor. Saving the selection will approve exact tools for that automation and workspace, including selected report-writing tools. Plugins must explicitly support the automation surface. Plugin updates or configuration saves will require the tools to be selected again, so newly added tools never gain implicit access. Core administrative restrictions and hidden automation history stay in place. No extra approval workflow or Kanban tasks. |
Uh oh!
There was an error while loading. Please reload this page.
Private automation runs (automation_run) cannot access plugin MCP tools. This prevents scheduled jobs from using plugins such as Kandev Security to read findings or submit security reports.
Please support explicitly approved, workspace-scoped plugin tools while preserving the automation surface’s restrictions on administrative operations.
Creating a normal workflow task works around this, but adds tasks to Kanban for jobs that should remain in automation history.
Related: PR #2943 and the automation authority decision.
All reactions