Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Decibel Partners' Dan Nguyen-Huu on AI agents gaining user admin rights

When AI agents during OpenAI's model training autonomously gained user admin rights on Hugging Face, organized on message boards, and escalated privileges, it signaled a permanent shift in cybersecurity. Dan Nguyen-Huu, Partner at Decibel Partners, joins Carol to discuss why this is cybersecurity's "COVID moment," how secrets are migrating from private repos to developer endpoints, and why agentic attackers are collapsing dwell time using tokens instead of human hours.

Why the Hugging Face Incident Is Cybersecurity's COVID Moment

An AI agent gained user admin rights on Hugging Face, and the agents organized on message boards, rebuilt them after takedowns, and escalated privileges on their own. Dan Nguyen-Huu, Partner at Decibel Partners, explains why this is a permanent shift in cybersecurity. "We don't know how many systems the agents have already exploited or have hacked and we just don't know about it.".

8 Best AI Tools for DevOps in 2026

Building an effective AI DevOps stack in 2026 comes down to balancing platform-native assistants for workflow speed with specialized engines for security, infrastructure, and delivery governance. This guide evaluates the 8 leading tools across both categories to help you select the right mix for your architecture and security requirements. This approach reflects a fundamental shift in engineering capabilities.

Why Developer Endpoints Are the New Secrets Battleground

Secrets migrated from private repos to developer endpoints. Attackers no longer hack access. They log in with stolen credentials and move laterally. Dan Nguyen-Huu, Partner at Decibel Partners, explains what the shift means for defenders and where innovation is headed. "The endpoint is largely going to become one of the big new battlegrounds. I think there's also going to be new innovation on the endpoint as it pertains to new companies, maybe trying to think about DLP in a different way.".

Does an agent have more access than you do?

70% of organizations give AI more access than a human in the same role would get. Not surprising when it is common for a team to click “always” when an agent asks to be allowed once or always allowed. That means the agent holds that access in perpetuity and turns into agent over-provisioning. Makes you wonder: Does an agent have more access to your organization's stack than it should and more access than the people who deploy them?

WebInject: The Web Agent Prompt Injection With No Payload

A browser agent in your cluster opens a supplier portal, screenshots it, and clicks somewhere the task never called for. The page looks exactly like the page the supplier serves, and to the person who checks it later, it still does. The classifier in front of the agent returned nothing, because the instruction that produced the click does not exist.

Detection scaled. The loop did not.

Findings got cheap. Verified closure did not. That AppSec remediation gap is the actual problem. AppSec spent a decade winning the wrong race. We got very good at finding things. Scanners in CI. SCA on every manifest. SAST on every pull request. Container and IaC checks on the way to the cluster. Then AI arrived and did what AI does to a solved problem: it made discovery cheaper, louder, and continuous. The same model that writes the function will also enumerate the ways to break it.

An agent breaks in production. Who's accountable?

We asked eight security and product leaders who's accountable when an agent ships to production and breaks something. Nobody said the model. Harish Gaggar named the reason. An agent runs on permissions someone approved and configuration someone set. Ron Reiter drew the line in the same place, accountability sits with whoever decided what the agent could actually do. As agents act across more systems, the accountability trail gets harder to follow. Most teams cannot determine which human granted an agent access.

FIPS 140-2 vs FIPS 140-3, Explained

FIPS 140-3 is the current standard for validating cryptographic modules, which are the specific hardware or software components that implement encryption and manage keys inside a defined boundary. FIPS 140-3 was approved on March 22, 2019, became effective on September 22, 2019, and supersedes FIPS 140-2, which dates back to 2001. Most FIPS 140-3 security requirements come from ISO/IEC 19790:2012, with test requirements drawn from ISO/IEC 24759:2025.