Collect evidence first, compare declared and actual capability next, and only then generate the install recommendation. The goal is not a prettier score. It is a more actionable decision.
BLOCK REVIEW ALLOW
Trust Methodology We are not guessing at a risk score.
We are not guessing at a risk score.
We are assembling an install decision.
A useful AI skill trust review has to answer three things: what the skill claims to do, what it actually does, and whether the evidence is strong enough to block, review, or allow it. ClawSafe is organized around those questions.
Evidence first
File tree, artifacts, IOCs, dependencies, and declared scope land before semantic judgment.
Capability diff
Declared scope and actual behavior are compared side by side to surface drift and hidden execution.
Actionable output
The result is meant to flow into approvals, gates, and audit trails.
Decision flow
Every scan follows the same evidence chain: get the facts first, make the behavioral judgment next, and end in an installation recommendation.
Input normalization
Accept GitHub, ClawHub, archives, or local files and normalize them into one file tree.
Static evidence extraction
Read file structure, sensitive files, artifacts, language mix, dependencies, and declared metadata.
Capability and intent reasoning
Compare declared scope with actual behavior to surface drift, hidden execution, egress, and attack chains.
Install recommendation
Output block, review, or allow with the evidence needed to justify that recommendation.
Signals we care about most
If the skill claims to “analyze code” but actually wants shell, network, or home-directory access, trust drops quickly.
This includes encoded execution, dangerous command composition, remote download-and-run patterns, and documentation that steers the model into undeclared actions.
External URLs, suspicious domains, hard-coded IPs, credential patterns, and data-export paths are treated as high-weight trust signals.
Unpinned packages, vulnerable dependencies, external scripts, and install-time behavior all change the final recommendation.
What a report should contain
01
An installation recommendation, not just a number.
02
Key reasons and evidence, not generic threat language.
03
Declared-versus-actual capability so drift becomes obvious.
04
Attack chains, artifacts, dependencies, and file snapshots for review and sharing.
Where this method stops
!
It is not a runtime sandbox and does not replace live execution monitoring.
!
It gives you a high-quality install decision input, not a transfer of final responsibility.
!
“Pass” means there is not enough evidence to block right now, not that the skill is absolutely safe.
!
Heavy obfuscation, multi-stage downloads, and strong context dependency can still create false negatives.
Next Action