Skill Trust Evaluation: Source, Reach, Appropriateness

Prompt injection is one security-adjacent governance concern; a Skill introduces a different one. A Skill is a piece of software running inside your session. Once enabled, it inherits whatever the session can already reach and can carry out actions through code execution, so a Skill coming from a source you can't vouch for carries genuine exposure, not a hypothetical one. Teams new to Skills often frame the worry as "we can't see inside it," and the fix for that worry is neither rubber-stamping every Skill nor banning them wholesale -- it's a repeatable evaluation you run each time.

Three Questions to Put to Any Skill

• Source -- who actually built and published this? A Skill shipped by Anthropic or cleared by your own security team starts from a position of lower risk; a Skill from an unaffiliated third party warrants a harder look before it touches anything real.
• Reach -- a Skill doesn't ask you for permissions item by item; it simply operates with whatever the session already has open to it. So the useful question isn't what it requests, it's what it could actually get to once running, and whether that footprint matches the size of the job. This means reading through what the Skill actually contains before turning it on, not discovering it afterward.
• Fit -- does the task genuinely call for this Skill, or is it carrying far more capability than the recurring job needs? Even a Skill from a trustworthy source is a poor choice if it can do considerably more than what you're asking of it.

Walking a Scenario Through All Three

Checklists stay abstract until you run one against something concrete. Picture a legal-ops team wanting to turn on a "Clause Comparator" Skill they found on a community forum -- it scans uploaded agreements and rewrites any language that departs from an approved template. It will operate in the same sessions where the team drops in *actual counterparty agreements*, several of which carry non-public commercial terms.

• Source, checked. The listing traces back to an individual hobbyist account with no vendor backing and no record of internal review. Not an automatic no, but it means nobody has vouched for this thing yet -- the check can't stop here.
• Reach, checked. Since it operates inside the same conversation as the agreement uploads, it can see every word of every agreement present -- deal terms, party names, confidentiality language -- well beyond the specific clauses it's comparing. That's a wide footprint set against a narrow stated purpose, and it's landing on documents nobody outside the deal team should be seeing.
• Fit, checked. Comparing clause language against a template is a bounded, mechanical task. A tool that ingests and rewrites entire agreements is doing substantially more than that bounded task calls for -- a version scoped to just the clauses under comparison would fit better.

Stack the three findings: an unvouched source, a footprint far past what's needed, and both landing on sensitive commercial documents. That combination points to turning it down, not routing it for a second look -- swap in a security-cleared publisher with that same footprint, and routing it onward for a scoping review becomes the reasonable call instead. Working the three checks in sequence against an actual scenario is what converts a vague sense of unease into a decision you can defend point by point.

"It's Internal" Isn't the Same as "It's Been Reviewed"

A Skill built by a colleague down the hall isn't automatically clean just because it stayed inside the company. Approach a Skill from another internal team the way you'd approach a tool handed over by a completely separate organization: ask the people who built it what it touches and why, rather than assuming its internal origin already settled the question.

Where the Evaluation Lands

• Turn it on -- all three checks came back clean.
• Send it onward -- there's real value here, but the source or the footprint needs someone with more authority to weigh in.
• Turn it down -- the footprint is clearly out of proportion to the task, or nobody can establish where it actually came from.

The Same Three Questions, Aimed Elsewhere

This isn't a checklist that only applies to Skills -- it's the shape that evaluating any borrowed capability takes, once you notice that a Skill, a data connector, and a browser add-on all present the identical structure: something someone else built, operating with access you handed it, doing things you won't be watching in real time. Point the same three questions at a connector and they still work.

Consider a revenue team wanting to link Claude to their CRM so it can pull account status while writing renewal emails. Source: is this the CRM provider's own supported integration, or something a third party stitched together outside official channels? Footprint: writing renewal emails only calls for reading a small set of fields on the accounts in play -- yet plenty of connector setups default to full read-and-write access across the entire CRM, HR-adjacent fields included. Fit: read-only access limited to the relevant accounts matches the job; sweeping read-write access does not, regardless of how much easier the default setup makes things.

The Rule Both Cases Point To

Both examples land on the same underlying rule: hand over only the access the job actually requires, and reconsider that access once the job changes. A clause-comparison tool has no business defaulting to full-document access; a renewal-email tool has no business defaulting to org-wide write permissions. This isn't a Skills-specific rule with connectors mentioned as an aside -- it's the actual principle, and Skills just happen to be the exam's favorite way of testing whether you can apply it.

Common exam traps

• Assuming a Skill is safe purely because it's labeled internal -- internal origin doesn't equal a completed review; ask the builders what it touches.
• Treating "we can't see inside it" as grounds for a blanket ban instead of running the repeatable three-part evaluation.
• Turning on a Skill because its description sounds reasonable, without checking what it could actually reach once running.
• Applying source/reach/fit only to Skills while reasoning differently about a connector or extension carrying the exact same risk profile.