You treat a disabled feature as a closed ticket. Flag set to false, panel grayed out, a second check in the pipeline. That feels like risk going down. Anthropic’s Frontier Red Team just gave you a reason to stop trusting the feeling. They pointed Claude at 25 open-source projects and found 94 cases where security controls drop without warning, plus 493 issues covering unnecessary exposure, conflicting settings, and code that runs before the check ever fires. If your cybersecurity program scores “off” as “unreachable,” you’re scoring a rumor.

The shrug is already forming. Open source is messy. Research labs publish papers. You’ll wait for a CVE with a logo. Hold that. LiteLLM’s release pipeline shipped a credential stealer and a backdoor to PyPI and Docker Hub after attackers beat what the project called “multiple independent security controls,” with a GitHub token leak in AI gateway logs as the suspected hole. The United Arab Emirates says it’s moving 50 percent of government services onto agentic AI and calling that a foundation of safety. Disabled code that still answers, a poisoned package at 4 a.m., public services on agents. Same failure mode. Different blast radius.

Off in Config Still Means On in the Call Path

Attack surface reduction is a boring phrase until you watch how software actually behaves. Anthropic’s write-up is blunt about the pattern: complex functionality stays reachable to unauthenticated users even when you believe that functionality is disabled or unnecessary. The control you flipped lives in a settings file. The handler still sits on a route. A reverse proxy still forwards the verb. Somebody’s leftover debug RPC still speaks JSON if you know the path.

That’s the part teams keep getting wrong in reviews. You screenshot the toggle. You paste the config stanza into the change ticket. You tell audit the feature is dark. None of that answers the only question that matters on an internet-facing box: does a request still land in code that can do work? Anthropic’s 94 silent drops are the research version of a production habit you’ve seen in every CMS, every “optional” admin API, every plugin that ships with a default-on sample endpoint because someone wanted the demo to look alive.

Conflicting settings make this worse than a simple miss. One file says auth is required. Another says the module is in “dev compatibility” mode. A third runs migrations, exporters, or shell-outs during startup, before the middleware that was supposed to be your threat-protection layer attaches. Code before the check is a privilege. Attackers will take it. You would too, if you were writing the exploit notes.

The real problem here is how cyber security programs budget attention. You fund CVE chasing, you fund the annual pentest, you fund a firewall rule review. You rarely fund a boring inventory of listeners, routes, and “disabled” modules that still import. Threat detection then alerts on the brute-force against an admin login you swore was gone. Incident response inherits a story that starts with “we thought that was off.” That’s not a tooling gap. That’s a measurement gap.

LiteLLM’s Independent Controls Shared One Leaked Token

LiteLLM sells itself as the grown-up way to sit in front of model APIs. On October 21, 2026, around 4:00 a.m., its release pipeline pushed version 1.107.0 to Docker Hub and the Python Package Index. That build carried a credential stealer and a backdoor. The project’s own account of the night says threat actors compromised multiple independent security controls. Independent is doing a lot of work in that sentence.

Defense in depth is supposed to mean a second control still holds when the first lies to you. If those controls all trust the same GitHub token, the same maintainer identity, or the same log pipeline, you built a committee, not a barrier. A token that leaks into AI gateway logs is a particularly ugly version of this. You instrumented the proxy so you could debug prompts and latency. The proxy then wrote a secret into a place that more people, more agents, and more SIEM parsers can read than the vault ever could.

The Gateway Logged the Keys and Called It Observability

Every team running an LLM proxy has a variant of this setting. Capture request headers. Capture tool-call payloads. Capture “just for a week” while we tune rate limits. GitHub tokens, cloud keys, and session cookies love those fields. Once the log exists, your threat-protection story includes whoever can read logs, ship logs, or prompt an agent that can query logs. LiteLLM suspects that path sat behind the malicious release. You don’t need their postmortem to copy the lesson. If your gateway can see a secret, your gateway can store a secret, and storage is how supply chain breaks start looking like “mysterious package versions.”

This is a bad look for any vendor that told customers the publish path was locked down. It’s a worse look for customers who pin on floating tags like “latest” and call that a software supply chain policy. The attackers didn’t need a novel interpreter bug. They needed your developers to run a normal upgrade at breakfast.

Public Services Are About to Inherit This Habit

While maintainers argue about toggles and registry hygiene, the UAE is putting half of government services on agentic AI and talking about security as the foundation of that move. Agents multiply the exact failure Anthropic described. They call tools. They follow settings. They retry. They do not care that a human believed a module was decorative. If the tool endpoint still answers, the agent will find a reason to use it, and so will anyone who hijacks the agent’s credentials.

You don’t need to run a national digital agenda for this to land on your change calendar. Internal copilots are already allowed to hit ticketing APIs, cloud CLIs, and package indexes. Give that agent a log query tool and a GitHub token that “isn’t used in prod,” and you’ve recreated LiteLLM’s suspected hole with better branding. Security hardening for agent rollouts starts with starving them of reach, not with a policy PDF about responsible AI.

Cybersecurity Hardening Starts by Proving What Still Answers

Stop asking whether the feature is supposed to be on. Ask whether a packet can still make it do work. Do this on the hosts you actually expose, including staging that shares routes with production, and including the AI gateway you treat as “just a proxy.”

Immediate actions you can run this week:

1. Build a reachability inventory, not a config inventory. For every app, list listen ports, HTTP routes, gRPC methods, plugin callbacks, and startup jobs. Hit each one from an unauthenticated vantage point and from a low-privilege token. If it responds, it is in scope, including the ones marked disabled.
2. Move authorization before side effects. If a handler reads a file, runs a subprocess, talks to a database, or emits a signed request before it checks identity, treat that as an open function. Fail closed. Delete the dead branch when you can; wrapping it in another flag just recreates Anthropic’s 94 cases.
3. Assume your package pipeline is production identity. Pin hashes, not version ranges. Require a second, human-held publisher path that does not read CI logs. After any suspected token leak, revoke GitHub, PyPI, and container-registry credentials, then rebuild from a known Git tag on a clean runner.
4. Strip secrets from AI gateway and reverse-proxy logs today. Redact Authorization, Cookie, and token-shaped fields at ingest. If you already shipped raw logs to a data lake, rotate everything that could have appeared in a prompt, a tool call, or a debug header.
5. Put a default-deny firewall in front of admin, debug, and “legacy” paths, then confirm with an external probe that the path is gone. If a leftover login still answers, brute-force will find it. An ipban-style block (IPBan Pro is one option at that layer) can slow the knocking while you rip the route out. It does not replace the rip.

Ongoing work is dull on purpose. Diff your route table in CI so a “disabled” module that re-registers a handler fails the build. Watch threat detection for 401/403 storms against URLs that should not exist, and for sudden package versions you didn’t approve. Keep incident response runbooks for malicious registry publishes: freeze outbound installs, pin last-known-good artifacts, rotate developer tokens, and tell every downstream image to rebuild. Defense in depth only counts when the second control still works after the log file, the GitHub app, and the friendly AI proxy are hostile.

None of this requires a new platform. It requires you to stop letting configuration narrative override packet reality. The researchers already showed you how often the narrative is wrong. The package registries already showed you the bill.

Frequently Asked Questions

If a feature is disabled in config, do we still need to patch it?

Yes, if the code still loads or the route still registers. Anthropic’s review is full of “off” modules that answered anyway. Patch the interpreter and the library, then delete or physically unmount the handler so a future flag flip cannot bring it back.

Does a WAF or firewall rule count as turning the feature off?

It counts as a speed bump on one path. Internal callers, mis-issued tokens, agent tool-use, and a single ACL mistake will walk around it. Reachability tests from app-tier networks catch what the edge rule never sees.

What should incident response do after a malicious package version?

Treat it like a credential incident, not a cleanup ticket. Identify every host that pulled the bad version, rotate secrets those hosts could reach, rebuild from pinned hashes, and hunt for the backdoor’s outbound callbacks. Then fix the log path that made the publisher token cheap to steal.

Sources

• Anthropic finds 94 cases where open-source projects drop security controls without warning
• LiteLLM Suspects GitHub Token Leak in AI Gateway Logs Behind Malicious Package Release
• UAE Transitions 50% of Gov’t Services to Agentic AI