https://thedotnetblog.com/es/tags/sql-server-2025/Articles, tutorials and insights from the .NET community.Hugoes@thedotnetblog (The .NET Blog)@thedotnetblogThu, 04 Jun 2026 00:00:00 +0000https://thedotnetblog.com/es/news/emiliano-montesdeoca/sql-server-maestro-agentic-ai-security-defense-in-depth/Thu, 04 Jun 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/es/news/emiliano-montesdeoca/sql-server-maestro-agentic-ai-security-defense-in-depth/La IA agéntica introduce amenazas para las que los modelos STRIDE tradicionales no fueron diseñados. Así es como Microsoft SQL se mapea al framework MAESTRO para proporcionar un límite de ejecución gobernado.<p>Los modelos de amenazas de seguridad se construyen sobre suposiciones sobre quién o qué está haciendo las solicitudes. STRIDE asume actores humanos que interactúan con sistemas a través de interfaces definidas. Los agentes de IA no funcionan de esa manera.</p> <h2 id="stride-no-fue-diseñado-para-agentes-de-ia">STRIDE No Fue Diseñado para Agentes de IA</h2> <p>Los sistemas agénticos operan de forma autónoma, encadenan herramientas a través de llamadas a APIs, toman decisiones sobre qué datos recuperar y qué acciones ejecutar, y pueden recibir instrucciones de múltiples fuentes — prompts del usuario, resultados de herramientas, datos recuperados. El modelo de amenaza STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) no captura adecuadamente vectores de ataque específicos de agentes como la inyección de prompts, el envenenamiento de contexto o el abuso de herramientas.</p> <p>La Cloud Security Alliance publicó el framework MAESTRO específicamente para el riesgo de agentes de IA.</p> <h2 id="el-framework-maestro">El Framework MAESTRO</h2> <p>MAESTRO organiza el riesgo de IA agéntica en siete capas:</p> <ol> <li><strong>Foundation Models</strong> — los LLMs subyacentes y sus vulnerabilidades de entrenamiento</li> <li><strong>Data Operations</strong> — recuperación, almacenamiento y manipulación de datos</li> <li><strong>Agent Frameworks</strong> — el middleware de orquestación y coordinación de agentes</li> <li><strong>Deployment &amp; Infrastructure</strong> — donde se ejecutan los agentes y cómo se configuran</li> <li><strong>Evaluation &amp; Observability</strong> — monitoreo del comportamiento de los agentes en el tiempo</li> <li><strong>Security &amp; Compliance</strong> — controles de acceso, auditoría y cumplimiento normativo</li> <li><strong>Agent Ecosystem</strong> — cómo los agentes interactúan entre sí y con herramientas externas</li> </ol> <p>Cada capa tiene vectores de ataque específicos que las controles de seguridad tradicionales no abordan directamente.</p> <h2 id="microsoft-sql-como-límite-de-ejecución-gobernado">Microsoft SQL Como Límite de Ejecución Gobernado</h2> <p>SQL Server 2025 se mapea a las capas de MAESTRO de formas concretas:</p> <p><strong>Capa de Operaciones de Datos</strong>: <code>AI_GENERATE_EMBEDDINGS</code> integrado en T-SQL mantiene las operaciones de vectores dentro del límite gobernado de la base de datos. Los datos no necesitan salir al servicio del modelo para el procesamiento de embeddings.</p> <p><strong>Capas de Seguridad y Compliance</strong>: La seguridad a nivel de fila (RLS) y el enmascaramiento dinámico de datos (DDM) se aplican independientemente de cómo llegó la solicitud — sea de un usuario humano o un agente de IA. El agente no puede eludir controles que son impuestos por la base de datos misma.</p> <p><strong>Capa de Agent Frameworks</strong>: Los procedimientos almacenados sirven como límites de herramientas. En lugar de dar a los agentes acceso SQL arbitrario, defines las operaciones permitidas como procedimientos y los expones como herramientas de agente. Las consultas parametrizadas previenen la inyección a nivel de ejecución.</p> <p><strong>Capa de Evaluation &amp; Observability</strong>: El registro de auditoría y Query Store capturan lo que cada agente ejecutó realmente — no solo lo que se le pidió que hiciera. Esta trazabilidad es crítica para investigaciones de incidentes en sistemas agénticos donde la atribución es compleja.</p> <h2 id="defense-in-depth-para-ia-agéntica">Defense-in-Depth para IA Agéntica</h2> <p>El principio se mantiene igual que en la seguridad tradicional: ningún control único es suficiente. Lo que cambia es qué controles importan más para los agentes:</p> <p><strong>Reducir el radio de impacto</strong>: los límites de herramientas de procedimientos almacenados significan que un agente comprometido solo puede ejecutar operaciones predefinidas. No puede pivotar a consultas arbitrarias.</p> <p><strong>Observabilidad</strong>: debes ser capaz de responder &ldquo;¿qué hizo exactamente este agente?&rdquo; después de un incidente. Los sistemas de IA agéntica sin trazabilidad a nivel de base de datos tienen puntos ciegos que la registración de aplicaciones no cubre.</p> <p><strong>Ejecución restringida</strong>: la parametrización, RLS y DDM son activos de seguridad independientemente de si el llamador es humano. No los debilites para acomodar agentes.</p> <p><strong>Responsabilidad</strong>: el registro de auditoría de SQL Server crea un registro de quién (qué agente, usando qué credenciales) ejecutó qué en qué momento. Esto importa cuando los sistemas agénticos toman acciones con consecuencias reales en el mundo.</p> <p>SQL Server 2025 no fue construido para resolver el riesgo agéntico en abstracto — fue construido para ser una base de datos relacional. Pero la gobernanza que hace a una base de datos empresarial confiable resulta ser exactamente lo que hace que un límite de ejecución de agentes sea seguro.</p> <p>Post original: <a href="https://devblogs.microsoft.com/azure-sql/microsoft-sql-security-across-the-maestro-stack-building-secure-agentic-ai-with-defense-in-depth/">Microsoft SQL Security Across the MAESTRO Stack</a></p>