Security Automation Is a Production Change: What Agentic SOCs Get Right in Kubernetes

A security tool detects suspicious activity in a Kubernetes pod and deletes the pod. The alert closes. The ReplicaSet behind the Deployment starts a replacement pod from the same image, with the same vulnerability.

The automation has accomplished little beyond destroying potential evidence. Unless investigators captured the container’s filesystem and runtime state beforehand, some of the forensic record is gone. The attacker might also notice the interruption.

AWS warns about deleting compromised pods managed by Kubernetes controllers. Replacement pods inherit the same vulnerable configuration, and considering that 60% of containers last a minute or even less, deleting a container cannot qualify as meaningful containment.

In Red Hat’s 2024 survey, 45% of respondents said their organizations had runtime incidents in the prior 12 months. Security tools shouldn’t get to make this change without the review a platform engineer would expect for any other production operation. An agentic SOC that takes response actions in Kubernetes inherits that standard.

Security Automation Has to Answer to SRE

Google’s Site Reliability Engineering book attributes roughly 70% of outages to changes in live systems. Engineers using documented incident-response playbooks achieve mean time to repair (MTTR) roughly three times faster than engineers improvising their response.

A documented procedure helps engineers recover faster because they already understand the steps and their consequences. The difficult part for security automation is deciding which procedure applies.

Take a process alert during a rollout. The process might belong to the new application version, or the rollout might have introduced a compromised image. Checking the process name against another allowlist won’t settle the question.

Adding more branches to a playbook means accounting for different namespace owners, service dependencies, and workload permissions. Those details change as teams update their clusters, leaving security engineers to maintain rules based on assumptions made when they wrote the playbook.

Prophet Security, a leading agentic AI SOC platform recognized in Rising in Cyber 2026, keeps the investigation agentic and the response deterministic: agents investigate each alert using current deployment and identity context, then run a predefined Agent Action only within approved limits. Its SOAR vs. AI SOC article describes the split as agentic where judgment lives, deterministic where response lives.

Ask Kubernetes Before Changing Kubernetes

Git and Argo CD history show which image or configuration was deployed and when. Checking those records against the alert shows whether the suspicious activity followed a rollout, including one that introduced a compromised image.

The pod’s ownerReferences identify its owning ReplicaSet, which in turn identifies the Deployment responsible for running it. Deleting a controller-managed pod triggers a replacement unless the response also addresses the controller’s desired state.

Namespace labels help identify the responsible team if they’re kept up to date. Check the pod’s network configuration, too. With hostNetwork: true, the pod shares the node’s network namespace, so ordinary pod-level NetworkPolicy rules won’t isolate it as expected.

The service account and cloud workload identity bindings show which permissions the pod holds. If an attacker has already stolen credentials, deleting the pod won’t revoke them.

There is little reason to maintain another copy of this information in a security product. An agent retrieves the records during the investigation, using the configuration and ownership data platform engineers already maintain. Prophet makes a related argument about consulting current identity context before a runtime decision.

Argo CD Might Undo Your Containment

To stop a Service routing traffic to a suspicious pod, teams can change one of the labels used by its selector. That won’t necessarily close existing connections or prevent direct access to the pod. A deny-all NetworkPolicy offers another option, provided the cluster’s networking plugin enforces it.

If the node is suspect, cordoning prevents new pods from being scheduled there. It leaves running workloads untouched, though, so investigators still need to establish whether the attacker has access. They may also need to preserve forensic evidence or rotate exposed credentials.

An automation modifying an Argo CD-managed NetworkPolicy directly in the cluster creates drift from Git. If automated self-healing is enabled, Argo CD can restore the configuration declared in Git, removing the emergency restriction.

Argo CD generally leaves an emergency NetworkPolicy alone if it sits outside the application’s managed resources. Whether it stays in place depends on how resource ownership and pruning are configured.

For resources Argo CD does manage, the restriction needs to be committed to Git or kept in place through an approved emergency procedure until Git is updated. Any separate isolation policy also needs an owner responsible for removing it when the incident is over.

Who Gets to Approve the Change?

Sysdig’s 2025 research talks about an attack window of roughly 10 minutes. Mature teams begin responding in around 3.5 minutes.

An approval process that takes longer than the attack itself does not leave much room for containment to be effective. However, automatically revoking credentials or intervening at the node level comes with consequences that go beyond the original alert.

Evidence collection is a sensible candidate for autonomous execution. Rotating credentials used by several production services needs an impact assessment. Cordoning a node requires awareness of available cluster capacity, especially during a deployment or an existing incident.

Platform engineering and SecOps need to decide in advance how much production access to give security automation. Some actions warrant automatic execution. Others need approval from someone responsible for the affected systems. The logs must identify who authorized the change and what the automation did.

Start with an automation already running in production. Look at the information available when the alert fired and the command the tool executed. Did it check which Deployment owned the pod? Did anyone account for Argo CD self-healing before changing a managed resource?

As agentic SOCs take on more response decisions, the review gate that a platform team already applies to every deploy is the natural place for those decisions to land.