I just attended the RSA Conference 2026 this week. My honest read: the marketing has never been more sophisticated, and the gap between what’s being sold and what’s actually under attack has never been wider.
Let me give you the version no one’s booth was advertising.
The real attack surface isn’t agents. It’s your CI/CD pipeline — right now, today.
Before we talk about the agentic future, let’s talk about what happened last month.
Three weeks ago, we wrote about an autonomous bot called hackerbot-claw — describing itself as “an autonomous security research agent” — that spent seven days systematically attacking CI/CD pipelines across major open source repositories. It targeted seven projects belonging to Microsoft, DataDog, Aqua Security, and multiple CNCF members. It achieved confirmed or likely remote code execution in five of them. In one — Aqua’s Trivy, a vulnerability scanner embedded in thousands of CI pipelines — it stole a Personal Access Token, renamed the repository, deleted years of GitHub Releases, and pushed a potentially malicious artifact to the VS Code extension marketplace. The recent TeamPCP exploit continues to impact the open source community.
The attack vector isn’t exotic. It exploits a structural flaw in pull_request_target workflows: a trigger that runs with the base repository’s secrets and permissions while executing the attacker’s code. The bot loaded 47 sub-patterns, scanned for candidates, and iterated. On one target it took six attempts over 18 hours to achieve confirmed RCE. That’s machine-speed iteration against a surface most teams haven’t fully hardened.
That’s the shift: attackers no longer need to get code merged — or even reviewed. They just need to get automation to run.
This is not a future problem. It is a right-now problem.
Mandiant’s M-Trends 2026 report makes that urgency concrete: the median time between initial access and handoff to a secondary threat group collapsed from over 8 hours in 2022 to 22 seconds in 2025. Defenders are not losing because they lack visibility. They are losing because attackers move faster than any human response loop can match.
GitHub Actions is not a developer convenience anymore. It is production control plane infrastructure. Compromise workflow tokens, reusable actions, or release automation and you’re not attacking a build — you’re attacking trust in the software supply chain itself.
That is where I’d focus my energy before anything else at RSA.
The attestation gap no one is talking about
There was a lot of supply chain security conversation at RSA this year. Most of it stopped in the wrong place.
Here’s what we’ve learned building enforcement tools on top of Kyverno: generating attestations is table stakes. Enforcing them at admission is the gap most teams haven’t closed.
Provenance data and SBOMs get produced in CI, stored in the registry, and occasionally reviewed — but rarely enforced. That gap matters more than most teams realize. Without runtime enforcement at the Kubernetes admission boundary, even an SLSA Build Level 3 pipeline can be bypassed. A compromised credential or a manual image push can still introduce untrusted artifacts into production. Attestations improve visibility. They do not provide assurance.
The right question to ask any supply chain security vendor at RSA: “Where does enforcement actually happen?” Not detection. Not dashboards. Not a report generated post-deploy. Enforcement — the deterministic point where a policy is applied and an unverified artifact is blocked before it runs.
With Kyverno’s ImageValidatingPolicy, that enforcement happens at admission. The policy doesn’t just ask “Is this signed?” It asks: Who built it? Where was it built? Is the SLSA provenance valid? Does the OIDC subject match the authorized workflow? Only artifacts that answer all of those questions correctly reach production. We wrote about exactly how this works two weeks before RSA — the Checkmarx and Trivy incidents that week felt less like news and more like confirmation.
RSA 2026 was agent washing season — here’s how to spot it
I want to be fair: agent security is a real category. The underlying problems — identity for non-human actors, delegated authority, secret access, runtime boundaries, auditability across chains of tools — are real and will matter. Some vendors are doing serious work on pieces of this.
But most of what I saw on the floor was agent washing.
We’ve seen this playbook before. New platform shift, new budget narrative, old products repackaged in new language. Identity becomes agent identity. Privileged access management becomes agent access governance. A vulnerability scanner with a chatbot becomes AI-native. The packaging changes. The underlying control depth often does not.
Here’s the test I’d apply to any “agent security” pitch you’re evaluating:
Ask them: where does enforcement actually happen?
If the answer is vague — if it lands on monitoring, alerting, or a recommendation surfaced in a UI — you’re looking at a detection product with agent-era branding. That’s not nothing. But it’s not governance.
The honest state of the market: there is no broadly accepted control model for agent identity, privilege delegation, runtime policy, and observability across heterogeneous enterprise environments. No settled reference architecture. This year’s RSAC felt more like category invention than category maturity. Smart CISOs will watch carefully, pilot selectively, and not restructure their security program around it yet.
What enforcement-first security actually looks like
Most security tools at RSA are selling half a loop.
They detect. Some remediate. Almost none prevent recurrence. That distinction matters more than it sounds, because when change happens at AI speed, governance that ends in a report is not governing anything — it is observing.
The model that actually works in fast-moving infrastructure is closed-loop: Detect issues. Fix drift. Prevent recurrence. That last step is what most vendors skip, and it’s the only one that changes the economics of the attack.
Here is what I believe, and what I built Nirmata around: the only security controls that scale are the ones that are enforced, not advised.
In cloud-native environments, the enforcement points already exist. Admission control in Kubernetes. Policy checks in CI/CD pipelines. Guardrails at the IDE, at the Terraform layer, at the API gateway. These are not theoretical — they are production infrastructure that can carry policy today, deterministically, at the speed attacks move.
The hackerbot-claw campaign illustrated the kill chain precisely: compromise the pipeline, steal the token, push the artifact, reach the cluster. We walked through each step and the Kubernetes controls that break the chain — workflow hardening in CI, admission policies on privilege and registry, digest pinning to stop image substitution. None of that requires new tooling. It requires closing enforcement gaps that already exist.
And the next step beyond closed-loop is what we’re showing at RSA with our partners at Latent Defense: autonomous governance — where AI discovers real attack paths, Kyverno enforces the fix, and the system reruns the simulation to verify the path is actually closed. Not a report. Not a recommendation. A verified control. We wrote about this model four days before the conference opened, and the RSA floor made it feel even more urgent.
The deeper lesson from RSA this year
The winners in the next phase of enterprise security will not be the companies with the most “agentic” messaging. They will be the ones that bring real enforcement to real execution points.
The threat is moving in seconds. Your controls need to be in place before the request arrives — not after the alert fires. Detection tells you what happened. Closed-loop governance changes what can happen.
That is the deeper lesson from RSA this year. Not agents. Enforcement.
