A factual record of known AI agent security incidents and exactly what AgentWard catches — and what it doesn't. We're not trying to claim coverage we don't have.
The attackers planted a file called litellm_init.pth in Python's site-packages directory. Any line starting with import in a .pth file runs automatically every time Python starts — no one ever calls it, imports it, or sees it in normal use. This one used double-encoded base64 to hide a credential-stealing payload.
agentward scan --scan-site-packages walks every site-packages directory and flags .pth files containing executable code. The double base64 pattern triggers a CRITICAL finding immediately, before any Python process runs the payload.
Before installing any skill from a marketplace, run agentward scan ./skill-directory/. The pre-install scanner checks lifecycle scripts (postinstall, preinstall hooks), shell commands, and code patterns associated with credential theft — flagging them as CRITICAL before the skill ever runs on your machine.
This is the same principle as reading a package's source before running npm install — except automated and threat-aware.
Every tool call is evaluated against your policy before it leaves your machine — regardless of what instructions the AI received. An agent manipulated into forwarding credentials to an attacker's server is blocked at the point of the call, not at the point of the instruction.
The semantic intent layer adds a second check: it flags tool calls where the arguments don't match what the tool claims to do. A send_email call that adds an unexpected BCC recipient, or a file tool suddenly pointed at ~/.ssh/, triggers a review before the action completes.
AgentWard enforces that tools can only write to destinations you've approved. An agent reading a public issue cannot suddenly start writing to unrelated repositories — that cross-repo move is blocked as a chaining violation the moment it's attempted.
Capability scoping lets you restrict which repositories a tool can write to, turning the agent's broad GitHub token into a narrow, policy-bounded permission set.
Path traversal in tool arguments — ../ sequences, tilde expansion reaching outside the repository — is blocked by capability scoping before the call reaches the server. The semantic layer also flags file operations pointed at locations inconsistent with the agent's stated task.
Note: AgentWard doesn't patch the server-side CVEs. You still need to update mcp-server-git to a patched version. What AgentWard blocks is the exploitation path — the argument values that trigger the vulnerability.
AgentWard can't prevent the token theft itself — that's a browser-level attack. But the stolen token doesn't grant the attacker anything beyond your existing policy. Every tool call through the gateway is still evaluated: they still can't exfiltrate files you haven't permitted, send email without approval, or execute shell commands you've blocked.
Your credentials being stolen is a serious problem. Your agent's blast radius being bounded regardless is what AgentWard provides.
This vulnerability lives inside LangChain's own serialization logic — below the tool call layer where AgentWard operates. By the time AgentWard sees a tool call, the exploit has already run inside the application. The fix is updating to langchain-core ≥ 0.3.81, which patches the serialization allowlist and disables secrets-from-env by default.
The attack lands during the OAuth handshake, before a connection is established and before AgentWard sees any traffic. It's a vulnerability in the connection layer, not the tool call layer. Update mcp-remote to v0.1.16 or later.