[FEATURE] Better Permission scoping around skills and sub-agents

Resolved 💬 2 comments Opened Jan 20, 2026 by DaveLowther Closed Feb 28, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

I would like to write a skill that has access to tools without giving broad access within the session settings. This is both a feature request, and a security/guardrails request.

Proposed Solution

I would like to be able to in some way govern the access to tools that my agent has, preferably through something like skill/sub-agent scoping of permissions. If I list permissions in the tool description, I would expect them to be respected without the agent pushing for broader session level access.

Alternative Solutions

The only alternative I can see as currently viable would be abandoning skills for scripts. Letting the scripts do the work of calling the mcp servers, and gh cli and the agent just generating a pr description to pass as an argument.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

A quick example:

I'm working on a PR creation skill that interfaces with 2 mcp servers and the gh cli tool. I've written a frontmatter with the allowed tools and actions the agent can perform.

When I run the skill, I am prompted to either continually give single use access to the tools on the allowed list, or broadly allow them in my settings file. Ideally, the agent would be able to in some way understand that in the context of the skill it has access to (N) tools that it might not normally have access to.

Additional Context

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗