Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Your SOC gets an alert from the CNAPP: an outbound connection from a pod in the ai-prod namespace to . The destination is in the allowlist. The payload size is 28 kilobytes — well under the DLP threshold. The agent’s service account has permission to invoke the email tool. By every check your stack runs, the traffic is normal. Forty minutes later, a customer support lead notices that an email went out containing a summary of 2,400 customer records that the agent had no business querying.

A developer clones a repository and opens it in VS Code at 10:47 a.m. Before their cursor blinks, six different configuration file formats on disk have a chance to execute shell commands on the host. A.vscode/tasks.json with runOn: folderOpen. A.devcontainer/devcontainer.json with initializeCommand. A post-checkout hook already sitting in.git/hooks/. A postinstall line waiting in package.json for the next dependency install. A.envrc in the project root.

A CISO running AI agents on GKE has watched three Google product launches in eighteen months — Model Armor, expanded Security Command Center coverage for AI workloads, additions to Chronicle’s curated detection content — and is being asked whether the GCP-native stack is now sufficient. The vendor demos and the Google Cloud blog say yes. The 2 AM analyst experience says something different.

Your fraud detection agent scores 30,000 transactions per hour. Your KYC agent processes identity verifications against government watchlists. Your customer service chatbot resolves disputes and initiates balance transfers. Each agent runs on Kubernetes with inherited service account permissions that span payment APIs, customer databases, and compliance systems. Now imagine one of those agents is compromised through a prompt injection embedded in a customer support ticket.

A missing null check in libssh’s SFTP directory listing code lets a malicious server crash clients, but real-world exploitability is extremely constrained. CVE-2026-0968 is an out-of-bounds heap read in sftp_parse_longname(), triggered when an SFTP client processes a crafted SSH_FXP_NAME response with a malformed longname field. Red Hat, which serves as the CNA (CVE Numbering Authority) for this vulnerability, scored it 3.1 (Low), while Amazon Linux independently scored it 4.2 (Medium).

Security teams deploying AI agents into Kubernetes know they need behavioral baselines. The concept is straightforward: define what “normal” looks like for each agent, then detect when behavior drifts in ways that suggest compromise. The problem is that AI agents are designed to change. A model update alters inference latency. A prompt revision shifts tool-calling sequences. A new MCP integration adds API destinations nobody flagged during the last security review.

A platform security engineer gets an alert at 2:14 a.m. One of the LangChain agents running in their production Kubernetes cluster has produced an execution graph with eleven nodes, seven tool calls, and an egress edge to a domain that is not in the agent’s approved integration list. The chain is fully rendered in their console. Every signal is there.

Your engineering lead is in your office Thursday morning. They want to push an AI agent to production next Tuesday. It’s a LangChain-based workflow agent, connected through MCP to three internal tools and one external API, with access to a customer database. The framework posters are on the wall. Your team has spent two quarters standing up runtime observability. And sitting in that chair, you still don’t know whether to say yes.

Your CNAPP shows green across every posture check—hardened clusters, compliant configurations, no critical CVEs—but when your board asks "Are our AI agents safe in production?", you cannot answer with confidence because your tools see the infrastructure, not what the agents actually do at runtime.

When your CNAPP flags a suspicious dependency in an AI agent container, your WAF logs an unusual API spike, and your SIEM shows a burst of cloud storage calls—are those three separate incidents or one rogue agent attack? Most security teams treat them as three tickets in three queues, investigated by three people who may never connect the dots. By the time someone pieces together that a single compromised agent drove all three signals, the attacker has already moved laterally and exfiltrated data.