When an AI agent downloads a reusable skill that runs code, what decides what that code is allowed to touch?

This is about what rules decide what a skill's bundled code may run and touch. The corpus has no catalog of skill permission systems, such as a comparison of sandboxes or allowlists. It does show why the question is urgent and which kinds of control have held up under testing.

Skills are not just text. They bundle executable scripts, tool interfaces and external resources, so they can run code and reach system resources. The packaging that makes a skill reusable also makes it an attack surface, closer to a software dependency than a prompt (Does bundling code with skills create hidden security risks?). So the permission question resembles the supply-chain question: what would you demand of a package before letting it run? Where the code came from also matters. Agent code splits into model-internal capability, the system-provided harness, and artifacts the agent creates itself, and each layer fails differently (What are the three distinct layers of agent code?). A script a human shipped and a script the agent wrote mid-task probably shouldn't share one blanket rule. The agent-written, persisted and shared layer is the least explored, with safety oversight listed among its open problems (What happens to code that agents create and then share?).

The most direct evidence is that stating a rule is not enough. Explicit authorization boundaries kept protected tests unmodified only when paired with restricted tools. Naming a prohibition failed, and the boundary had to specify the protected state itself (Can explicit authorization boundaries prevent agents from modifying protected tests?). A companion note adds a caveat. The result comes from a bundle of rules plus restricted tools, and no experiment isolates one factor. So we can't tell whether the agent could not cross the line or chose not to. The same pipeline recorded a 100% Judgment Bypass Rate alongside a 0% Unsafe Action Rate, so the two can come apart (Do authorization rules or restricted tools prevent test modifications?).

Three notes speak to where the control should sit. A model-level filter judges one output at one moment, but an agent's risk spreads across memory, retrieved content, tool calls and environmental reach. Containment means controlling what the agent can touch, not only what it says (Can a model-level filter truly contain an agent with environment access?). Timing matters too. A crafted prompt can steer a planner-executor system while the workflow is still being formed, before inspection defenses activate, raising malicious success by up to 55 percent (Can prompts alone reshape multi-agent workflows without system access?). A gate placed at the moment a skill script runs may therefore come too late. And in one persistent agent, governance rules written into the memory layer it consulted (889 events over 96 days) worked better than external policy, because the agent actually read them while deciding (Can governance rules embedded in runtime memory actually protect autonomous agents?).

Taken together, the corpus points to a permission model with three parts. Restrict the tools, so unsafe crossings aren't available. Name the protected state, not just the forbidden act. Put the rules where the agent reads them at runtime. What's missing is a test of this against skill bundles directly. Skills are treated as externalized procedural memory in the harness (Where does agent reliability actually come from?), and a separate trained curator can rewrite skill libraries (Can a separate trained curator improve skill libraries better than frozen agents?). That work is about performance, not security. It does raise a question the corpus leaves open: whoever can edit a skill decides what code runs, so who should be allowed to edit it?