Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

In March 2026, attackers from the TeamPCP group compromised Trivy (CVE-2026-33634) — a widely-deployed open-source vulnerability scanner running in thousands of CI/CD pipelines — and turned it into a credential harvester. SSH keys, Kubernetes secrets, cloud tokens — secrets accessible to any pipeline that ran a compromised version — were exposed. The attacker retained access long enough to exfiltrate newly rotated secrets before the window closed.

AI agents querying databases pose well-documented risks. What gets less attention is the fact that PostgreSQL has no native concept of an agent as a distinct actor. This means DBAs are managing access for something that appears in pg_stat_activity like any other role created with CREATE ROLE, with no distinguishing attributes and no indication of who or what initiated the connection. AI agents have no distinct identity when interacting with PostgreSQL.

Cloud service providers preparing for FedRAMP 20x are encountering a fundamentally different authorization model than the one their compliance programs were built around. The traditional FedRAMP path produced lengthy System Security Plans, point-in-time assessments, and human-readable narrative evidence.

When your AI agent calls an MCP tool, that tool has no idea who actually triggered the request. It sees the agent, not you. This post explains why that matters and how to fix it with Teleport JWTs. In part two of this post, we will explain how to extend this to AWS to carry your identity through Amazon Bedrock AgentCore all the way into CloudTrail.

Traditionally, engineers have relied on shared database passwords. When someone needs to run a query, they either already have standing access granted via a static credential everyone on the team knows, or someone has to scramble to create a quick workaround. Every new user, exception rule, or port forward through a bastion host becomes a “just this once” fix.

Regulators and auditors now demand immutable proof of every privileged action, attributed to an identity, across Secure Shell (SSH), Kubernetes, databases, and Remote Desktop Protocol (RDP).

On workload identity, a spec the industry has already started building around, and what the next layer looks like. I don't have a better answer than SPIFFE (Secure Production Identity Framework for Everyone) for workload identity, and that's where I want to start, because what follows is going to sound like I do.

A device in your fleet encounters an issue. You try to SSH in only to discover that the IP changed overnight, the customer's firewall blocks inbound connections, and the VPN they set up six months ago stopped working when the device switched from Wi-Fi to cellular. The next several hours disappear into a Slack thread with the customer's IT team trying to get a port opened. Every engineer who has shipped hardware into a customer's environment has a version of this story.