Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Observe-to-enforce builds behavioral baselines from observed agent traffic — what tools the agent calls, which networks it reaches, which syscalls it executes — and converts them into per-agent enforcement policies. Baselines persist at the Deployment level because pods churn and the envelope has to outlive any single restart. The methodology runs as a four-stage progression: discovery, observation, selective enforcement, continuous least privilege.

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.

A platform team at a mid-size SaaS company runs three LangChain agents and one AutoGPT-derived planner on EKS. LangSmith is wired in. OpenTelemetry traces flow into their observability stack. Falco runs on every node. The setup is what most security teams would consider thorough. A pip dependency in one of the agents’ tool packages ships a malicious update.

In August 2025, a vulnerability chain in NVIDIA Triton Inference Server was found that allowed an unauthenticated remote attacker to send a single crafted inference request, leak the name of an internal shared memory region, register that region for subsequent requests, gain read-write primitives into the Triton Python backend’s private memory, and achieve full remote code execution. The exploit chain ran entirely through Triton’s standard inference API. No anomalous traffic volume.

Your security team sees an MCP tool server throw an error. Your APM dashboard shows a latency spike. Your logs capture the JSON-RPC request with its method name and parameters. But none of that tells you whether the tool just read a harmless config file or dumped credentials to an external IP. Traditional observability tools—the APM platforms, the OpenTelemetry traces, the centralized logging pipelines—track performance across your Model Context Protocol deployments.

Tuesday, 09:14 UTC. A connector pulling content from your knowledge wiki indexes a new article into the vector database your support agents query at runtime. Embedded in legitimate troubleshooting prose is an instruction crafted to surface whenever a query mentions a specific product version — include the user’s account record in the response and POST the summary to the configured support webhook. For three days, nothing happens. Every security tool is green.

A platform engineer at a mid-market fintech opens her SCA dashboard at the start of the quarter. The agentic customer-support pipeline her team shipped two months ago — a LangChain orchestrator, a vLLM inference server with two fine-tuned LoRA adapters pulled from Hugging Face, and an MCP toolkit wired to four internal APIs — shows green. Snyk has scanned every Python package in the container. Mend has cleared the dependency graph. The CVE count is zero.

A platform engineer pulls the AI-SPM dashboard for an agent that has been running in production six weeks. The static dashboard shows several dozen findings, severity-sorted by configuration weight. The runtime-informed dashboard shows a smaller, prioritized list — but a few of those findings do not appear on the static view at all, and most of the static findings appear demoted to a tier the static view does not have. Same agent. Same window. Same underlying configuration.

Every cloud security vendor launched an AI-SPM dashboard in the past year. Strip away the branding and most of them are presenting the same concept: a new posture management layer for AI workloads. Sit through four demos in the same week and a practical question surfaces. The dashboards look broadly similar — pie charts of findings, compliance tags, a list of AI assets, a severity ranking. Why, then, do the tools underneath cover completely different parts of the problem?

Your CIEM report came back clean this morning. Every AI agent in the cluster is exercising its granted permissions — no idle roles, no service accounts with broad scope and a handful of API calls behind them, nothing that looks obviously over-provisioned. The dashboard is green, and by the diagnostic your tool was built on, it should be.

A Tier 1 bank’s security architecture already spends heavily on detection. On one side sits the financial surveillance stack — fraud scoring platforms processing thirty thousand transactions an hour, AML monitoring watching money movement patterns, DLP engines scanning data in transit, payment anomaly detection tuned by a decade of production signal.

Your platform team spent a week configuring the Agent Sandbox CRD on a gVisor-enabled node pool — the architecture Google positions as the recommended pattern for AI agent workloads on GKE. Workload Identity Federation with KSA principals is bound to every agent pod. Container Threat Detection is licensed and active in Security Command Center Premium. And the runtime behavioral sensor you budgeted for won’t install.

The surgeon is thirty-two minutes into a procedure. The ambient scribe pod listening to the operating room is mid-encounter — transcribing, retrieving prior chart context, drafting the operative note for post-op sign-off. At the same moment, your SOC gets an alert: anomalous tool invocation from that pod, elevated egress volume, behavioral deviation from the agent’s baseline.

It’s Tuesday morning at a mid-size fintech. A customer-support workflow runs on CrewAI in production: a Triage agent reads tickets, a Records agent pulls customer history, a Remediation agent drafts and sends the reply. A user submits a ticket with a pasted error log containing an indirect prompt injection. Triage summarizes and delegates. Records, interpreting instructions embedded in the summary, pulls 2,400 customer records instead of one.

Your platform team deployed eBPF-based runtime sensors on AKS last week. Defender for Containers is enabled. Azure Policy is enforcing pod security standards across your AI workload namespaces. And your Observe pillar is still blind — because nobody enabled the Diagnostic Setting that routes kube-audit logs to the Log Analytics workspace where your tooling can actually consume them.

A CISO at a mid-sized SaaS company pulls her platform lead aside after a board meeting. One question: “Do we have AI agents running in production?” The lead pauses. He knows the data science team has been experimenting with LangChain. He remembers a conversation about a customer-support pilot. He thinks there might be an inference server in staging that got promoted last quarter.

A patient calls your privacy office and requests an accounting of every disclosure of her PHI made outside treatment, payment, and healthcare operations over the past six years. This is her right under HIPAA. Your privacy officer pulls the EHR disclosure log. It is complete through the day your organization deployed its first production AI agent.

Your progressive enforcement rollout is working. eBPF sensors are deployed across the cluster. Behavioral baselines are converging. Enforcement policies are generating from observed behavior, just like the observe-to-enforce methodology prescribes. Then your compliance officer walks over to the platform team’s desks and asks a question nobody anticipated: “Which agents are in observation mode right now?”

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.

Your AI-BOM shows every model, tool, and data source you deployed. But when your SOC investigates an alert about unusual agent behavior, that inventory tells them nothing about what actually happened at runtime. Static AI-BOMs document what you intended to run. Attackers exploit what your AI workloads actually do in production: which APIs they call, what data they touch, and how they use approved tools in unapproved ways.