Modelo de seguridad

Preparado para agentes no significa sin control. Un sistema MCP-first describe cada capacidad de forma legible por máquina, y al mismo tiempo establece quién puede invocarla, bajo qué condiciones y qué rastros deja. La seguridad no es un añadido posterior, sino parte del diseño de capacidades.

Seis niveles de autorización

La autenticación responde: ¿Quién eres? La autorización responde: ¿Qué puedes hacer? Un sistema MCP-first necesita ambas preguntas, y las responde en seis niveles independientes entre sí, que juntos determinan el acceso efectivo.

Nivel 1: User Role

El rol del usuario autenticado constituye el nivel más amplio. Determina clases de acceso fundamentales, no herramientas individuales.

admin
manager
employee
viewer
external_client

Nivel 2: Tenant Scope

En sistemas multi-tenant, cada acceso debe estar vinculado al tenant. Ningún agente puede leer o escribir entre tenants, aunque su rol de usuario lo permitiera técnicamente.

tenant:abc
project:123
contact:456

Nivel 3: Tool Scope

Cada herramienta está protegida con sus propios scopes. Un agente recibe exclusivamente los scopes necesarios para su tarea definida.

contacts:read
contacts:write
projects:read
projects:write
files:read
files:write
emails:draft
emails:send
calendar:create
billing:read
billing:write
admin:users
admin:security

Nivel 4: Resource Scope

Más allá de los scopes de herramienta, el acceso puede restringirse a tipos de recursos individuales. Esto garantiza que un agente con contacts:read no pueda consultar todos los recursos de contacto.

resource.project.visible
resource.contact.visible
resource.employee.visible
resource.file.downloadable
resource.email.readable

Nivel 5: Risk Level

Cada herramienta lleva un nivel de riesgo declarado. Este nivel influye en la política de confirmación y en la configuración de auditoría.

Nivel 6: Confirmation Policy

La Confirmation Policy establece qué barrera adicional debe superarse antes de la ejecución. Se configura por herramienta y es impuesta por la capa de políticas, no por el agente mismo.

no_confirmation_required
confirmation_required
step_up_auth_required
admin_approval_required
four_eyes_required
not_allowed_for_ai

Visibilidad de herramientas

Si una herramienta existe ya es información de relevancia para la seguridad. Un agente que conoce una herramienta prohibida puede utilizarla como superficie de ataque, aunque la invocación posterior sea bloqueada.

Un Sales Assistant recibe, por ejemplo, la siguiente lista filtrada de herramientas:

Human-in-the-loop

MCP-first no significa totalmente automático. Significa completamente controlable, pero de forma controlada. Para acciones sensibles o de riesgo, el sistema interrumpe al agente y obtiene activamente el consentimiento del usuario.

El agente reconoce, a partir de los metadatos de riesgo declarados, que una acción requiere aprobación humana y cede el control. Solo tras una confirmación explícita se ejecuta la herramienta.

El siguiente ejemplo muestra un diálogo de aprobación típico para el envío masivo de correos externos, una de las acciones de agente críticas más frecuentes:

Step-up Authentication

Para acciones especialmente sensibles, una sesión activa no es suficiente. Incluso un administrador autenticado debe confirmar su identidad de nuevo antes de ejecutar operaciones críticas.

Desencadenantes típicos de Step-up Auth:

• Cambiar o asignar permisos de administrador
• Cambiar datos de pago o suscripción
• Datos salariales o exportaciones de nómina
• Generar o rotar claves API
• Exportaciones completas de datos
• Eliminar usuarios o tenants

Métodos aceptados de Step-up (según la política del sistema):

Solicitud de contraseña de nuevo
TOTP / App de autenticación
Passkey
Aprobación de administrador por segunda persona
Principio de cuatro ojos

Consent Ledger

Cada aprobación de una acción de agente es un evento que debe almacenarse de forma permanente. El Consent Ledger permite rastrear a posteriori qué acción fue aprobada por quién, para qué alcance y con qué método de seguridad.

Campos almacenados de una entrada de consentimiento:

consentId, ID única del consentimiento
userId, usuario que aprueba
agentId, agente que actúa
clientId, cliente MCP conectado
toolName, herramienta invocada
inputSummary, resumen estructurado de las entradas (sin texto plano)
riskLevel, nivel de riesgo declarado de la herramienta
approvedAt, marca de tiempo de la aprobación
expiresAt, validez de la aprobación (si está limitada en el tiempo)
approvalMethod, método de aprobación utilizado (p. ej. "totp", "passkey", "manual")

Algunas aprobaciones pueden tener validez limitada en el tiempo, por ejemplo, una aprobación puntual para un envío concreto. Otras son válidas para una sesión o un período configurado. La política determina la granularidad.

Audit Trail

Cada acción MCP genera una entrada de auditoría. Esta entrada es inmutable, vinculada al tenant y procesable por máquina. Constituye la base para las pruebas de cumplimiento, la detección de anomalías y las revisiones internas.

{
  "event": "mcp.tool.executed",
  "tool": "emails.send_external",
  "tenantId": "tenant_123",
  "userId": "user_456",
  "agentId": "agent_sales_assistant",
  "clientId": "client_claude_desktop",
  "riskLevel": "critical",
  "confirmationId": "confirm_789",
  "inputHash": "sha256:a3f2c1...",
  "result": "success",
  "createdAt": "2026-06-11T10:00:00Z"
}

El log de auditoría puede monitorizarse automáticamente para detectar anomalías: frecuencias de ejecución inusuales, acciones fuera del horario habitual o accesos a scopes que un agente normalmente no usa, todo ello es detectable porque cada acción está tipada y auditada de forma limpia.