Instead of vetting AI add-ons one by one before install, could we catch attacks by watching them work together live?

This explores whether agent-skill security can move from vetting each skill before it's installed (scan time) to watching the chain of skills as it actually runs (execution time). The corpus has no direct test of that swap for skills. It does explain why scan-time checking breaks, and it points to what a runtime version would need.

Scan-time checking breaks because the attack isn't inside any single skill. An attacker can split one malicious intent into interdependent subpayloads packaged as separate skills. Each looks harmless alone, and the harm only appears through their ordered execution, shared context and passed artifacts (Can skill scanners miss attacks hidden across multiple skills?). Scanner feedback makes this worse. An attacker can keep refining each skill until it scores as innocent while the chain's meaning stays intact, which reached 96% average attack success across six scanners (Can attackers evade skill scanners by refining individual skills?). The scanner reads the text of one skill, but the attack lives in how skills hand things to each other.

Making the chain the unit of inspection helps, but only partly. ChainGuard cut attack success to 22.5% while passing 99.5% of benign workflows, so the blind spot narrows but stays open (Does chain-level inspection close the cross-skill attack blind spot?). That summary doesn't say whether ChainGuard runs before or during execution, so it shows the chain matters as a unit, not that timing is the fix. The stronger argument for runtime comes from two other notes. A per-action check can't state a rule that depends on what happened earlier. Only a stateful monitor tracking the composed behavior can catch actions that are each allowed but together violate a safety limit (Can stateless checks ever catch sequence-level constraint violations?). The defended unit should also be a set of actions linked by observed transfers, task authority and response history, with membership revised as evidence accumulates (Should defence units span multiple executions and agents?). Those links, such as which output skill A actually passed to skill B, don't exist until the chain runs.

Work on benchmark cheating shows what runtime checking can look like, though it isn't about skill chains. BenchShield records authority-bearing transitions from the infrastructure side, so it can tell a task that merely exposes a hacking vector from a run that actually used one (Can runtime instrumentation distinguish hacking exposure from actual exploitation?). It models a run as a finite lifecycle of typed events. The same model serves both pre-run static analysis and runtime instrumentation, so the choice isn't scan time versus execution time (Can a finite lifecycle model detect reward hacking across benchmarks?). Its audit agents get a narrow remit, pinned artifacts and a duty to cite evidence, so infrastructure records serve as the fixed check and the agent's judgment as the arguable step (Can scoped agents reliably judge semantic hacks in runtime analysis?). A separate note found that safety rules stored in the memory an agent actually consults worked better than a policy document sitting beside it (Can governance rules embedded in runtime memory actually protect autonomous agents?).

So checking at execution time looks plausible and probably necessary, since the cross-skill links can't be seen any earlier. But nothing in the corpus shows a runtime chain monitor beating ChainGuard's 22.5% residual, and the audit-agent reliability numbers are reported as unquantified. The open question is whether an intended lifecycle for a skill chain can be written down well enough that deviations from it stand out.