Supply Chain ai-sessions Bridge Activation Chain
This detects a compromised or malicious version of the ai-sessions PyPI package behaving like a remote control channel after it starts running inside an AI coding agent (Codex, Claude Code, OpenCode). It does not flag installing or launching the package — only what happens next if the package starts pulling in outside instructions and reaching out to the network in ways normal package updates don't.
How the attack works
ai-sessions is a terminal bridge tool that runs with the same privileges as the AI agent hosting it. The rule waits for the package's code to activate inside that agent's process tree, then watches a 15-minute window for at least two of: fetching instruction content from a public host after activation, a non-package-manager child process making outbound web requests, egress spread across three or more distinct public hosts, or a shell/interpreter spawned with a command line naming the package or an AI coding harness. Any two of these together, in that order, suggest the package is acting as a live bridge pulling commands and data rather than just installing normally.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 3f8c1d47-9b26-4a5e-8d31-7c0a6be24f19
- Severity
- Medium
Why it matters
If real, this means an AI agent's own process is being used as a channel to fetch and execute outside instructions and exfiltrate data to multiple destinations, with whatever access and credentials that agent has.
What you can do
- →Pin the ai-sessions package to a known-good version and review any recent version bumps before deployment.
- →When this fires, check the actual destination hosts and what content was fetched rather than assuming compromise — legitimate update or docs checks can look similar.
- →Restrict which processes an AI agent's sandbox or container is allowed to spawn shells or interpreters from, and log those spawns.
- →In CI/devcontainer setups that install ai-sessions and run test suites, expect some benign multi-host egress and tune your own baseline for that pattern.
Known benign look-alikes
- Legitimate first run of ai-sessions where the tool performs its own version/update check and then fetches harness documentation from a public docs host - two stages, benign intent. Investigate the destination rather than assuming compromise.
- CI or devcontainer bootstrap that installs ai-sessions and then runs a test suite which downloads fixtures from several public hosts inside the same window.
- Process nodes are keyed by executable path, so HTTP requests made by an unrelated invocation of the same interpreter (python, node) can be attributed to the same node and inflate the egress host count.
- A developer running the bridge interactively under an agent-launched shell, where the harness name appears in the command line as normal usage.