Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

If you run CertKit across multiple collections, September was your month. The new home page lets you search across all of them, the new dashboard surfaces the context you need, and a read-only API pulls it all into your external tools.

Technically: no. In practice: maybe. Lot’s of teams are experimenting with shorter duration certificates from Let’s Encrypt to get ready for the 47-day mandate. Those certs come with a big gotcha: no more Common Name. A modern browser is perfectly happy with a TLS certificate that has no Common Name. Your VPN or mail server might have other opinions. And since those are probably things you’d like to keep working, there’s a little more nuance to the answer.

Identity governance cannot tell you which AI agent did something. It records which identity is allowed what. In a cluster, one service account often serves several workloads, and every pod is replaced at the next rollout. As a result, the permission record and the behavior record point at different objects. Detection and investigation need a unit of attribution. The Deployment is the right one. It stays stable across restarts and replicas and changes only when someone ships a rollout.

Two of the three layers of agentic AI security already have an owner in your organization, and the third has none. Identity falls to IAM and interaction falls to AppSec, because the controls at both layers extend products those teams already run. The behaviour layer covers what the agent does on the infrastructure once it is running, and it sits between a platform team with no security mandate and a SOC with no sense of what normal looks like for an agent. That gap is where a coerced agent works.

TL;DR: A production kubeconfig that contains a certificate or token is a production credential, and every copy then accesses the cluster with the same identity. You should use individual single sign-on (SSO) logins and short-lived credentials for your clusters.