Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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.

My first introduction to UNIX remote access was via telnet and rsh protocols in college, which was the standard method at the time. But I soon started reading articles about how easy it was for someone to sniff the network and capture passwords since they were being transmitted in plaintext. On the shared network segments common to university campuses and early enterprise environments, the tools to intercept traffic were freely available, well-documented, and required very little skill to use.

An AI just found critical vulnerabilities that survived decades of human review. If your security program isn’t built for this moment, it’s already behind. Surprise! An AI just did what your security team couldn’t.

What can bring together development and operation teams better than DevOps, a prevalent agile methodology? It involves new management principles, cultural change, and technology tools that boost the team’s development, collaboration, and productivity while they cooperate on software development.

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.

NIST Special Publication 800-171 defines a precise set of security requirements for organizations that handle Controlled Unclassified Information (CUI) outside of federal systems. For defense contractors, subcontractors, and their engineering teams, these controls are non-negotiable with the advent of the Cybersecurity Maturity Model Certification (CMMC) program, which dictates how CUI must be accessed, logged, transmitted, and protected across every system in scope. That scope is shifting.

In Part 1 of this series, we discussed the CI/CD security boundary, mapped out potential attack vectors with a CI/CD threat matrix, and introduced a simple threat model focused on ideating detection workflows. In this post, we’ll apply these principles to a real-world source code management (SCM) tool example that every developer is familiar with: GitHub. In addition to threat modeling, we’ll also be taking a closer look at historical attacks on GitHub and GitHub Actions ecosystems.