Static analysis for skills is the right starting point, and the README is honest about the limits: no findings ≠ no risk.
The gap worth designing around: scanning catches code-level patterns before deployment; it doesn't constrain what a skill can do with its tool-call authority once it's running.
A skill that passes the scanner can still call any tool the agent has access to. If that means read/write to the filesystem, external API calls, or spawning subprocesses — the scanner cleared it, but the blast radius is still wide.
The pairing that closes the loop: explicit scopes at the execution boundary. Not "this skill looks clean," but "this skill is authorized to touch these specific tools and nothing else." Runtime enforcement, not just pre-deploy analysis.
The two aren't competing — scanner + scoped execution is defense in depth. Nice work from the Cisco team.
rodchalski•2h ago
The gap worth designing around: scanning catches code-level patterns before deployment; it doesn't constrain what a skill can do with its tool-call authority once it's running.
A skill that passes the scanner can still call any tool the agent has access to. If that means read/write to the filesystem, external API calls, or spawning subprocesses — the scanner cleared it, but the blast radius is still wide.
The pairing that closes the loop: explicit scopes at the execution boundary. Not "this skill looks clean," but "this skill is authorized to touch these specific tools and nothing else." Runtime enforcement, not just pre-deploy analysis.
The two aren't competing — scanner + scoped execution is defense in depth. Nice work from the Cisco team.