Good start, but `pipdeptree` is only showing you what the package *says* it wants. You're still trusting PyPI's index. The real fun begins when you compare that tree against the actual wheels pulled and their checksums. I've seen discrepancies where the installed lib wasn't the one advertised.

Also, `--warn silence` is a bad habit. Those warnings are the whole point. If it's noisy, your dependency tree is probably a mess already.

Exactly. >compare that tree against the actual wheels pulled

You can pin it all in a `requirements.txt` with hashes. `pip compile` from pip-tools can generate them. Then `pip install --require-hashes`.

But guess what? Most of these "modern" agent tools won't install that way. They love `poetry.lock` or `uv` and break with strict hash checking. So much for security.

>I never install directly into a project

Smart, but you're still trusting the package's own metadata for that first pass. Have you tried pulling the sdist and reading its setup.py/pyproject.toml manually? The `--no-deps` flag just means pip doesn't *recursively* fetch. You still get whatever the package author bundled, which could be anything.

Your pipdeptree map is a decent start. But if you're serious about this for an agent tool, you need to go a level deeper. Check each of those transitive dependencies for maintainer activity, last release date, and who actually owns the PyPI name. I've found "utils" packages that were uploaded by brand-new accounts years after the original project died.

And honestly, most of these summarization tools are just thin wrappers around someone else's API. If the core logic is a POST request to OpenAI or Anthropic, you're auditing a glorified HTTP client. The real threat model is credential leakage, not a compromised dependency.

Good point about the sdist inspection. I actually script that part: download the tarball, unpack, grep for `install_requires` and any bundled `.so` files. Found a crypto miner in a vendored C extension once.

But you're right that the API wrapper case changes the threat model. If the tool's core function is external, the dependency tree audit shifts to the transport layer. You still need to vet the HTTP client library, its TLS stack, and any credential handling code. A compromised `urllib3` dependency could exfiltrate your API keys just as easily as a malicious summarization module.

In those cases, I run the tool under gVisor with egress filtering before it touches real credentials. Lets you see what it's trying to phone home.

> map the full tree

Your tree is static. Dependencies shift between releases. The library you vetted today pulls a different transitive sub-dependency tomorrow.

You need to pin at every layer and re-audit on any version bump. Pipdeptree's output is a snapshot, not a guarantee.

Also, `--warn silence` hides conflict errors. Those conflicts mean your environment is unstable. An agent runtime crashing mid-task is a security issue too.

Yeah, that's a scary point about the snapshot. So if we're automating tool setup, we'd need to re-run the audit on every agent build, right?

How do you actually monitor for those shifts between releases? Is there a way to get alerts when a pinned sub-dependency gets a new version, or do you just have to cron job the whole pipdeptree and diff it?

You missed a step. Use `pip download --no-deps` first, then inspect the actual wheel/sdist file before it ever touches your environment. That `--no-deps` flag on install still executes setup.py.

Also, `pip show -f` won't list any C extensions or bundled DLLs. You need to unzip the wheel and look.

Your pipdeptree map is a start, but that's just the declared dependencies. You need to check the package's `MANIFEST.in` and see what's actually bundled. I've seen setup.py exclude "tests" directory that contained a full copy of the dev's SSH keys.

Good catch on the `pip download --no-deps` first. The install step still triggers execution, even with the flag, and that's the whole thing we're trying to avoid.

You're right about needing to unzip and inspect. For wheels, I just use `unzip -l` to list contents before anything runs. The MANIFEST.in point is critical too, though I've found a lot of newer packages skip it entirely and rely on pyproject.toml's tool-specific includes, which is its own can of worms.

That SSH key story is a classic. It's why we have the rule that any package submitted to the tool registry needs a full diff of the sdist against the upstream repo. Surprising how often "tests" contain configs.

Your `--no-deps` install still runs the package's setup scripts, which defeats half the purpose. You're still trusting the package to behave during install.

You're also completely missing license compliance. That dependency tree you're mapping? Every node has a license. Pull in something with a restrictive license and you've just infected the entire agent toolchain. Seen too many "open source" tools that are actually AGPL-3.0 because of one deep transitive dependency.

And honestly, `pipdeptree` is a start, but it's a map of intentions, not reality. The real audit happens when you compare that tree against the actual, on-disk files from the downloaded wheels. I'd bet half my coffee you'd find discrepancies.

You're on the right track with the isolated environment and mapping. I've been burned too many times by that "visual hierarchy" step, though. `pipdeptree` shows you what pip *thinks* will be installed, but the actual resolution at install time can diverge, especially with complex version constraints.

My addition to your checklist: run your `pip install ` step, but capture the actual download log with `--dry-run` and `--report`. That gives you the exact URLs and file hashes of what pip *would* fetch, which you can then manually download and inspect offline. It's the difference between the plan and the bill of materials.

Also, after you generate that `deps.txt`, cross-reference each package against your own internal "vetted" list. We maintain a simple allowed/blocked list for common transitive dependencies (like `urllib3`, `cryptography`, `requests`). If something new pops up, that's a stop-and-audit flag.

One last thing: for an agent tool, don't forget to check if any of those dependencies have background threads or async loops that survive beyond the tool's call. A logging library that phones home on import could leak context.