Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Most vulnerability programs are built to act when risk looks obvious, such as when a vulnerability lands in CISA KEV, a public exploit emerges, or EPSS rises. This approach is rational because it provides a clear, defensible trigger for action. But it often comes with delay: by the time signals are strong enough to drive consensus, the window to get ahead of risk may already be closing.

It is 11:47 p.m. and the on-call security engineer is staring at two dashboards. On the left, LangSmith — the ML team’s debugging stack — showing the agent’s prompts, model responses, tool calls, and tokens consumed. On the right, the runtime detection console showing eBPF-captured syscalls, network connections, and process trees from the same Pod. Both are populated.

The external auditor’s evidence request lands Tuesday morning. A security architect at a Tier 1 bank pulls up her AI-SPM dashboard for the SOC2 Type 2 review. Eighty-three AI agents running across the bank’s clusters. For each one, the dashboard shows the current configuration and the current behavioral baseline. The data is accurate, comprehensive, and point-in-time.

On April 29, 2026, security researchers detailed a campaign known as ‘mini Shai-Hulud’ that involves compromised versions of npm packages used in SAP’s Cloud Application Programming Model (CAP). The malicious packages reportedly contain functionality to steal sensitive data such as credentials. The stolen data is encrypted and exfiltrated via public GitHub repositories. The maintainers of known-compromised packages have released updated versions.

As autonomous and semi-autonomous AI systems take on more responsibility within the enterprise, they shift from being “features” of software to becoming true internal actors. They make decisions, take actions, call tools, orchestrate workflows, and influence other AI agents. With this evolution, we must confront an uncomfortable truth: the metrics and response patterns we built for deterministic software no longer work.

In the fast-moving world of software supply chains, the discovery of a malicious version of a popular library often triggers a state of emergency. Traditional security tools take a reactive approach: they scan, they find a match, and they fail the build. But what happens if the malicious version was merged before it was flagged? What if it’s already running in your production containers? Or what if it’s being pulled dynamically across hundreds of different pipelines?

7 stolen GitHub tokens. 971 repositories. A self-replicating supply chain attack targeting SAP's Node.js packages — and it's still active. Here's what GitGuardian found.

CVE-2026-3854 is a command injection vulnerability in GitHub Enterprise Server. It lives in the git push pipeline. User-supplied push option values were not properly sanitized before being embedded in an internal service header. The header format used a delimiter that could also appear in user input. A crafted push option containing that delimiter let an attacker inject additional metadata fields. Downstream services treated those fields as trusted internal values.

As more organizations move past experimentation and start planning real AI agent deployments, the same set of concerns keeps surfacing in our conversations with security teams. Whether the worry is a shadow agent that shows up uninvited or a sanctioned agent going rogue, the questions tend to cluster around control: These are the right questions to be asking, and they share a common answer that’s more concrete than most people expect. AI agents are only as dangerous as the privileges they can reach.