- In short
- Skill trust evaluation vets a Skill before enabling it, the way you would vet any new software, on three questions: SOURCE (who published it - Anthropic-provided or internally-approved Skills are the lower-risk starting point), REACH (what it could reach in the sessions where it runs, since Skills do not request permissions but inherit the session's existing access), and APPROPRIATENESS (whether its actual capability is proportional to the job). A Skill is software: it can access whatever the session has and act through code execution.
A Skill is software, so vet it like software
The single most important thing the CCAO-F exam wants you to hold about Skills is that a Skill is software. It runs procedures, it can touch the data and tools available in a session, and it can take actions through code execution. That reframing changes everything: a Skill from an untrusted source is not a harmless convenience but a real risk, in the same category as any program you might install on a work machine. And the practical answer to that risk is not blind trust and not blanket bans - it is a repeatable source-and-permissions check before you enable it.
The evaluation rests on three questions - source, reach, and appropriateness - that together tell you whether you know what the Skill does and whether its access matches the job. This knowledge point is about running those three questions well; the three outcomes they lead to come next.
- Skill trust evaluation
- A pre-enable check applied to a Skill the way you would to any new software, on three questions. SOURCE: who published it - Anthropic-provided or internally-approved Skills are the lower-risk starting point; an unknown third-party Skill demands more scrutiny. REACH: what could it touch in the sessions where it runs, given that Skills do not request permissions but inherit the session's existing access. APPROPRIATENESS: is its actual capability proportional to the task, or more than the job needs.
Source: who published it
The first question is who published the Skill, because provenance is the strongest early signal of risk. Anthropic-provided Skills and internally-approved Skills are the lower-risk starting point: someone with standing has stood behind them. An unknown third-party Skill - one found in a public forum, say - demands more scrutiny precisely because no trusted party has vouched for it.
Source is not a simple binary, though, and one part of the auditing goes beyond the publisher's name. You also audit the bundle's contents - the Skill's instructions, dependencies, and bundled files - before enabling, because that is where the Skill's real behavior lives. A formatting Skill whose instructions roam far beyond formatting is a red flag no matter who published it. Judging a Skill safe purely from its description, without looking at what it actually contains, is a shortcut that defeats the source check.
Reach: what it can touch
The second question is the one people most often get wrong, and it turns on a crucial fact: Skills do not request permissions. Unlike an app that asks for specific scopes, a Skill inherits whatever access the session it runs in already has. There is no permission prompt that narrows it to its stated task. So you cannot ask "what permissions did it request" - there is no such thing to read - and you certainly cannot assume it is limited to only what its task needs.
Instead you ask: what could this Skill reach in the sessions where it will run, and is that exposure proportional to the task? If the Skill runs in sessions with access to sensitive data or powerful tools, its reach is that entire surface, because it inherits it. Reach is therefore a property of the session as much as the Skill, and evaluating it means thinking about where the Skill will actually run and what that context exposes.
Appropriateness: proportional to the job
The third question is whether the Skill is the right tool for the task at all, or more capability than the job needs. A Skill can be from a fine source and still be inappropriate because it does far more than the task requires - and every bit of extra capability is extra surface for something to go wrong.
Appropriateness is the proportionality check. It asks not "is this Skill useful in general" but "does this specific Skill's capability match this specific need." A narrow tool for a narrow job is proportional; a broad, powerful tool enabled for a small task is not, even if it would work. This is the same least-privilege instinct that extends to connectors and integrations: grant the narrowest capability that gets the job done.
What the exam trips candidates on
The first trap is believing a Skill requests or is limited to only the permissions its stated task needs. This is the reach misconception, and it is the most tested idea here. Skills do not request permissions; they inherit the session's access. An answer that assumes a meeting-notes Skill can only touch meeting notes has the model exactly wrong.
The second trap is judging a Skill safe purely from its description without auditing its bundled instructions and dependencies. A description is a claim, not evidence. The credited approach inspects what the Skill actually contains - its instructions and dependencies - and treats a mismatch between the stated purpose and the actual bundle as a red flag.
Worked example
A colleague shares a Skill they found in a public forum that 'converts meeting notes into summaries.' They say it is obviously safe because summarizing notes is harmless and it only needs the notes. Run the three-question evaluation.
Source. The Skill comes from an unknown publisher in a public forum - not Anthropic-provided, not internally approved. That places it in the higher-scrutiny category from the start. And the description alone is not enough: you would audit the bundle's instructions and dependencies before trusting it, because a "summarizer" whose instructions reach beyond summarizing is a warning sign.
Reach. Here the colleague's reasoning fails outright. They assume the Skill "only needs the notes," but Skills do not request permissions - once enabled, this Skill runs with whatever access the session already has, and nothing in its bundled instructions limits it to meeting notes. So its reach is the full access of the sessions where it runs, not a tidy notes-only scope. That is the exact misconception the exam probes.
Appropriateness. Even setting reach aside, you would ask whether this particular Skill is proportional to the task. A simple summarization need does not justify enabling an unvetted, broadly-capable tool from an unknown source.
Putting the three together: unknown source, session-wide reach it inherits rather than requests, and no reason to trust its proportionality. The colleague's "obviously safe" conclusion rests on the assumption that the Skill is limited to its stated task - which is precisely what Skills are not. This is not an enable on individual authority; it is a case for organizational review, which the next knowledge point frames as one of three outcomes.
Common misreadings to avoid
Misconception
A Skill only has access to what its stated task needs, because it requests those permissions.
What's actually true
Misconception
If a Skill's description says it does something harmless, it is safe to enable.
What's actually true
How this shows up on the exam
Domain 6 questions on this knowledge point present a Skill and ask whether or how to trust it. The reliable move is to run source, reach, and appropriateness, and above all to apply the reach fact - Skills inherit the session's access rather than requesting a task-scoped subset. Reject any answer built on "it only needs / can only touch its stated task."
This evaluation feeds directly into the three trust outcomes - enable, escalate, or decline - and its source question is exactly what the internal-source fallacy complicates, since "internal" is not the same as "vetted." The same three questions generalize to least privilege across features and connectors.
Before enabling a third-party Skill that formats documents, what is the most important thing to understand about its access?
People also ask
How do you evaluate whether a Skill is safe to enable?
Do Skills request only the permissions they need?
What can a Skill access once enabled?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.