Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Running your own certificate authority sounds like the responsible choice for internal infrastructure. Distribute your root cert to every machine and issue certs internally. In practice, you spend the next six months chasing down every device, contractor laptop, and vendor console that didn’t get root installed. The warnings come back. And when they do, people click through them, because they always have. There’s a simpler path, and most teams don’t know it exists.

A CNAPP isn’t a single instrument. It bundles five separately-instrumented security domains — CSPM, CWPP, CIEM, CDR, and a fifth add-on module marketed as AI security — each watching a different observation point. So when leadership asks whether your CNAPP can secure the AI agents your team has shipped, you don’t get one answer. You get five.

Most enterprise AI agent governance programs publish policies at the bottom three rungs of a runtime enforceability ladder while their architecture diagrams claim rung four. Almost no program reaches rung five, the only rung that produces evidence an auditor cannot dispute. The mismatch shows up in the audit committee meeting. The CISO walks in with the NIST AI RMF mapping, the AUP, the model cards, and the vendor risk assessments for every third-party API the agents call.

On 2026-05-22, an attacker rewrote every repository tag across four Composer packages in the Laravel-Lang ecosystem to point at malicious commits. The affected packages are laravel-lang/lang, laravel-lang/attributes, laravel-lang/http-statuses, and laravel-lang/actions. The rewrite took place on 2026-05-22 into the early hours of 2026-05-23. Every malicious commit makes the same two-file change: one entry added to composer.json, and one new file at src/helpersphp.

Your platform team already runs a production-readiness review on every workload that ships to Kubernetes. When the workload is an AI agent, the PRR doesn’t get thrown out — it gets a delta. Most of the items still apply; specific ones need extension when the workload is non-deterministic, calls tools dynamically, and exercises identity at runtime in ways the manifest didn’t predict.

Most threat modeling assumes the attacker has to break something. AI agents change that assumption. An attacker who controls a prompt can make the agent misbehave without breaking anything at all. The prompt can be a customer support ticket the agent reads, a document it retrieves, or a tool response it processes — any input the agent treats as context is an attack surface. On Kubernetes, that attack surface has physical form.

Every guide to AI agent observability tells you what to capture — prompts, tool calls, token usage, traces, syscalls. Almost none address which of those signal sources you can still trust when the agent itself is part of the threat model. That distinction is the entire difference between observability that helps your SRE team debug a slow reasoning chain and observability that helps your security team investigate a breach.

Our previous post, How to Secure Microservices with SPIFFE and Istio, showed how to secure Kubernetes microservices using Istio policy and SPIFFE identities, with Teleport issuing the identities that the mesh trusts. The question teams face next is: How do you extend that identity-driven security model to workloads outside Kubernetes — such as VMs, edge gateways, and legacy services — without creating a massive certificate-management project?

The Cyber Resilience Act (CRA) is an EU regulation that sets binding cybersecurity requirements for any "product with digital elements" placed on the European Union market. It is the first horizontal EU law that holds manufacturers accountable for the security of hardware and software throughout the entire product lifecycle—from design to end-of-support.