On February 25, 2026, Gartner published its inaugural Market Guide for Guardian Agents, marking an important milestone for this emerging category. For those unfamiliar with the various Gartner report types, “a Market Guide defines a market and explains what clients can expect it to do in the short term. With the focus on early, more chaotic markets, a Market Guide does not rate or position vendors within the market, but rather more commonly outlines attributes of representative vendors that are providing offerings in the market to give further insight into the market itself.”

And if Guardian Agent is an unfamiliar term, Gartner defines it quite simply. “Guardian agents supervise AI agents, helping ensure agent actions align with goals and boundaries.” Enterprise security and identity leaders can request a limited distribution copy of the Gartner Market Guide for Guardian Agents.

Learning 1: Why Guardian Agent technology is important

One need only to read the news- in the Wall Street Journal, The Financial Times, Forbes, Bloomberg, the list goes on- to see that AI agents are a thing now. But Team8’s 2025 CISO Village Survey quantified it, finding that:

• Nearly 70% of enterprises already run AI agents (any system that can answer and act) in production.
• Another 23% are planning deployments in 2026.
• Two-thirds are building them in-house. 

However, in the market guide, Gartner asserts that this fast enterprise adoption is outpacing traditional governance controls. This raises the risk that “as AI agents become more autonomous and embedded in critical workflows, the risks of operational failure and noncompliance escalate.”

We concur, having read about the recent cloud provider outages stemming from autonomous AI agent actions, which do not surprise us. What we see across early adoption is that, even more so than traditional service accounts, AI agent deployment creates more identity dark matter- the invisible and unmanaged layer of identity. It includes the local credentials authentication that may be offered. The never-expiring tokens that are easily forgotten. Full permission access is granted, regardless of the user or job. And more.

Not only that, as we shared in our piece on “Lazy LLMs,” AI agents are, by design, shortcut seekers; always looking for the most efficient path to return a satisfactory outcome to each prompt. However, in doing so, they often exploit identity dark matter- orphan, dormant accounts or loose tokens, usually with local clear-text credentials and excessive privileges- that allow them to reach the “end of job,” regardless of whether they should have been allowed to do so. This is how unintended or unimaginable incidents arise.

As if that weren’t enough business risk, we note that the 2026 CrowdStrike Global Threat Report goes one step further, sharing that “Adversaries are also actively exploiting AI systems themselves, injecting malicious prompts into GenAI tools at more than 90 organizations and abusing AI development platforms.”

To learn more about how AI agents both expand what we call “Identity Dark Matter” and even exploit it themselves, check out our previous article in The Hacker News.

Learning 2: Core capabilities of Guardian Agents

So, having established the need for AI agent supervision, the next question for us becomes how, technically, to address that need. This is where, in our opinion, Gartner is extremely valuable- looking across the market and vendors to understand what is possible and winnowing it down to what’s most valuable, given the problem to be solved.

The market guide outlines mandatory features in 3 core areas:

1. AI Visibility and Traceability: Can you see and follow the actions of each AI agent? 
2. Continuous Assurance and Evaluation: How do you retain confidence that agents remain secure from compromise and compliant in action? 
3. Runtime Inspection and Enforcement: “ensure that AI agents’ actions and outputs match defined intentions, goals, and governance policies, preventing unintended behaviors.”

There are 9 detailed features across these core areas detailed in the market guide. Many of these have helped shape many of the 5 principles we believe underpin secure (and productive) use of AI agents.

1. Pair AI Agents with Human Sponsors: It is our belief that every agent should not only be identified and monitored, but also tied to an accountable human operator. 
2. Dynamic, Context-Aware Access: We believe AI agents should not hold standing, permanent privileges. Their entitlements should be time-bound, session-aware, and limited to least privilege.
3. Visibility and Auditability: In our view, visibility isn’t just “we logged it.” You need to tie actions to data reach: what the agent accessed, what it changed, what it exported, and whether that action touched regulated or sensitive datasets. 
4. Governance at Enterprise Scale: In our minds, AI agent adoption should extend across both new and legacy systems within a single, consistent governance fabric, so that security, compliance, and infrastructure teams are not working in silos. 
5. Commitment to Good IAM Hygiene: As with all identities, authentication flows, authorization permissions, and implemented controls, strong hygiene- on the application server as well as the MCP server- is critical to keep every user within the proper bounds.

Learning 3: Different vendor approaches to Guardian AI

That said, even when vendors try to address the same Guardian Agent requirements, they often solve the problem using very different architectural models.

Gartner outlines six emerging delivery and integration approaches, which, for adopters, matter more than they may first appear. These are not just packaging choices. They determine where control lives, how much visibility you actually get, how enforceable the policy is, and how much of your agent estate will fall outside coverage.

Here is our quick take on each model:

• Standalone Oversight Platforms are typically the easiest place to start. They collect logs, telemetry, and events into one place and can provide meaningful posture visibility, auditability, and analysis. But many of these platforms still lean more toward observation than intervention. That is useful, but it is not the same as control. If your AI risk posture depends on stopping bad actions before they happen, visibility alone will not be enough.
• AI/MCP Gateways are the most intuitive model: put a control point in the middle and force agent traffic through it. That can create a powerful centralized layer for monitoring and policy enforcement across multiple agents. But it only works if traffic actually goes through that layer. In practice, gateways can become both a bottleneck and a false comfort. If teams bypass them, or if agent interactions happen outside the governed path, visibility breaks down quickly.
• Embedded or In-Line Run-Time Modules sit closer to execution, inside the agent platform, an AI management platform, or an LLM proxy. That makes them appealing because they are often easier to turn on and can act with more immediacy. The downside is that they are usually platform-bound. They govern the environment they live in, not the broader enterprise. For adopters, that means great local control, but weak enterprise-wide consistency if your agents span multiple stacks.
• Orchestration Layer Extensions are attractive in environments where orchestration already acts as the operating layer for multi-agent workflows. They can add policy, visibility, and oversight at the workflow level. But they also assume orchestration is where meaningful control should sit. That is only true if the organization actually runs its agents through a common orchestration layer. Many will not. So for adopters, this model is powerful in the right architecture and irrelevant in the wrong one.
• Hybrid Edge – Cloud Models are where things start to get more realistic. As Gartner notes, these are becoming more important as agent ecosystems become more endpoint-centric. This model spreads oversight between local execution environments and cloud analysis, which can reduce latency and improve runtime relevance. For adopters, the value is clear: it avoids over-centralizing everything in one choke point. But it also raises the complexity bar. Distributed governance is stronger in theory, but harder to implement well. 
• Coordination Mechanisms standards, APIs, and hooks are less a deployment model than the connective tissue between them. And today, that tissue is immature. Gartner is explicit that integration across AI agent platforms remains difficult because standard interfaces are still lacking. That means adopters should be careful not to mistake “supports standards” for “works seamlessly in production.” The coordination layer is necessary, but it is not yet mature enough to be treated as solved.

Regardless of technical approach, Gartner gives clear guidance about the need for something more than the governance of individual AI agents built into a single cloud provider, identity tool, or AI platform. Specifically, they call out the following:

“A neutral, trusted guardian agent layer with multiple guardian agents performing separate but integrated oversight functions enforces routing across all providers. Thus, the guardian agent acts as the missing universal enforcement mechanism.”

Learning 4: Guardian Agents Will Become an Independent Layer of Enterprise Control

Perhaps the most important long-term takeaway for us from the Market Guide is that Guardian Agents will not simply be another feature embedded in AI platforms. As we read it, Gartner is quite explicit: “enterprises will require independent guardian agent layers that operate across clouds, platforms, identity systems, and data environments.”

Why? Because AI agents themselves do not live in one place.

Agents interact with APIs, applications, data repositories, infrastructure, and even other agents across multiple environments. A cloud provider may be able to supervise agents running inside its own ecosystem, but once those agents call tools, delegate tasks, or operate across providers, no single platform can enforce governance alone.

That is why we believe Gartner argues that organizations will increasingly deploy enterprise-owned guardian agent layers that sit above individual platforms and supervise agents across the full enterprise environment.

In other words, governance cannot live only inside the platforms that create or host AI agents. It needs to live above them.

Put simply: the future of agent governance will not be platform-native supervision. It will be enterprise-owned oversight. And the organizations that adopt that architecture early will be far better positioned to scale agentic AI safely, without introducing a new generation of invisible automation risk across their infrastructure, data, and identities.

Learning 5: There is Still Time, But Not Forever

For all of the excitement about AI agents and the big brand news stories about them replacing jobs, the Guardian Agent market is still early. According to Gartner, “Today, guardian agent deployments are mainly prototypes or pilots, although advanced organizations are already using early versions of them to supervise AI agents.” 

But it’s coming fast. They note that “the guardian agent market — encompassing technologies for the oversight, security, and governance of autonomous AI agents — is entering a phase of accelerated growth, underpinned by the rapid adoption of agentic AI across industries.”

Frankly, we would make a similar statement about the Agentic market overall. Yes, we have implemented AI agents within Orchid- the company and the product. But organizations, ourselves included, are just scratching the surface of what’s possible. Have individual employees started using their own personal AI agents? Yes. Do many technology vendors offer built-in AI agents, beyond the simple chatbot? Yes. Have some of the earliest adopters implemented a corporate standard platform to augment or replace jobs? Yes (but said with some skeptical hesitation).

However, as the saying goes, it’s too late to bar the door after the horse is out of the barn. Orchid Security recommends that you ensure AI agent visibility sooner rather than later, and for sure, establish the same identity and access management guardrails and governance required for human users are indeed in place to similarly guide their AI companions, before the horse is out of the barn. 

The Bottom Line (We Will Say it Again)

AI agents are here. They are already changing how enterprises operate.

The challenge is not whether to use them, but how to govern them.

Safe adoption of AI agents requires applying the same principles that identity practitioners know well, least privilege, lifecycle management, and auditability, to a new class of non-human identities that follow this protocol.

If identity dark matter is the sum of what we can’t see or control, then unmanaged AI agents may become its fastest-growing source, if left unchecked. The organizations that act now to bring them into the light will be the ones who can move quickly with AI without sacrificing trust, compliance, or security. That’s why Orchid Security is building identity infrastructure to eliminate dark matter, and make Agent AI adoption safe to deploy at enterprise scale.

La ciberseguridad ha cambiado rápidamente. Los roles son más especializados y las herramientas son más avanzadas. Sobre el papel, esto debería hacer que las organizaciones sean más seguras. Pero en la práctica, muchos equipos luchan con los mismos problemas básicos que enfrentaron hace años: prioridades de riesgo poco claras, decisiones de herramientas desalineadas y dificultad para explicar los problemas de seguridad en términos que la empresa entienda.

Estos desafíos no suelen surgir de la falta de esfuerzo. Surgen de algo más sutil, una pérdida gradual de comprensión fundamental a medida que se acelera la especialización. La especialización en sí misma no es el problema. La falta de contexto lo es. Cuando los equipos de seguridad no tienen una comprensión compartida de cómo encajan el negocio, los sistemas y los riesgos, incluso una ejecución técnica sólida comienza a fallar. Con el tiempo, esa brecha aparece en la forma en que se diseñan los programas, se eligen las herramientas y se manejan los incidentes. Desafortunadamente, he visto este patrón repetidamente cuando ayudo con incidentes y programas de seguridad en organizaciones de todos los tamaños.

La especialización sin contexto reduce el panorama de riesgos

La ciberseguridad es inusual por la rapidez con la que los profesionales pueden especializarse. En muchas profesiones, la formación básica amplia es lo primero. Aprende cómo funciona el sistema antes de centrarse en una sola parte del mismo. Consideremos, por ejemplo, que uno se convierte en médico antes de convertirse en cirujano especializado. En seguridad, a menudo ocurre al revés. Las personas pasan directamente a funciones específicas, como seguridad en la nube, ingeniería de detección, análisis forense o IAM, con una exposición limitada a cómo encaja el entorno más amplio. Con el tiempo, esto crea equipos que son altamente capaces dentro de sus dominios pero desconectados del panorama de riesgo más amplio.

El desafío resultante es la falta de visibilidad de un extremo a otro. Cuando solo se ve una parte del entorno, resulta más difícil razonar sobre cómo se mueven las amenazas, cómo interactúan los controles o por qué ciertos riesgos son más importantes que otros. El riesgo deja de ser algo que se comprende de manera integral y se convierte en algo que sólo se ve a través del estrecho lente de su función. Aquí es donde fracasan muchas conversaciones sobre seguridad. Se plantea un problema de seguridad, pero no está relacionado con el funcionamiento real de la organización. Sin esa conexión, la preocupación suena abstracta. No logra resonar, no porque carezca de importancia, sino porque carece de contexto.

Cuando las herramientas reemplazan la comprensión, los programas se desvían

Otro patrón que aparece repetidamente es cómo las decisiones de seguridad se centran en productos en lugar de procesos. Se pregunta a los equipos por qué necesitan una herramienta y la respuesta se centra en las características o tendencias de la industria en lugar del riesgo específico que aborda dentro de la organización. Cuando una herramienta no puede vincularse al riesgo organizacional, generalmente significa que el problema subyacente no se ha definido claramente. La seguridad se convierte en algo que se compra en lugar de algo que se diseña.

Un programa de seguridad funcional comienza con la empresa. ¿Por qué existe la organización? ¿Para qué misión cumple? ¿Qué sistemas y datos son esenciales para esa misión? Sin respuestas claras a esas preguntas, es imposible saber qué es lo que realmente es necesario proteger. Los atacantes lo entienden bien. Para alterar un negocio, deben identificar qué es lo más importante y dónde se sentirá el impacto. Los defensores que carecen de esa misma claridad siempre están reaccionando. Están respondiendo a alertas y vulnerabilidades sin un claro sentido de prioridad. El conocimiento fundamental ayuda a prevenir esa deriva. Permite a los equipos trabajar desde la misión hasta los activos y el riesgo, en lugar de hacerlo desde la herramienta hasta la alerta y la remediación.

La detección, la respuesta y la prevención dependen de conocer lo «normal»

Muchas fallas de seguridad se deben a un problema simple: los equipos no saben cómo es lo normal en sus propios entornos. La detección se vuelve difícil cuando no se comprende bien el comportamiento esperado. La respuesta se ralentiza cuando las preguntas básicas sobre sistemas, usuarios y flujos de datos no pueden responderse rápidamente. La prevención se convierte en conjeturas cuando los incidentes pasados ​​no se pueden explicar ni aprender con claridad.

Este no es un problema de herramientas. Es un problema de familiaridad. Conocer sus sistemas, su red y cómo opera su organización día a día es fundamental. Es lo que permite que las anomalías se destaquen y que las investigaciones avancen con confianza. Cuando los equipos se saltan este trabajo, se ven obligados a desarrollar esta comprensión durante los incidentes, cuando la presión es mayor y los errores son más costosos. Las capacidades avanzadas sólo funcionan cuando se basan en una comprensión básica adecuada.

Domine sus habilidades fundamentales en SANS Security West 2026

La ciberseguridad moderna depende de la especialización. Eso no va a cambiar. Lo que sí es necesario cambiar es la suposición de que la especialización por sí sola es suficiente. Las habilidades fundamentales permiten a los equipos especializados razonar sobre los riesgos, comunicarse claramente con la empresa y tomar decisiones que se mantengan bajo presión. Crean un contexto compartido, que a menudo es lo que falta cuando los programas fallan, las herramientas se acumulan o los incidentes se estancan.

A medida que los entornos se vuelven más complejos, esa comprensión compartida se convierte en un requisito, no en algo agradable de tener. Este mes de mayo estaré presentando SEC401: Conceptos básicos de seguridad: red, punto final y nube en Seguridad SANS Oeste 2026 para equipos y profesionales que desean fortalecer esas bases y aplicar sus habilidades especializadas con un contexto más claro en todos los programas de seguridad modernos.

Nota: Este artículo ha sido escrito y contribuido por expertos de Bryan Simon, instructor sénior de SANS.

Citrix ha lanzado actualizaciones de seguridad para abordar dos vulnerabilidades en NetScaler ADC y NetScaler Gateway, incluida una falla crítica que podría explotarse para filtrar datos confidenciales de la aplicación.

Las vulnerabilidades se enumeran a continuación:

• CVE-2026-3055 (Puntuación CVSS: 9,3) – Validación de entrada insuficiente que provoca una lectura excesiva de la memoria
• CVE-2026-4368 (Puntuación CVSS: 7,7) – Condición de carrera que provoca una confusión en la sesión del usuario

Empresa de ciberseguridad Rapid7 dicho que CVE-2026-3055 se refiere a una lectura fuera de límites que podría ser explotada por atacantes remotos no autenticados para filtrar información potencialmente confidencial de la memoria del dispositivo.

Sin embargo, para que la explotación sea exitosa, el dispositivo Citrix ADC o Citrix Gateway debe estar configurado como proveedor de identidad SAML (SAML IDP), lo que significa que las configuraciones predeterminadas no se ven afectadas. Para determinar si el dispositivo se ha configurado como perfil IDP SAML, Citrix insta a los clientes a inspeccionar su configuración de NetScaler para ver la cadena especificada: «agregar autenticación samlIdPProfile .*».

CVE-2026-4368, por otro lado, requiere que el dispositivo esté configurado como una puerta de enlace (es decir, SSL VPN, ICA Proxy, CVPN y RDP Proxy) o una autenticación, autorización y contabilidad (aaa) servidor. Los clientes pueden verificar la configuración de NetScaler para determinar si sus dispositivos se han configurado como cualquiera de los nodos:

• Servidor virtual AAA: agregue autenticación vserver.*
• Puerta de enlace: agregue vpn vserver.*

Las vulnerabilidades afectan a NetScaler ADC y NetScaler Gateway versiones 14.1 anteriores a 14.1-66.59 y 13.1 anteriores a 13.1-62.23, así como a NetScaler ADC 13.1-FIPS y 13.1-NDcPP anteriores a 13.1-37.262. Se recomienda a los usuarios que apliquen las últimas actualizaciones lo antes posible para una protección óptima.

Si bien no hay evidencia de que las deficiencias hayan sido explotadas en la naturaleza, las fallas de seguridad en los dispositivos NetScaler han sido explotadas repetidamente por actores de amenazas (CVE-2023-4966, también conocido como Citrix Bleed, CVE-2025-5777, también conocido como Citrix Bleed 2, CVE-2025-6543 y CVE-2025-7775), lo que hace imperativo que los usuarios tomen medidas para actualizar sus instancias.

«CVE-2026-3055 permite a atacantes no autenticados filtrar y leer memoria sensible de implementaciones de NetScaler ADC. Si suena familiar, es porque lo es: esta vulnerabilidad suena sospechosamente similar a Citrix Bleed y Citrix Bleed 2, que continúan representando un evento traumático para muchos», dijo el CEO y fundador de watchTowr, Benjamin Harris, a The Hacker News.

«Los NetScalers son soluciones críticas que han sido objeto continuamente de acceso inicial a entornos empresariales. Si bien el aviso acaba de publicarse, los defensores deben actuar rápidamente. Cualquiera que ejecute versiones afectadas debe aplicar parches urgentemente. Es muy probable que se produzca una explotación inminente».

Un ciudadano ruso de 26 años ha sido condenado en Estados Unidos a 6,75 años (81 meses) de prisión por su papel en la asistencia a importantes grupos de ciberdelincuencia, incluido el Yanluowang equipo de ransomware, en la realización de numerosos ataques contra empresas estadounidenses y otras organizaciones.

Según el Departamento de Justicia de Estados Unidos (DoJ), Alekséi Olegóvich Vólkov facilitó docenas de ataques de ransomware en todo Estados Unidos, causando más de 9 millones de dólares en pérdidas reales y más de 24 millones de dólares en pérdidas previstas. Volkov fue arrestado el 18 de enero de 2024 en Italia y extraditado a Estados Unidos para enfrentar cargos. Se declaró culpable de los crímenes en noviembre de 2025.

Se dice que Volkov actuó como intermediario de acceso inicial responsable de obtener acceso no autorizado a redes y sistemas informáticos pertenecientes a varias organizaciones y vender ese acceso a otros grupos delictivos, incluidos los actores de ransomware. Esto se logró explotando vulnerabilidades o encontrando formas de acceder a las redes sin autorización.

«Los cómplices de Volkov utilizaron el acceso proporcionado por Volkov para infectar las redes y sistemas informáticos afectados con malware», dijo el Departamento de Justicia. dicho. «Este malware cifró los datos de las víctimas y les impidió acceder a ellos, dañando sus operaciones comerciales».

«Los conspiradores luego exigieron que las víctimas les pagaran un rescate en criptomonedas, a veces de decenas de millones de dólares, a cambio de restaurar el acceso de las víctimas a los datos y prometer no revelar públicamente el hackeo ni liberar los datos robados de las víctimas en un sitio web de ‘filtración’».

Cada vez que una víctima pagaba un rescate, Volkov recibía una parte de las ganancias ilícitas. Fue acusado de transferencia ilegal de un medio de identificación, tráfico de información de acceso, fraude de dispositivos de acceso y robo de identidad agravado, además de dos cargos de fraude informático y conspiración para cometer lavado de dinero.

Como parte de la declaración de culpabilidad, el acusado acordó pagar una restitución total a las víctimas, incluidos al menos $9,167,198 a víctimas conocidas para compensarlas por sus pérdidas reales, además de perder las herramientas utilizadas para llevar a cabo los crímenes.

Estados Unidos acusa a un tercer negociador de ransomware vinculado a los ataques de BlackCat

La revelación se produce cuando los fiscales estadounidenses cargado un tercer individuo actúa como negociador para la banda de ransomware BlackCat (también conocido como ALPHV), ayudando a los actores de amenazas a extorsionar pagos más altos de al menos 10 víctimas. El hombre de 41 años, Angelo Martino (anteriormente identificado sólo como «Co-Conspirador 1»), trabajó como negociador de ransomware para DigitalMint.

Las autoridades han confiscado casi 9,2 millones de dólares en cinco tipos de criptomonedas (Bitcoin, Monero, Ripple, Solana y Stellar) de 21 carteras controladas por Martino, además de incautar vehículos y propiedades de lujo. Se enfrenta a hasta 20 años de prisión. Otros dos socorristas de incidentes, Ryan Clifford Goldberg y Kevin Tyler Martin, se declararon culpables de sus funciones como afiliados de BlackCat en diciembre de 2025.

En una declaración compartida con The Record, DigitalMint dijo que las acciones violaban la política y los estándares éticos de la compañía, y que había despedido tanto a Martino como a Martin después de que su comportamiento saliera a la luz.

«DigitalMint condena el comportamiento criminal de estos individuos, que es una clara violación de nuestros valores, nuestras normas éticas y la ley», afirma. dicho. «Tanto nuestra empresa como nuestra industria existen para apoyar a las organizaciones que sufren los impactos de un ciberataque, y esto va completamente en contra de lo que defendemos».