Skip to main content
Sign in →

Visión general de la arquitectura

ShieldAgent aplica seguridad en el límite entre los agentes de IA y las herramientas que utilizan. La ubicación exacta de ese límite en tu stack es flexible — despliega el proxy inline entre el agente y el upstream, o usa la Verdict API del SDK para escanear solicitudes desde dentro del código de tu propio servidor antes de ejecutarlas.

Dónde posicionar ShieldAgent

ShieldAgent puede insertarse en varios puntos de la cadena de llamadas de agente a herramienta. La posición correcta depende de lo que controles en tu stack y el nivel de visibilidad que necesitas. Todas las posiciones usan el mismo pipeline de seguridad multi-etapa; solo el método de integración difiere. Las posiciones 2 y 3 usan la Verdict API del SDK — tu código envía los payloads de solicitud a ShieldAgent para escanearlos y aplica el veredicto devuelto.

Recomendado

Posición 1 — Proxy entre el agente y el MCP

El agente apunta su cliente MCP al proxy de ShieldAgent en lugar del servidor upstream directamente. Sin cambios de código en el agente ni en el servidor MCP. El proxy intercepta cada llamada a herramienta, ejecuta el pipeline de seguridad completo y reenvía las solicitudes aprobadas. Este es el modelo de despliegue principal y el que te da visibilidad completa de todas las llamadas a herramientas.

Ideal cuando: no posees el agente ni el servidor MCP, o quieres un despliegue sin intervención. La segmentación de red debe garantizar que los agentes no puedan eludir el proxy.

Verdict API

Posición 2 — Verdict API en tu propia API

Si tus agentes llaman a una API REST que tú posees y operas, usa el SDK de ShieldAgent para escanear cada solicitud entrante antes de ejecutarla. Tu servidor llama a client.scan() con el payload de la solicitud. ShieldAgent ejecuta el pipeline de seguridad completo multi-etapa y devuelve un veredicto (allow / block / human_review). Tu código aplica el veredicto — ejecuta si está permitido, rechaza si está bloqueado. El pipeline de seguridad se ejecuta en el proxy de ShieldAgent, no en proceso.

Ideal cuando: posees la capa de API que llaman tus agentes y quieres añadir escaneo de seguridad sin cambiar el flujo de tráfico. Tu código sigue en control — ShieldAgent escanea y devuelve un veredicto, tú lo aplicas.

TypeScript

your-api-handler.ts
import { ShieldAgentClient } from '@shieldagent/sdk';

const client = new ShieldAgentClient({
  baseUrl: 'https://proxy.shieldagent.io',
  apiKey: '{your-api-key}',
});

async function handleAgentRequest(agentId: string, method: string, path: string, body: unknown) {
  const verdict = await client.scan({
    tenantId: '{your-tenant-id}',
    agentId,
    toolName: `api:${method}:${path}`,
    params: { method, path, body },
    context: { transport: 'rest' },
  });

  if (verdict.action === 'block') {
    throw new Error(`Request blocked by ShieldAgent: ${verdict.reason}`);
  }

  if (verdict.action === 'human_review') {
    return { status: 'pending_review', reviewId: verdict.reviewId };
  }

  return executeRequest(method, path, body);
}

Python

your_api_handler.py
from shieldagent import ShieldAgentClient

client = ShieldAgentClient(
    base_url="https://proxy.shieldagent.io",
    api_key="{your-api-key}",
)

async def handle_agent_request(agent_id: str, method: str, path: str, body: dict):
    verdict = await client.scan(
        tenant_id="{your-tenant-id}",
        agent_id=agent_id,
        tool_name=f"api:{method}:{path}",
        params={"method": method, "path": path, "body": body},
        context={"transport": "rest"},
    )

    if verdict.action == "block":
        raise HTTPException(status_code=403, detail=verdict.reason)

    if verdict.action == "human_review":
        return {"status": "pending_review", "review_id": verdict.review_id}

    return execute_request(method, path, body)
Verdict API

Posición 3 — Verdict API en tu propio servidor MCP

Si operas un servidor MCP al que se conectan los agentes, añade una llamada a client.scan() antes de cada manejador de herramienta. Cuando un agente solicita una herramienta, tu servidor envía el nombre de la herramienta y los argumentos a ShieldAgent para escanearlos. ShieldAgent devuelve un veredicto — tu código ejecuta la herramienta solo si está permitido. Esto te da visibilidad profunda y aplicación de políticas en el punto donde se definen las herramientas, manteniendo ShieldAgent centralizado.

Ideal cuando: construyes y mantienes el servidor MCP y quieres aplicación de seguridad en la capa de definición de herramientas. Tu servidor sigue en control — ShieldAgent escanea, tú aplicas. Contexto más rico para la evaluación de políticas que el posicionamiento proxy externo.

TypeScript

your-mcp-server.ts
import { ShieldAgentClient } from '@shieldagent/sdk';

const client = new ShieldAgentClient({
  baseUrl: 'https://proxy.shieldagent.io',
  apiKey: '{your-api-key}',
});

async function handleToolCall(toolName: string, params: unknown, clientName?: string) {
  const verdict = await client.scan({
    tenantId: '{your-tenant-id}',
    clientHint: clientName,
    toolName,
    params,
    context: { transport: 'mcp' },
  });

  if (verdict.action === 'block') {
    throw new Error(`Tool blocked by ShieldAgent: ${verdict.reason}`);
  }

  if (verdict.action === 'human_review') {
    return { status: 'pending_review', reviewId: verdict.reviewId };
  }

  return executeToolHandler(toolName, params);
}

Python

your_mcp_server.py
from shieldagent import ShieldAgentClient

client = ShieldAgentClient(
    base_url="https://proxy.shieldagent.io",
    api_key="{your-api-key}",
)

async def handle_tool_call(tool_name: str, params: dict, client_name: str | None = None):
    verdict = await client.scan(
        tenant_id="{your-tenant-id}",
        client_hint=client_name,
        tool_name=tool_name,
        params=params,
        context={"transport": "mcp"},
    )

    if verdict.action == "block":
        raise MCPError(f"Tool blocked by ShieldAgent: {verdict.reason}")

    if verdict.action == "human_review":
        return {"status": "pending_review", "review_id": verdict.review_id}

    return execute_tool(tool_name, params)
PosiciónQué debes poseerCambios en el código del agenteVe llamadas salientes a herramientasImpacto en la latenciaAplicación
1 — Proxy inlineNadaApuntar a la URL del proxy+5-15msInfraestructura
2 — Verdict API (REST)Tu servidor APIAñadir SDK scan()+5-15msCódigo del cliente
3 — Verdict API (MCP)Tu servidor MCPAñadir SDK scan()+5-15msCódigo del cliente

Las posiciones 1-3 cubren los principales patrones de integración para ShieldAgent SaaS.

Passthrough vs. Verdict API

Existen dos patrones de integración del SDK para clientes que poseen su propio servidor. Elige según si ShieldAgent necesita reenviar el tráfico a un upstream separado.

EscenarioPatrónCómo funciona
Tu servidor es un gateway hacia un upstream diferentePassthrough (apiProxy / mcpProxy)El SDK envía la solicitud al proxy de ShieldAgent. El proxy escanea, luego reenvía al upstream real y devuelve la respuesta.
Tu servidor ES el proveedor de herramientas (sin upstream separado)Verdict API (scan)El SDK envía el payload a ShieldAgent. ShieldAgent devuelve un veredicto (allow/block/human_review). Tu servidor ejecuta o rechaza localmente.

Modelo de aplicación

Todas las posiciones de despliegue ejecutan el mismo pipeline de seguridad multi-etapa — detección, evaluación de políticas, puntuación de riesgo y auditoría siempre son gestionadas por ShieldAgent. Lo que difiere es quién aplica el veredicto. La Posición 1 proporciona bloqueo garantizado por infraestructura: ShieldAgent se sitúa inline y detiene la solicitud antes de que llegue al upstream. Las Posiciones 2 y 3 usan la Verdict API: ShieldAgent detecta amenazas y devuelve un veredicto; el código de tu servidor lo aplica. Este modelo de responsabilidad compartida es estándar en la industria de seguridad — análogo al modo Count vs. Block de AWS WAF o al modo Detect vs. Prevent de CrowdStrike.

Comparación de aplicación

PosiciónAplicado porMecanismo de bloqueoGarantía
1 — Proxy inlineShieldAgentEl proxy descarta / rechaza la solicitudInfraestructura — no puede eludirse
2 — Verdict API (REST)Tu código de servidorTu manejador lanza o devuelve errorA nivel de código — depende de la implementación
3 — Verdict API (MCP)Tu código de servidorTu manejador de herramienta rechazaA nivel de código — depende de la implementación

Matriz de responsabilidades

ResponsabilidadPosición 1 (Proxy Inline)Posiciones 2 y 3 (Verdict API)
Detección de amenazasShieldAgentShieldAgent
Evaluación de políticasShieldAgentShieldAgent
Puntuación de riesgoShieldAgentShieldAgent
Registro de auditoríaShieldAgentShieldAgent
Documentación de cumplimiento (Anexo IV)ShieldAgentShieldAgent
Bloqueo de amenazasShieldAgent — garantía de infraestructuraCliente — a nivel de código, verificado vía confirmExecution()
Verificación de aplicaciónAutomática (el proxy bloquea antes de reenviar)Opcional — llama a confirmExecution() para cerrar el ciclo de auditoría

Impacto en los marcos de cumplimiento

MarcoPosición 1 (Proxy Inline)Posiciones 2 y 3 (Verdict API)
SOC 2 CC6.1 (Controles de acceso lógico)ShieldAgent es el control de acceso lógico completo.ShieldAgent proporciona detección + auditoría. Tu código de aplicación forma parte del control combinado evaluado por los auditores.
ISO 42001 A.6.2.6 (Supervisión del sistema de IA)Totalmente conforme.Totalmente conforme — la supervisión se proporciona independientemente de la topología de aplicación.
Ley de IA de la UE Art. 9 (Gestión de riesgos)ShieldAgent identifica, analiza, evalúa y mitiga amenazas.ShieldAgent identifica, analiza y evalúa. Tú mitiga aplicando los veredictos. Ambas partes deben documentarse en el Anexo IV.
Ley de IA de la UE Art. 14 (Supervisión humana)Revisión humana a través del panel de ShieldAgent.Revisión humana a través del panel + tu decisión explícita de aplicación tras recibir un veredicto human_review.
Ley de IA de la UE Anexo IV (Documentación técnica)Generada automáticamente con prueba de bloqueo garantizado por infraestructura.Generada automáticamente — debe incluir tu mecanismo de aplicación y las tasas de confirmExecution() como evidencia.

Pipeline de seguridad

Cada solicitud interceptada viaja por el mismo pipeline de seguridad ordenado independientemente de la posición de despliegue que uses. Las capacidades marcadas como siempre se ejecutan incondicionalmente; el resto se omiten en modo sombra o cuando no están configuradas.

1
Identity & Accesssiempre

Verifica las credenciales, identifica al inquilino y al agente, y determina si aplica el modo sombra.

2
Rate Limiting

Aplica límites de tasa configurables por inquilino y por agente para proteger los servicios upstream de la sobrecarga.

3
Policy Enforcement

Evalúa tus reglas de política configurables contra cada solicitud — permitir, denegar o escalar a revisión humana. El modo sombra registra sin bloquear.

4
Threat Detectionsiempre

Detecta inyección de prompts, exfiltración de datos, uso indebido de herramientas y otras amenazas mediante coincidencia de patrones y aprendizaje automático.

5
Risk Scoring

Asigna una puntuación de riesgo a cada agente basada en patrones de comportamiento. Bloquea o escala cuando el riesgo supera tus umbrales configurados.

6
Audit Loggingsiempre

Registra un evento de auditoría a prueba de manipulaciones para cada solicitud y veredicto, incluidas las solicitudes denegadas. Nunca bloquea la ruta de la solicitud.

Las capacidades se ejecutan en secuencia. Cualquier paso puede cortocircuitar el pipeline devolviendo una decisión de deny. El registro de auditoría siempre se ejecuta, incluso para las solicitudes denegadas.

Aislamiento de datos y multi-tenancy

La plataforma SaaS de ShieldAgent aplica un aislamiento lógico estricto entre todos los inquilinos. Toda la infraestructura está completamente gestionada — tú eliges dónde posicionar ShieldAgent en tu stack, no cómo operarlo.

SaaS

Aislamiento lógico multi-inquilino

Todos los inquilinos comparten un único proxy gestionado. El aislamiento se aplica en cada capa — claims JWT por solicitud, controles de acceso a nivel de fila y límites de tasa por inquilino. Tus datos nunca se mezclan con los de otro inquilino.

TopologíaAislamientoGestionado porAplicable a
Compartido (SaaS)LógicoShieldAgentTodos los planes

Capacidades de la plataforma

ShieldAgent proporciona una plataforma de seguridad completa para operaciones de agentes de IA. Todas las capacidades están completamente gestionadas — no hay infraestructura que configurar o desplegar.

CapacidadQué hace
Security ScanningEscanea cada llamada de herramienta y solicitud API en busca de amenazas, incluyendo inyección de prompts, exfiltración de datos y uso indebido de herramientas, antes de que lleguen a tus sistemas.
Policy EnforcementEvalúa reglas de política configurables contra cada solicitud. Las políticas pueden permitir, denegar o escalar a revisión humana. El modo sombra te permite observar sin bloquear.
Dashboard & MonitoringPanel de seguridad en tiempo real para monitorear la actividad de agentes, gestionar políticas, explorar registros de auditoría y registrar agentes.
Audit TrailRegistro de auditoría a prueba de manipulaciones de cada llamada de herramienta y veredicto. Exporta en cualquier momento a través del panel de control o un webhook configurado.
Risk ScoringPuntuación de riesgo continua por agente con detección de anomalías de comportamiento y umbrales de alerta configurables.
Compliance ReportingDocumentación de cumplimiento generada automáticamente para marcos SOC 2, ISO 42001 y Ley de IA de la UE, incluyendo evidencia del Anexo IV.

Transportes compatibles

El proxy admite transportes MCP tanto de red como basados en procesos. Elige según cómo se comunica tu framework de agentes con los servidores MCP.

TransporteProtocoloCaso de uso
HTTP/SSEHTTP streamingAgentes de red, despliegues con múltiples réplicas
stdioStandard I/OEl agente lanza el proxy como proceso hijo (desarrollo local, apps de escritorio)
REST API proxyHTTP methodsPass-through para APIs REST no MCP con aplicación de políticas

Cómo escala ShieldAgent

Escalado automático

ShieldAgent escala de forma transparente según tu volumen de tráfico. La capacidad del proxy, la afinidad de sesiones y el rendimiento de la base de datos se gestionan automáticamente — sin configuración requerida por tu parte.

Fiabilidad de conexiones SSE

Las conexiones Server-Sent Event son de larga duración y se gestionan con enrutamiento de reconexión automático. La afinidad de sesión es gestionada por la plataforma para que tus agentes se reconecten sin pérdida de datos.

Rendimiento de auditoría

El registro de auditoría está diseñado para alto rendimiento. Los eventos se escriben de forma asíncrona y nunca bloquean la ruta de la solicitud. Exporta en cualquier momento a través del panel de control o un webhook configurado.

Incluido en ShieldAgent SaaS

Toda la infraestructura es operada por ShieldAgent. Las siguientes capacidades están incluidas — nada que desplegar ni mantener de tu parte.

Incluido

Escaneo de seguridad · Aplicación de políticas · Panel y monitoreo · Registro de auditoría · Puntuación de riesgo · Informes de cumplimiento

Visión general de la arquitectura