feat: Permission-Based Tool Registry

[diiviikk5]

Fixes #65

Summary

This PR extends the ToolRegistry to integrate with the existing RBAC system, ensuring tools require appropriate permissions before they can be executed by agents or users. This addresses the security gap where dangerous tools were previously accessible without restriction.

Changes Made

• Tool Metadata: Added ToolMetadata struct with required_permission and dangerous_operations fields.
• Permission Enforcement: Updated ToolRegistry::execute and related methods to perform permission checks against the user's role before executing the tool.
• Tool Updates: Updated all existing core tools (e.g., filesystem, web, shell, spawn) to return their specific minimum PermissionLevel requirements.
• Audit Logging: Added auditing for permission checks during tool execution.
• Configuration: Added support for custom permission mappings in configuration.
• Testing: Added comprehensive unit tests for permission enforcement and registry behavior.

Related

• Depends on: Existing RBAC infrastructure in core/src/permissions.rs

Checklist

• Defined ToolMetadata with permission requirements
• Extended ToolRegistry with permission checking
• Updated all tools to declare permission requirements
• Integrated with existing RBAC system
• Added configuration for custom permission mappings
• Added unit tests for permission enforcement
• Verified no regression in existing functionality

[Copilot]

Pull request overview

Adds a permission-enforced execution layer for tools by introducing a PermissionAwareRegistry wrapper that consults RBAC (and a default per-tool role map) before allowing tool execution, with optional audit logging.

Changes:

• Introduces core/src/tools/permissions.rs with PermissionAwareRegistry, default tool permission requirements, and unit tests.
• Wires the permission-aware executor into AgentLoop when an RbacManager is configured.
• Adds ToolError::PermissionDenied and re-exports new permission-related APIs.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
core/src/tools/permissions.rs	New permission-aware registry wrapper, default tool permission mapping, audit integration, and tests.
core/src/tools/mod.rs	Exposes the new permissions module and re-exports its public types/functions.
core/src/lib.rs	Re-exports permission-aware tool registry types/functions at crate root.
core/src/error.rs	Adds a new ToolError::PermissionDenied variant for permission failures.
core/src/agent/loop_.rs	Adds RBAC/audit fields and switches tool execution to PermissionAwareRegistry when RBAC is set.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[diiviikk5]

@Nixxx19 commited new changes

[Nixxx19]

@Nixxx19 commited new changes

can you click on resolve and close the suggestion which you have implemented already? thank you!

[diiviikk5]

@Nixxx19 done , also some of the suggestions from it were not that accurate so mightve followed a different route in 1 or two places , still its a hefty one so i wont be surprised if i have to make more changes , thank you

[Nixxx19]

Thanks for the work here: the RBAC model, tests, and permission registry structure are solid.

I reviewed this with a runtime focus and found blocking issues before merge.

Blocking Findings

1) RBAC is not wired into the running agent loop

• AgentLoop only enforces via PermissionAwareRegistry when set_rbac(...) is set.
• I could not find any call to set_rbac(...) in startup flow, including CLI path.
• Result: runtime falls back to ToolRegistryExecutor (no permission gating).

2) Fine-grained checks are bypassed in default tool wiring

• Default tool registration uses ReadFileTool::new(), WriteFileTool::new(), EditFileTool::new(), ExecTool::new().
• Path/command checks (check_path_access, check_command_access) only run when tools are created with with_rbac(...).
• Current behavior applies mostly coarse "execute" checks and misses path whitelist/blacklist + safe command allowlist enforcement.

3) Fail-open behavior in RBAC manager

• Invalid resource format / unknown category / invalid min_role currently return Allowed.
• For security boundaries this should be fail-closed (or at least explicitly configurable with strict default).

[diiviikk5]

thanks for the review , was out for most of the day , will look at it !