Attach Tools to Skills as Permissions, Not Convenience
The most important thing about a tool-enabled skill is not that the model knows a tool exists. It is that the platform has deliberately decided which capability may invoke which action under which conditions.
- Read tools versus write tools
- Least-privilege skill design
- Parameter constraints
- Secret handling
- Approval-gated actions
- Auditable side effects
The situation
A skill becomes much more useful once it can act: update a record, send a message, create a document, issue a refund, run code, publish content, or change a configuration. It also becomes much more dangerous, because a reasoning error is no longer confined to a draft response.
The naive solution
Give the main agent access to every available tool and tell it to use them carefully. Individual skills can then call whichever tool seems useful.
The hidden constraint
Prompt instructions are not a strong permission boundary. If every capability inherits every tool, a summarisation task may technically have permission to send email or modify customer data. That creates unnecessary blast radius and makes reviews difficult because tool access no longer communicates intent.
The decision
Bind tool permissions to the skill. A capability gets only the tools it needs, with parameter constraints and approval rules appropriate to that responsibility.
The implementation
I separate read and write capabilities where useful. A lead-research skill may read public and CRM data but not send outreach. An outreach-drafting skill may create a draft but not transmit it. A separate approved-send action can require a human or a higher-trust workflow. I also constrain tool parameters in software where possible rather than relying on the model to remember policy.
The tradeoff
Least-privilege design creates more permission configuration and sometimes more steps for users. That friction is intentional when the alternative is giving every intelligent component broad authority over business systems.
The evidence I would look for
I would expect tool logs to map cleanly back to the skill that requested the action, privileged operations to have explicit approval evidence, and unrelated skills to be technically incapable of performing sensitive actions.
The reusable lesson
A skill is a natural security boundary. If the capability does not need an action to fulfil its responsibility, do not give it that action.
The consultant's questions
- What is the most damaging thing this skill can currently do with its tool access?
- Does a read-only task accidentally inherit write permissions?
- Which tool parameters should be enforced by code rather than model instruction?
- Where should a draft end and an irreversible action begin?