\n\n\n\n Your Bot's Dependency Tree Is a Trust Fall - AI7Bot \n

Your Bot’s Dependency Tree Is a Trust Fall

📖 4 min read•796 words•Updated Aug 23, 2026

Your scanner scanned you back.

That’s the short version of what happened in 2026, and if you build bots for a living like I do, it should ruin your week in a productive way. A financially motivated hacking group called TeamPCP pulled off a supply-chain attack that leaked terabytes of credentials from more than 2,500 organizations, including major tech firms. The original compromise happened on March 24, 2026. The vector was an open-source security tool.

Read that last sentence again. The security tool.

Why This One Hits Bot Builders Specifically

Reporting on the incident points at two open-source projects in the chain: Trivy, the scanner that checks images and code for vulnerabilities, and LiteLLM, the tool that smooths out talking to a pile of different AI model providers through one interface. I have shipped both in production. Most of you have too, whether you chose them or a template did.

Think about where those two things sit in a typical bot stack. Trivy runs in CI, which means it runs with access to your build environment, your registry tokens, and often your cloud role. LiteLLM sits at the exact chokepoint where every API key you own gets loaded into memory: OpenAI, Anthropic, your vector database, your observability provider, whatever you’re paying per-token for this month. If you wanted to design the two juiciest positions in an AI bot pipeline to compromise, you would design those.

That’s why “terabytes of credentials” isn’t hyperbole. It’s arithmetic. Compromise a proxy layer that thousands of teams route their model traffic through, and you don’t steal one key at a time. You collect.

The Uncomfortable Part About How We Build

Bot development has a culture problem that this attack exposes cleanly. We move fast, we glue services together, and our default posture toward tooling is trust. A tool with a security label gets even more trust, because it’s supposed to be the thing watching the door.

Ask yourself honestly:

  • Do you pin your dependency versions, or does your Dockerfile say latest?
  • Does your CI job that runs a scanner have narrower permissions than your deploy job, or the same ones?
  • How many of your model API keys are scoped, rate-limited, and rotated on a schedule you could name out loud?
  • If a proxy in your stack quietly forwarded every request somewhere else, would anything in your monitoring notice?

I answered badly on at least two of those the first time I asked myself. That’s the honest reason I’m writing this instead of a tutorial.

What I Changed In My Own Stack

None of this is exotic. It’s the boring work we skip because bots are more fun to build than to secure.

Treat the proxy layer as hostile

Anything that sits between your bot and a model provider sees everything. Give it scoped keys with spend caps, not your account-level keys. If your provider supports per-project keys, use one per bot, so a leak is a contained blast rather than a full account handover.

Split CI permissions by job

A vulnerability scanner needs to read your code and images. It does not need to push to your registry or assume your production role. Separate the credentials so a compromised scan step can’t become a compromised deployment.

Pin and verify

Pin exact versions and check digests. Auto-updating an open-source tool the moment a new tag lands means you inherit a compromise at machine speed. Slower updates with a human reading the changelog is a real defense, not paranoia.

Watch egress

Your bot should talk to a known, short list of hosts. If your runtime can enforce that list, enforce it. Unexpected outbound traffic from a container is one of the few signals that catches this class of attack while it’s still happening.

Assume rotation is routine

Credential rotation should be a script you run without ceremony, not a crisis response. If rotating every key in your bot stack takes you a full day of manual clicking, that’s the actual vulnerability.

The Part Nobody Wants To Say

Open source is how we build bots. I’m not arguing against it, and neither is anyone serious. The lesson here isn’t to stop using shared tooling, because there’s no version of modern AI development where you write your own model router and your own vulnerability scanner from scratch.

The lesson is that trust needs a budget. Every dependency you add is a small trust fall, and 2,500 organizations just learned what happens when the thing catching you gets pushed. The tools you install to protect your bots are part of your attack surface, and the ones with the deepest access deserve the most suspicion, not the least.

Go look at your dependency tree. Not later. It’s a worse read than you think, and it’s still the cheapest audit you’ll ever run.

🕒 Published:

💬
Written by Jake Chen

Bot developer who has built 50+ chatbots across Discord, Telegram, Slack, and WhatsApp. Specializes in conversational AI and NLP.

Learn more →
Browse Topics: Best Practices | Bot Building | Bot Development | Business | Operations
Scroll to Top