Saltar al contenido principal
Cuando un agente corre suelto a través de una docena de herramientas MCP, la pregunta que importa después del hecho nunca es “¿es segura esta herramienta?” — es “¿qué llamó realmente el agente, qué decidió el firewall y qué regla hizo esa llamada?”. OrcaRouter responde eso desde un lugar: el mcp audit log. Cada tools/call que el gateway MCP evalúa en la superficie mcp aterriza como un evento de firewall — veredicto, herramienta, regla coincidente y el run del agente que lo emitió — así puedes monitorear una sesión en vivo o reconstruirla después. Esta página es el how-to enfocado para leer ese rastro. Para el gateway en sí, el vocabulario de veredictos y el DSL de reglas, ver Firewall y Firewall: servidores MCP.
Cada lectura aquí se configura desde la consola (o la API REST con tu token de sesión/acceso — UserAuth) y está restringida por rol. Solo las llamadas de relay /v1/* y las rutas del gateway del firewall llevan una clave de estilo sk-orca-....

​
1. Qué registra el mcp audit log

Cada llamada a herramienta MCP produce un evento de firewall en la superficie mcp. El evento lleva lo que necesitas para responder “quién llamó a qué, y qué hizo la política” — y nada que no debería (los argumentos de herramienta se redactan, ver §4).
verdict (allow / audit / deny / sanitize / pending_approval / observe), surface (mcp aquí), policy_name, rule_label, y un reason legible por humanos. Un flag quarantine marca una llamada retenida porque la skill propietaria está en modo cuarentena.
tool_name (con espacio de nombres <server>.<tool>), skill_name cuando la llamada es atribuible a una skill registrada, model_name y token_name.
agent_run_id, conversation_id y request_id — las claves que usas para agrupar las llamadas de una sesión o profundizar de una solicitud a cada llamada que abanicó.
Un flag gap marca una llamada en modo observe que tu política adjunta vio pero no coincidió con ninguna regla — la señal que la vista de Herramientas Descubiertas usa para aflorar herramientas que tu política aún no cubre.

​
2. Leer el feed

La pestaña Events en la consola es la vista primaria. Para extraer los mismos datos programáticamente, lista los eventos con tu token de acceso y filtra a la superficie mcp: 
# Ruta de consola (UserAuth). Leer eventos requiere Developer+.
curl "https://api.orcarouter.ai/api/workspace/firewall/events?surface=mcp&verdict=deny,pending_approval" \
  -H "Authorization: Bearer <your-access-token>"
El filtro verdict acepta un solo valor o un conjunto separado por comas (el preset de “denies + retenciones” de arriba). Un evento de muestra: 
{
  "created_at": 1700000000,
  "surface": "mcp",
  "tool_name": "github.create_issue",
  "verdict": "deny",
  "policy_name": "Coding agent",
  "rule_label": "no writes to prod org",
  "reason": "rule matched: no writes to prod org",
  "agent_run_id": "run_8f3a",
  "model_name": "claude-sonnet-4-5",
  "token_name": "ci-agent"
}
Para reconstruir el abanico completo de una solicitud — cada herramienta que el modelo llamó bajo una sola solicitud de relay — profundiza por id de solicitud: 
curl "https://api.orcarouter.ai/api/workspace/firewall/events/by-request/<request_id>" \
  -H "Authorization: Bearer <your-access-token>"
Para un resumen a nivel de sesión en vez de filas crudas, golpea GET /api/workspace/firewall/events/aggregate?group_by=run (o group_by=session) — una fila por run de agente con un desglose por veredicto, herramientas distintas y first/last-seen. Los endpoints de traza (/trace/runs, /trace/by-run) reconstruyen el árbol de llamadas del run.

​
3. Filas de auditoría de gobernanza de servidor

Los eventos por llamada te dicen qué hizo el agente. Un segundo rastro, más pequeño, te dice qué hiciste tú a la gobernanza de un servidor — y es donde vive la historia del rug-pull. Cuando un sondeo encuentra que el conjunto de herramientas anunciado de un servidor registrado ha derivado, y un admin lo re-toma como línea base o lo pone en cuarentena, esa decisión se escribe en el log de auditoría del espacio de trabajo:
Acción de auditoríaEscrita cuando
firewall_mcp_schema_changedUn sondeo encuentra que el conjunto de herramientas en vivo derivó del aprobado.
firewall_mcp_schema_approvedUn admin re-toma como línea base el nuevo conjunto de herramientas.
firewall_mcp_schema_quarantinedUn admin pone en cuarentena (y deshabilita) un servidor derivado.
Cada fila lleva el id del servidor, el nombre y el conteo de herramientas — nunca argumentos de herramienta ni credenciales. Este es el rastro forense detrás de la Defensa contra rug-pull: un servidor que aprobaste el lunes no puede crecer silenciosamente una herramienta shell.exec el viernes sin dejar una fila aquí.
Los cambios de política, regla y configuraciones del firewall escriben sus propias filas de auditoría junto a estas. Cuando un admin de plataforma hace el cambio, también aterriza en el log de auditoría central de admin (GET /api/admin/audit-logs, solo admin); la edición de un miembro regular se queda en el rastro del espacio de trabajo.

​
4. Los argumentos se redactan por defecto

El flujo de eventos está construido para ser legible por tu equipo sin filtrar secretos. Los argumentos de llamada a herramienta nunca se almacenan textualmente — un evento lleva como mucho un args_summary acotado y redactado, y el hash de argumento en bruto usado para la agrupación de anomalías nunca deja el servidor.
Como los eventos llevan esa instantánea de argumentos saneada, los endpoints de eventos, agregado y traza están restringidos a Developer+ — un miembro de rol Viewer puede leer políticas y herramientas descubiertas pero no la procedencia de llamadas a herramienta de otro miembro. Planifica tus roles en consecuencia.

​
5. Monitoreo en vivo: anomalías

Leer después del hecho es una mitad; la otra es que te avisen mientras está pasando. El feed de anomalías vigila MCP (y cada otra superficie) en busca de comportamiento que rompe con la línea base aprendida del espacio de trabajo — picos de tasa y coste contra un perfil de hora de la semana, bucles de reintento y rutas de herramienta novedosas — y los aflora sin que escribas una sola regla. 
# El feed de anomalías está abierto a cualquier Member.
curl "https://api.orcarouter.ai/api/workspace/firewall/anomalies?window=5m" \
  -H "Authorization: Bearer <your-access-token>"
Una señal ruidosa puede posponerse (hasta 7 días) para que deje de amontonar el feed sin silenciarse permanentemente. La lectura de anomalías está abierta a Member — más amplia que el flujo de eventos — porque lleva la señal, no los argumentos.
Empareja el feed con el modo sombra: rueda una política apretada como solo-auditoría, vigila los denies en potencia en el flujo de eventos (reason prefijado [shadow] would …), y promuévela una vez que el feed esté tranquilo.

​
6. Retención y borrado

Los eventos del firewall expiran automáticamente — no son un almacén permanente, son una ventana de monitoreo rodante. Las filas de auditoría de espacio de trabajo (el rastro de gobernanza de servidor en §3) se mantienen hasta 180 días. Y cuando se elimina un usuario, el ciclo de gracia-luego-depuración cascadea a través de los eventos y coincidencias del firewall así que el rastro de llamadas a herramienta de un usuario que se fue no se demora.
Los controles de residencia de datos y retención viven en el plano de cumplimiento. El mcp audit log hereda la postura de retención del espacio de trabajo; no lo configuras por servidor.

​
7. Dónde ir a continuación

Resumen de seguridad de MCP

Toda la superficie de gobernanza de MCP — gateway, veredictos, skills, egress.

Defensa contra rug-pull

Los eventos de deriva en §3, de extremo a extremo: detectar, re-tomar como línea base, poner en cuarentena.

Lista de permitidos de herramientas MCP

Convierte lo que muestra el audit log en una política de denegación por defecto.

Firewall: servidores MCP

La referencia completa de campos y rutas.
¿Nuevo en el modelo? Ver Cómo inspecciona OrcaRouter para dónde se emiten los eventos en el camino de evaluación, y Agencia excesiva para la amenaza que un rastro de auditoría limpio te ayuda a atrapar temprano.