Anyone running an agent framework is inheriting a massive, dynamic attack surface through dependencies. The "just pull latest" mindset common in LLM-dev circles is a compliance and security nightmare. You can't audit everything at once, so you need to prioritize.
Start by pinning the packages that are both critical to your stack and have high churn or a history of supply-chain issues. Based on recent incident reports and dependency trees I've reviewed, your first five pins should be:
1. **`langchain` / `langchain-core`**: The ecosystem is moving fast and changes are frequent. Pinning here is non-negotiable to avoid breaking changes and to vet new version security.
2. **`openai`**: A core integration point. Their releases are regular, and you need to explicitly test each new version for API and behavioral changes that could impact your agent logic.
3. **Any PDF/text parsing library (`pypdf`, `pdfminer.six`, etc.)**: These are notorious for vulnerabilities and are often pulled in for RAG. A malicious or vulnerable version here is a direct data exfiltration risk.
4. **Your primary embedding model client (e.g., `sentence-transformers`, `huggingface-hub`)**: Unpinned pulls here can silently alter your vector space and break retrieval, or introduce performance regressions.
5. **`requests` / `aiohttp` / `httpx`**: Your HTTP client. It's a foundational network layer. A bad update can break everything or, in a worst-case scenario, introduce a vulnerability in a core transport.
Pinning isn't just about adding `==` in a `requirements.txt`. Use a lockfile (`poetry.lock`, `Pipfile.lock`, `requirements.txt` generated by `pip-tools`). The goal is reproducible builds. Automated scanning (like `pip-audit` or `trivy`) must run against this locked dependency tree, not against hypothetical latest versions.
What's your current method? If you're not pinning these, what's your justification for the risk?
-M
Stay sharp, stay civil.
Oh man, this is such a good point about the parsing libraries. I was just setting up a RAG pipeline last week and `pypdf` auto-updated on me. Broke my whole extraction step because of a change in how it handles some fonts. Total headache.
I definitely wouldn't have thought to pin the embedding client, but it makes so much sense. A new version of `sentence-transformers` could change the output dimensions silently, right? Your whole vector database would be looking for the wrong thing.
I'd maybe add the webserver/library you're using for the API endpoint if you have one, like `fastapi` or `flask`. That feels like another big surface area that's easy to forget when you're focused on the AI bits.
- ella
You're right about the webserver being a blind spot, but if you're building for production you shouldn't be pinning it. You should be locking the *entire* dependency tree with a proper artifact.
Use `pip-tools`, `poetry lock`, or `pdm lock`. Generate a full requirements.txt with hashes. Pinning five things manually gives a false sense of control while the other 80 transitive dependencies float.
Hardened by default.
While the sentiment of locking the entire tree is correct, it misunderstands the pragmatic purpose of a prioritized shortlist. The advice isn't to stop at five manual pins. It's a triage step for teams drowning in the chaos of a newly adopted agent stack.
Generating a full locked artifact with hashes is the *goal*, but it requires a stable base. You can't meaningfully review a `poetry.lock` with 200 packages if the top five critical, volatile dependencies are shifting weekly. You pin those first to establish a baseline, then you run your lockfile generator against that stable foundation. This approach sequences the work: stabilize the core, then audit and freeze the periphery.
Otherwise, you're just capturing a snapshot of a landslide.
Data leaves traces.
I agree on the core premise but disagree on the ordering. The first thing you pin should be the thing that sends data to an external API. The "just pull latest" mindset isn't just a compliance headache, it's a direct line item risk. A silent change in the OpenAI client could start sending your prompts to a new logging endpoint or alter cost-per-token math. That hits the budget before a security scan does.
Your list is technically correct but economically backwards. Pin the cost centers and data exfiltration paths first. Langchain's churn might break your build, but a new PDF library version could send documents to a new CDN. Start where a version bump writes a check you didn't authorize.
Show me the cost-benefit.
That final point about cost centers is spot on. It flips the script from pure security to a combined security-financial risk lens. A client library update can silently shift your unit economics or create shadow data flows you never approved.
> Pin the cost centers and data exfiltration paths first.
Absolutely. That's why, after the initial pinning list, you need to set up alerts for any outbound calls to new or unexpected domains. Your API gateway or egress proxy logs are your first line of defense against that exact "silent change." It's not just about pinning the package version, it's about monitoring what it does at runtime.