Supply Chain Titah-Code NPM Agent Delegation CLI

How the attack works

The rule watches for the literal string 'titah-code' appearing as an argument to npm, pnpm, yarn, bun, npx, pnpx, or bunx, or as the command being executed directly. That covers normal installation and use of the tool. A second, more serious pattern looks for a process launched from inside the package's node_modules folder that then invokes a shell, fetches something over the network, evaluates code, or decodes base64 - the classic sign of a compromised postinstall script escaping its sandbox. Both patterns only produce a log entry; neither blocks anything.

Netzilo detection

Why it matters

If titah-code or its postinstall script were ever compromised, an attacker could gain access to source code, developer prompts, and any API keys the CLI passes to the downstream AI agents. Right now there is no evidence of a malicious payload - this is inventory data to support that judgment call, not proof of compromise.

What you can do

• →Review every logged installation or invocation of titah-code and confirm it is an approved, intentional use rather than an unexpected dependency.
• →If the postinstall-escape pattern fires (execution from node_modules/titah-code combined with shell, network, eval, or base64 activity), treat it as high priority and inspect the package version and script contents immediately.
• →Restrict which API credentials and repository scopes are exposed to any CLI that delegates tasks to third-party AI editors.
• →Pin and audit the exact version of titah-code in use, and monitor its release history for unexpected changes to postinstall scripts.

Known benign look-alikes

• A developer who has deliberately adopted titah-code as an approved coding CLI - every legitimate invocation of the tool fires Tier 1. This rule is an inventory of the dependency, not an accusation; expect one event per real use.
• CI/CD jobs that install the package as a declared dependency (`npm install titah-code`, `pnpm add titah-code`) during image build or test setup.
• One-shot trial runs via `npx titah-code ...` by an engineer evaluating the tool.
• Security researchers or an internal supply-chain review detonating the package in a sandbox; only the grep/npm-view/scanner forms are filtered, a real execution is not.
• The package's own legitimate postinstall or bin shim shelling out - `node -e` and `sh -c` in a lifecycle script are common in benign npm packages, so Tier 2 is suspicious but not conclusive and remains report-only.
• Build scripts, Makefiles or wrapper CLIs that pass the literal string `titah-code` as an argument to a spawned process.

References

• https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/
• https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/
• https://attack.mitre.org/techniques/T1195/002/