Provenance verification and allowlisting aim to stop malicious components from being loaded. Containment accepts that some will get through — and builds the execution environment so they can't escape the sandbox.
A poisoned package that reads SSH keys is devastating when it runs in a developer's full environment. The same package running in a sandboxed container with no access to the home directory, no network egress, and no mounted credentials can't exfiltrate anything.
For package execution: Run all agent-installed packages in ephemeral containers or VMs with minimal permissions — no host filesystem access, no network access to anything outside the declared API endpoints, no credential store access.
For tool calls: Each tool invocation runs with only the permissions it needs for that specific call. A tool that sends emails doesn't need filesystem access. A tool that reads documents doesn't need network access. Apply least-privilege at the tool-call level, not just at the agent level.
For builds: Use reproducible, hermetic build environments where the entire dependency set is resolved and locked before the agent runs — preventing runtime resolution from introducing new, unvetted components.
MIT03 directly limits the impact of Scenarios 5 (poisoned npm, SSH key exfiltration) and 6 (agent-in-the-middle). A sandboxed agent that installs a malicious package gets no access to credentials. A compromised sub-agent that's isolated from the main orchestrator can't cascade its payload through the pipeline.
Ask your team: if a compromised component were loaded by your AI agent, what could it actually reach — your production database, your API keys, your internal network? Ask whether agent components run in an isolated environment where a bad actor getting in would still find nothing of value to take.