Default to asking for approval on any command that installs a package, and allow it automatically only inside a disposable sandbox with no secrets and limited network access. Installing can execute third party code immediately, so an agent that installs freely is making a trust decision for you.
What an install actually does
On npm, the documentation states that preinstall, install and postinstall scripts from the package run during npm install. That code runs with your user's permissions, on your machine or runner, before anyone reads it.
Python packages built from source can also run build code. The point is general: installing is execution.
Three setups, three answers
Local laptop, real credentials present. Require approval for installs. Your shell holds cloud keys, SSH keys and tokens that a malicious script could read.
Disposable container with no secrets. Auto approval is reasonable. The worst case is a thrown away environment. Keep egress limited so a bad package cannot easily send anything out.
CI runner. Do not let an agent add packages to a pipeline that has deployment credentials. Use a frozen install from a reviewed lockfile instead, and let humans change the lockfile.
Controls that make approval cheap
- Show the package name, version and registry in the prompt, so the human can judge in seconds.
- Allow list of already approved packages that install without a prompt.
- Block installs from unfamiliar registries or direct URLs.
- Commit the lockfile and review its diff. A frozen install fails when the manifest and lockfile disagree.
- Run the agent with the least permissions it needs. OWASP's guidance on prompt injection recommends least privilege and human approval for high risk actions, which fits here.
Why this connects to prompt injection
An agent that reads a web page or an issue can be told, by text hidden in it, to install something. OWASP describes this as indirect prompt injection, where external content carries instructions that change model behavior. An install approval step turns that attack from silent to visible.
A simple policy
- Installs require approval outside a sandbox.
- New packages need the checks in this checklist.
- Lockfile changes are reviewed like code.
- Agents never hold deployment credentials.
Safeguard's policies, gates and MCP Guardrail can enforce rules like these on what an agent is allowed to do.
What to log
Whatever you decide, record every install an agent runs: the package, version, registry, time and the task it was working on. When a package is later reported as malicious, that log answers in minutes whether you were exposed and on which machines. An agent that runs installs without leaving a trace is hard to defend in a post incident review.
Quick check
Is a sandbox enough on its own?
It limits damage but does not remove the risk. If the sandbox has network access or mounted secrets, a bad package can still reach them. Keep both out.
Sources
Last reviewed: 19 October 2026.
