Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

What PCI DSS 4.0 Requires for Infrastructure Identity and Access Evidence

Most conversations about PCI DSS 4.0 start with the requirements, but I’d rather start with a habit. As a GRC & Cybersecurity Consultant advising organizations preparing for PCI DSS 4.0 assessments, I’ve developed a habit of observing how findings move from identification to ownership, remediation, and documented closure. That’s often where accountability gaps and unresolved findings surface first.

AI Agent Security: Detecting Risky Behavior (Live Demo)

Watch five AI agents tackle a CTF and start coordinating with one another. Learn how to detect risky agent behavior using @goteleport graphs, risk scoring, and custom classifiers. Ben Arent explores lessons from the Hugging Face incident, then demonstrates how agent identity, scoped access, and activity monitoring help secure AI agents running against infrastructure.

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?

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.

ISO 42001 Evidence: What Auditors Ask For

ISO 42001 is the management system standard for artificial intelligence. It sits on the backbone of ISO 27001 but with a different focus: do you have a system for governing AI, and can you prove that system runs, with evidence? Core to the standard is an Artificial Intelligence Management System (AIMS), a structured set of policies, processes, and controls an organization uses to govern AI.

What tasks should AI take over?

What part of your profession do you hope AI takes over? What should it never touch? Security practitioners and technology leaders landed in the same place: hand off the tedious work, and keep human judgment on anything that affects blast radius. That's the skills reckoning. As AI absorbs the repetitive work, the expertise that decides what an agent is allowed to reach becomes more valuable.