Add a read_tool action so Cedar can grant tools/list visibility without invocation #6924

Activity

1. github-actions

   added

   needs-triageIssue needs initial triage by a maintainerIssue needs initial triage by a maintainer

   on Oct 22, 2026
2. jhrozek commented on Oct 22, 2026

   

   jhrozek

   on Oct 22, 2026

   Contributor

   More actions

   Thanks for writing this up. Before anyone starts on it, there's a catch. A real read_tool action changes what some existing policies do, so it isn't purely additive.

   Take this policy set:

   permit(principal, action, resource);
   forbid(principal, action == Action::"call_tool", resource == Tool::"t");
   

   Today tools/list asks about call_tool, so the forbid applies and t is hidden. With #6903 as it stands it's still hidden, because the Cedar read check errors and the call check decides. If Cedar evaluated Action::"read_tool", the read request would match the broad permit and not the call-only forbid, so t would be listed. I checked this against the real Cedar authorizer. The same goes for unless { action == Action::"call_tool" } and any forbid that only looks at call context.

   Action groups don't get us out of it. With read_tool in call_tool, policies written as action == Action::"call_tool" still never match a read request, because == is exact. With call_tool in read_tool, a read grant would allow calls.

   So I think this needs a short design first. It should say what a call-only forbid should mean for visibility, and how existing deployments get through the change: opt-in, a migration note, or something else. Happy to look at a proposal here before any code.

   👍React with 👍1Reacted by Ranjeeth
3. aponcedeleonch

   removed

   needs-triageIssue needs initial triage by a maintainerIssue needs initial triage by a maintainer

   on Oct 23, 2026