feat(budget): implement safety profile enforcement for tool access control #8983

Open
opened 2026-04-14 04:35:10 +00:00 by HAL9000 · 1 comment
Owner

Background and Context

Part of Epic #5178 (Cost & Session Budget Enforcement). Safety profiles are named configurations that restrict which tools are available during plan execution. Without safety profiles, any plan can invoke any tool regardless of the operational context — a risk in production or sensitive environments. Safety profiles allow operators to define allow-lists and deny-lists of tools per profile (e.g., read-only, no-network, sandboxed), and automation profiles can reference a safety profile to enforce those restrictions at runtime.

The Epic body explicitly lists safety profile enforcement as a required deliverable alongside CostTracker (#5248), budget enforcement (#5249), and cost reporting (#5250). This is the only item from the Epic's scope not yet covered by an existing child issue.

Acceptance Criteria

  • SafetyProfile model defined with allowed_tools and denied_tools fields (allow-list takes precedence over deny-list)
  • Safety profile configuration loadable from automation profile YAML (e.g., safety_profile: read-only)
  • Built-in profiles provided: unrestricted (default), read-only (no write/delete tools), no-network (no HTTP/external tools), sandboxed (only local read tools)
  • PlanExecutor enforces safety profile: raises ToolAccessDeniedError when a plan attempts to invoke a denied tool
  • ToolAccessDeniedError includes the tool name, the active profile name, and a human-readable reason
  • Safety profile violations are logged and surfaced in agents plan status output
  • Unit tests (Behave) cover allow-list, deny-list, and built-in profile scenarios
  • Integration test (Robot) verifies that a read-only profile blocks a write tool invocation end-to-end

Subtasks

  • Define SafetyProfile dataclass/model with allowed_tools: list[str] | None and denied_tools: list[str] fields
  • Implement built-in profiles: unrestricted, read-only, no-network, sandboxed
  • Add safety_profile field to automation profile YAML schema and Settings
  • Implement SafetyProfileEnforcer service that checks tool invocations against the active profile
  • Integrate SafetyProfileEnforcer into PlanExecutor before each tool call
  • Define and raise ToolAccessDeniedError with tool name, profile name, and reason
  • Surface safety profile violations in agents plan status output
  • Tests (Behave): Add scenarios for allow-list enforcement, deny-list enforcement, and each built-in profile
  • Tests (Robot): Add integration test for read-only profile blocking a write tool
  • Verify coverage >= 97% via nox -s coverage_report
  • Run nox (all default sessions), fix any errors

Definition of Done

  • All acceptance criteria met
  • Tests written and passing (coverage >= 97%)
  • Code reviewed and approved
  • Documentation updated if needed
  • No regressions introduced

Metadata

  • Commit message: feat(budget): implement safety profile enforcement for tool access control
  • Branch name: feat/v3.6.0/safety-profile-enforcement

Automated by CleverAgents Bot
Agent: new-issue-creator

## Background and Context Part of Epic #5178 (Cost & Session Budget Enforcement). Safety profiles are named configurations that restrict which tools are available during plan execution. Without safety profiles, any plan can invoke any tool regardless of the operational context — a risk in production or sensitive environments. Safety profiles allow operators to define allow-lists and deny-lists of tools per profile (e.g., `read-only`, `no-network`, `sandboxed`), and automation profiles can reference a safety profile to enforce those restrictions at runtime. The Epic body explicitly lists safety profile enforcement as a required deliverable alongside `CostTracker` (#5248), budget enforcement (#5249), and cost reporting (#5250). This is the only item from the Epic's scope not yet covered by an existing child issue. ## Acceptance Criteria - [ ] `SafetyProfile` model defined with `allowed_tools` and `denied_tools` fields (allow-list takes precedence over deny-list) - [ ] Safety profile configuration loadable from automation profile YAML (e.g., `safety_profile: read-only`) - [ ] Built-in profiles provided: `unrestricted` (default), `read-only` (no write/delete tools), `no-network` (no HTTP/external tools), `sandboxed` (only local read tools) - [ ] `PlanExecutor` enforces safety profile: raises `ToolAccessDeniedError` when a plan attempts to invoke a denied tool - [ ] `ToolAccessDeniedError` includes the tool name, the active profile name, and a human-readable reason - [ ] Safety profile violations are logged and surfaced in `agents plan status` output - [ ] Unit tests (Behave) cover allow-list, deny-list, and built-in profile scenarios - [ ] Integration test (Robot) verifies that a `read-only` profile blocks a write tool invocation end-to-end ## Subtasks - [ ] Define `SafetyProfile` dataclass/model with `allowed_tools: list[str] | None` and `denied_tools: list[str]` fields - [ ] Implement built-in profiles: `unrestricted`, `read-only`, `no-network`, `sandboxed` - [ ] Add `safety_profile` field to automation profile YAML schema and `Settings` - [ ] Implement `SafetyProfileEnforcer` service that checks tool invocations against the active profile - [ ] Integrate `SafetyProfileEnforcer` into `PlanExecutor` before each tool call - [ ] Define and raise `ToolAccessDeniedError` with tool name, profile name, and reason - [ ] Surface safety profile violations in `agents plan status` output - [ ] Tests (Behave): Add scenarios for allow-list enforcement, deny-list enforcement, and each built-in profile - [ ] Tests (Robot): Add integration test for `read-only` profile blocking a write tool - [ ] Verify coverage >= 97% via `nox -s coverage_report` - [ ] Run `nox` (all default sessions), fix any errors ## Definition of Done - [ ] All acceptance criteria met - [ ] Tests written and passing (coverage >= 97%) - [ ] Code reviewed and approved - [ ] Documentation updated if needed - [ ] No regressions introduced ## Metadata - **Commit message:** `feat(budget): implement safety profile enforcement for tool access control` - **Branch name:** `feat/v3.6.0/safety-profile-enforcement` --- **Automated by CleverAgents Bot** Agent: new-issue-creator
HAL9000 added this to the v3.6.0 milestone 2026-04-14 04:39:37 +00:00
Author
Owner

Verified — Safety profile enforcement for tool access control is a v3.6.0 governance feature. MoSCoW: Should-have. Priority: Medium.


Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner-pool-supervisor

✅ **Verified** — Safety profile enforcement for tool access control is a v3.6.0 governance feature. MoSCoW: Should-have. Priority: Medium. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner-pool-supervisor
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
cleveragents/cleveragents-core#8983
No description provided.