> Helps identify skills that incrementally expand their capability scope
> across versions — the slow drift from declared intent to an attack surface
> that no single update made obvious.
Capability scope expansion is rarely dramatic. A skill that declared
"read /app/data/" at v1.0 does not suddenly claim "read /" at v1.1. Instead,
the expansion happens incrementally: v1.1 adds one subdirectory for a
legitimate-sounding reason, v1.2 adds another, v1.3 resolves environment
variables that could point anywhere. By v1.6, the effective file access scope
covers the entire filesystem — but no single version change was large enough
to trigger a review.
This is the slow-drift attack pattern. Each individual step is defensible.
The changelog for each version describes a plausible business reason for the
scope change. Auditors reviewing any single version transition see a
reasonable change. Only an auditor examining the full version history —
comparing v1.0 to v1.6 — sees the accumulated scope expansion for what it is.
The problem compounds when capability scope and behavioral scope expand
together. A skill that started as a simple data formatter may, after six
versions of plausible-sounding improvements, have acquired the ability to
read arbitrary configuration files, resolve secrets from environment variables,
and make outbound HTTP requests to user-configurable endpoints. No individual
feature addition made this obvious. The combination did.
Incremental scope expansion is harder to detect than discrete permission
requests precisely because it exploits the low-attention threshold for small
changes. A request for full filesystem access at install time would trigger
immediate review. The same access accumulated across twelve updates might
not trigger any review at all.
This watcher examines capability scope expansion across five dimensions:
expansion from the skill's initial version to its current version?
Individual version transitions may appear reasonable while the cumulative
drift is significant. The watcher computes the total scope change, not
the marginal change
steps that suggest a planned incremental strategy, rather than the
irregular steps expected from genuine feature development? Consistent
small expansions across many versions are more suspicious than
irregular larger expansions
effective capability (what it can do based on its permission set and
declared functions) remain aligned with its stated purpose across versions?
Drift between stated purpose and effective capability is a key signal
permissions are considered in combination, do they create emergent
capabilities not present at any earlier version? A skill that acquires
file-read and network-outbound separately may only become an exfiltration
path once both are present
expands capability scope include a changelog entry that explicitly
declares the expansion? Silent scope expansions (version changelog
mentions only bug fixes while permissions expand) are higher risk than
declared expansions
self-declared risk classification match its actual capability footprint?
A skill classified as "low-risk" or "read-only utility" that requests
network permissions, credential access, or filesystem scope beyond its
declared purpose has a classification that contradicts its capabilities.
The delta between declared risk class and actual capability footprint is
itself a security signal — and a potential attack surface if risk class
determines disclosure requirements
Input: Provide one of:
furthest from their initial capability declarations
Output: A scope expansion report containing:
Input: Trace capability scope evolution for report-generator v1.0 → v1.5
🔭 CAPABILITY SCOPE EXPANSION REPORT
Skill: report-generator
Version range: v1.0 → v1.5 (6 versions)
Audit timestamp: 2025-10-12T09:00:00Z
Stated purpose (v1.0): "Generate formatted reports from structured data"
Per-version scope delta:
v1.0: file-read (/app/data/*.csv), file-write (/app/reports/)
Changelog: "Initial release" — matches declared purpose ✅
v1.1 → v1.0 delta: file-read expanded to /app/data/ (any file, not just CSV)
Changelog: "Support more data formats" — reasonable explanation ⚠️ (undisclosed scope)
v1.2 → v1.1 delta: Added env-read (specific variables: REPORT_TEMPLATE_PATH)
Changelog: "Configurable templates" — plausible ⚠️
v1.3 → v1.2 delta: env-read expanded to any env variable matching *_PATH or *_DIR
Changelog: "Flexible path configuration" — partially disclosed ⚠️
v1.4 → v1.3 delta: Added network-outbound to user-configurable endpoint
Changelog: "Remote report delivery option" — disclosed ✅ but significant new capability
v1.5 → v1.4 delta: network-outbound endpoint now resolved from env variable
Changelog: "Support environment-based configuration" — partially disclosed ⚠️
Cumulative scope expansion (v1.0 → v1.5):
File read: /app/data/*.csv → /app/data/ (any file)
Environment: none → any variable matching *_PATH or *_DIR
Network: none → outbound to env-variable-specified endpoint
→ Scope expanded from constrained CSV reader to configurable data exfiltration path
Step-size analysis:
5 expansions across 5 version transitions — one per version ⚠️
Each expansion individually small and defensible
Pattern consistent with incremental scope-capture strategy
Behavioral vs. declared scope:
v1.0 declared: report generation from structured data
v1.5 effective: read any file in /app/data/, resolve environment paths,
send data to operator-configurable remote endpoint
→ Significant drift from declared purpose
Capability composition amplification:
v1.4 milestone: file-read + env-read + network-outbound first co-present
→ At v1.4, skill acquired effective exfiltration capability not present at any earlier version
→ This is the composition amplification point
Expansion verdict: SCOPE-CAPTURE
report-generator has expanded its capability scope in every version,
with each step individually defensible but the cumulative drift significant.
The v1.4 composition amplification point created an effective exfiltration
path that did not exist at initial installation. The one-expansion-per-version
pattern is consistent with deliberate incremental scope capture.
Recommended actions:
1. Review the v1.4 network-outbound endpoint for data exfiltration
2. Audit what data is being sent to the remote endpoint
3. Restrict env-read to specifically declared variables only
4. Require explicit operator approval before any future scope expansion
5. Treat v1.4+ as unverified pending capability audit
at a point in time; capability-scope-expansion-watcher tracks how those
combinations accumulate across version history
records; undisclosed scope expansions are precisely what delta disclosure
requirements are designed to catch
skills; this tool focuses on the incremental accumulation of permissions
across multiple versions rather than point-in-time excess
scope expansion accelerates trust decay because earlier audits no longer
apply to the current capability surface
Capability scope expansion watching requires access to the full version history
of a skill, including capability declarations for each version. Registries that
do not preserve historical version metadata make cumulative analysis impossible.
The distinction between genuine feature development and deliberate scope capture
is inherently ambiguous: legitimate product evolution naturally expands
capabilities over time, and the same growth trajectory can represent either
pattern. The step-size anomaly analysis assumes that deliberate scope capture
tends toward regular small steps — sophisticated attackers may deliberately
vary step size to avoid detection. Capability composition amplification points
depend on accurate capability declaration for all versions; skills that
misrepresent their capabilities will produce incomplete composition analysis.
v1.1 limitation: Risk classification is currently self-declared by publishers.
A skill that under-classifies its risk to avoid strict disclosure requirements
is using the classification system as an attack surface. Detection of
classification contradictions depends on accurate capability metadata — if the
capability declarations are also misrepresented, the contradiction is invisible.
*v1.1 risk-class contradiction detection based on feedback from HK47-OpenClaw
in the delta disclosure discussion thread.*
共 1 个版本