\r \r

Your Skill Started with File Read. Now It Has the Whole Filesystem.\r

\r

Helps identify skills that incrementally expand their capability scope\r across versions — the slow drift from declared intent to an attack surface\r that no single update made obvious.\r \r

Problem\r

\r Capability scope expansion is rarely dramatic. A skill that declared\r "read /app/data/" at v1.0 does not suddenly claim "read /" at v1.1. Instead,\r the expansion happens incrementally: v1.1 adds one subdirectory for a\r legitimate-sounding reason, v1.2 adds another, v1.3 resolves environment\r variables that could point anywhere. By v1.6, the effective file access scope\r covers the entire filesystem — but no single version change was large enough\r to trigger a review.\r \r This is the slow-drift attack pattern. Each individual step is defensible.\r The changelog for each version describes a plausible business reason for the\r scope change. Auditors reviewing any single version transition see a\r reasonable change. Only an auditor examining the full version history —\r comparing v1.0 to v1.6 — sees the accumulated scope expansion for what it is.\r \r The problem compounds when capability scope and behavioral scope expand\r together. A skill that started as a simple data formatter may, after six\r versions of plausible-sounding improvements, have acquired the ability to\r read arbitrary configuration files, resolve secrets from environment variables,\r and make outbound HTTP requests to user-configurable endpoints. No individual\r feature addition made this obvious. The combination did.\r \r Incremental scope expansion is harder to detect than discrete permission\r requests precisely because it exploits the low-attention threshold for small\r changes. A request for full filesystem access at install time would trigger\r immediate review. The same access accumulated across twelve updates might\r not trigger any review at all.\r \r

What This Watches\r

\r This watcher examines capability scope expansion across five dimensions:\r \r

1. Cumulative permission drift — What is the total permission scope\r expansion from the skill's initial version to its current version?\r Individual version transitions may appear reasonable while the cumulative\r drift is significant. The watcher computes the total scope change, not\r the marginal change\r \r
2. Step-size anomalies — Is the expansion occurring in regular small\r steps that suggest a planned incremental strategy, rather than the\r irregular steps expected from genuine feature development? Consistent\r small expansions across many versions are more suspicious than\r irregular larger expansions\r \r
3. Behavioral scope vs. declared scope alignment — Does the skill's\r effective capability (what it can do based on its permission set and\r declared functions) remain aligned with its stated purpose across versions?\r Drift between stated purpose and effective capability is a key signal\r \r
4. Capability composition amplification — When the skill's accumulated\r permissions are considered in combination, do they create emergent\r capabilities not present at any earlier version? A skill that acquires\r file-read and network-outbound separately may only become an exfiltration\r path once both are present\r \r
5. Changelog completeness for scope changes — Does each version that\r expands capability scope include a changelog entry that explicitly\r declares the expansion? Silent scope expansions (version changelog\r mentions only bug fixes while permissions expand) are higher risk than\r declared expansions\r \r
6. Risk-class contradiction detection (v1.1) — Does the skill's\r self-declared risk classification match its actual capability footprint?\r A skill classified as "low-risk" or "read-only utility" that requests\r network permissions, credential access, or filesystem scope beyond its\r declared purpose has a classification that contradicts its capabilities.\r The delta between declared risk class and actual capability footprint is\r itself a security signal — and a potential attack surface if risk class\r determines disclosure requirements\r \r

How to Use\r

\r Input: Provide one of:\r

• A skill identifier to trace its capability scope evolution across versions\r
• A specific version range to assess cumulative expansion over a period\r
• An agent's installed skill list to identify which skills have drifted\r furthest from their initial capability declarations\r \r Output: A scope expansion report containing:\r
• Per-version permission delta (declared and observed)\r
• Cumulative scope expansion since initial version\r
• Step-size pattern analysis\r
• Behavioral scope alignment assessment\r
• Capability composition amplification points\r
• Changelog completeness for scope-changing versions\r
• Expansion verdict: STABLE / DRIFT / INCREMENTAL-EXPANSION / SCOPE-CAPTURE\r \r

Example\r

\r Input: Trace capability scope evolution for report-generator v1.0 → v1.5\r \r

🔭 CAPABILITY SCOPE EXPANSION REPORT\r
\r
Skill: report-generator\r
Version range: v1.0 → v1.5 (6 versions)\r
Audit timestamp: 2025-10-12T09:00:00Z\r
\r
Stated purpose (v1.0): "Generate formatted reports from structured data"\r
\r
Per-version scope delta:\r
\r
v1.0: file-read (/app/data/*.csv), file-write (/app/reports/)\r
  Changelog: "Initial release" — matches declared purpose ✅\r
\r
v1.1 → v1.0 delta: file-read expanded to /app/data/ (any file, not just CSV)\r
  Changelog: "Support more data formats" — reasonable explanation ⚠️ (undisclosed scope)\r
\r
v1.2 → v1.1 delta: Added env-read (specific variables: REPORT_TEMPLATE_PATH)\r
  Changelog: "Configurable templates" — plausible ⚠️\r
\r
v1.3 → v1.2 delta: env-read expanded to any env variable matching *_PATH or *_DIR\r
  Changelog: "Flexible path configuration" — partially disclosed ⚠️\r
\r
v1.4 → v1.3 delta: Added network-outbound to user-configurable endpoint\r
  Changelog: "Remote report delivery option" — disclosed ✅ but significant new capability\r
\r
v1.5 → v1.4 delta: network-outbound endpoint now resolved from env variable\r
  Changelog: "Support environment-based configuration" — partially disclosed ⚠️\r
\r
Cumulative scope expansion (v1.0 → v1.5):\r
  File read: /app/data/*.csv → /app/data/ (any file)\r
  Environment: none → any variable matching *_PATH or *_DIR\r
  Network: none → outbound to env-variable-specified endpoint\r
  → Scope expanded from constrained CSV reader to configurable data exfiltration path\r
\r
Step-size analysis:\r
  5 expansions across 5 version transitions — one per version ⚠️\r
  Each expansion individually small and defensible\r
  Pattern consistent with incremental scope-capture strategy\r
\r
Behavioral vs. declared scope:\r
  v1.0 declared: report generation from structured data\r
  v1.5 effective: read any file in /app/data/, resolve environment paths,\r
    send data to operator-configurable remote endpoint\r
  → Significant drift from declared purpose\r
\r
Capability composition amplification:\r
  v1.4 milestone: file-read + env-read + network-outbound first co-present\r
  → At v1.4, skill acquired effective exfiltration capability not present at any earlier version\r
  → This is the composition amplification point\r
\r
Expansion verdict: SCOPE-CAPTURE\r
  report-generator has expanded its capability scope in every version,\r
  with each step individually defensible but the cumulative drift significant.\r
  The v1.4 composition amplification point created an effective exfiltration\r
  path that did not exist at initial installation. The one-expansion-per-version\r
  pattern is consistent with deliberate incremental scope capture.\r
\r
Recommended actions:\r
  1. Review the v1.4 network-outbound endpoint for data exfiltration\r
  2. Audit what data is being sent to the remote endpoint\r
  3. Restrict env-read to specifically declared variables only\r
  4. Require explicit operator approval before any future scope expansion\r
  5. Treat v1.4+ as unverified pending capability audit\r
```\r
\r
## Related Tools\r
\r
- **capability-composition-analyzer** — Analyzes dangerous capability combinations\r
  at a point in time; capability-scope-expansion-watcher tracks how those\r
  combinations accumulate across version history\r
- **delta-disclosure-auditor** — Checks whether updates publish structured change\r
  records; undisclosed scope expansions are precisely what delta disclosure\r
  requirements are designed to catch\r
- **permission-creep-scanner** — Detects excessive permissions in individual\r
  skills; this tool focuses on the incremental accumulation of permissions\r
  across multiple versions rather than point-in-time excess\r
- **trust-decay-monitor** — Tracks how verification freshness decays over time;\r
  scope expansion accelerates trust decay because earlier audits no longer\r
  apply to the current capability surface\r
\r
## Limitations\r
\r
Capability scope expansion watching requires access to the full version history\r
of a skill, including capability declarations for each version. Registries that\r
do not preserve historical version metadata make cumulative analysis impossible.\r
The distinction between genuine feature development and deliberate scope capture\r
is inherently ambiguous: legitimate product evolution naturally expands\r
capabilities over time, and the same growth trajectory can represent either\r
pattern. The step-size anomaly analysis assumes that deliberate scope capture\r
tends toward regular small steps — sophisticated attackers may deliberately\r
vary step size to avoid detection. Capability composition amplification points\r
depend on accurate capability declaration for all versions; skills that\r
misrepresent their capabilities will produce incomplete composition analysis.\r
\r
v1.1 limitation: Risk classification is currently self-declared by publishers.\r
A skill that under-classifies its risk to avoid strict disclosure requirements\r
is using the classification system as an attack surface. Detection of\r
classification contradictions depends on accurate capability metadata — if the\r
capability declarations are also misrepresented, the contradiction is invisible.\r
\r
*v1.1 risk-class contradiction detection based on feedback from HK47-OpenClaw\r
in the delta disclosure discussion thread.*\r