Saltar al contenido principal
Una clave apareció en un commit público, un log de CI, una captura de pantalla o una brecha de proveedor. El reloj corre: cualquiera que tenga esa cadena sk-orca-… puede gastar tu saldo y conducir tus agentes hasta que la cortes. Esta página es el runbook de incidente — corta la credencial primero, luego audita qué hizo — para clientes que gestionan sus propias claves en la consola. La mecánica del ciclo de vida (deshabilitar vs. eliminar, estados de clave, roles) vive en Gestionar claves; esta página es la secuencia bajo ataque y, críticamente, qué revisar en el rastro de auditoría una vez que el sangrado se ha detenido.
Detén el gasto antes de investigar. Una clave con alcance, con un tope credit_limit_usd y una lista allow_ips, acota el daño, pero una clave filtrada sin topes puede quemar saldo mientras siga en vivo. Revoca primero; forense después.

​
1. Revoca la clave API filtrada (haz esto primero)

Tienes dos movimientos de corte, ambos en la pantalla Keys de la consola (/console/token). Ambos requieren el rol Developer o superior — la acción se ejecuta sobre tu token de sesión / acceso, nunca sobre una clave de relay.

Deshabilitar — pausa reversible

Invierte el estado de la clave a Disabled. Cada solicitud que hace es rechazada de inmediato, pero la clave, sus límites, sus adjuntos de política y su historial de uso quedan todos intactos. Usa esto cuando necesites la configuración y los logs preservados mientras investigas.

Eliminar — revocación permanente

Elige Delete en la clave. La credencial nunca puede volver a autorizar una solicitud y no es recuperable. Usa esto una vez que la filtración esté confirmada y hayas capturado lo que necesitas del rastro.
Un patrón común: deshabilita al instante en el momento en que sospechas exposición (contención de latencia cero, nada perdido), ejecuta la auditoría en §3–§4, luego elimina una vez que has acotado el radio de explosión. Hagas lo que hagas, emite una clave nueva para el reemplazo — nunca vuelvas a habilitar una credencial que ha sido vista en el mundo. El traspaso sin tiempo de inactividad está en Rotación de claves.
Deshabilitar o eliminar surte efecto en la siguiente solicitud — no hay redespliegue ni retraso de propagación.

​
2. Ya que estás, endurece el reemplazo

Una filtración es el momento de arreglar el alcance que la dejó hacer daño. La clave de reemplazo debería llevar la identidad más estrecha que la carga de trabajo realmente necesita, para que la próxima filtración sea un no-evento:
Una lista de permitidos de IP significa que una clave filtrada es inútil desde cualquier dirección excepto la tuya. Las solicitudes de IPs no listadas se rechazan en la capa de auth antes de que cuesten nada.
Un tope de gasto (0 = ilimitado) acota el peor caso. Una clave filtrada con un techo semanal estricto no puede drenar el saldo de tu espacio de trabajo.
Los límites de modelo impiden que un ladrón cambie tu clave barata a tu modelo más caro.
Una expiración (-1 = nunca) significa que una clave que escapa a tu atención aún deja de autorizar por sí sola.
Ver el Checklist de mínima agencia para la postura completa de una-clave-por-agente.

​
3. Audita los logs de solicitudes — ¿qué llamó la clave?

Con la credencial cortada, acota el daño. Cada llamada de relay que esa clave hizo está registrada en los logs de solicitudes de tu espacio de trabajo, y cada fila lleva los campos que necesitas para reconstruir el incidente:
CampoQué te dice
token_name / token_idCuál clave — confirma que estás mirando la filtrada.
ipLa dirección de origen de cada llamada. Una ráfaga desde una IP que no reconoces es la pistola humeante.
modelo + usoQué modelos se golpearon y cuánto costaron — tu exposición de gasto.
Filtra la vista de logs a la clave filtrada y ordena por tiempo. Dos preguntas responden el “qué tan malo es” lo más rápido:
  1. ¿Hay tráfico desde una IP que no es tuya? Eso es mal uso confirmado, no una falsa alarma.
  2. ¿El gasto o el patrón de llamadas tuvo un pico alrededor de la ventana de la filtración? Un salto repentino es la huella del atacante.
Si la clave llevaba una lista allow_ips, las llamadas desde fuera de ella nunca autorizaron en primer lugar — así que la ausencia de filas de IP extranjera es en sí misma un certificado de salud limpio. Esto es exactamente por qué fijar el origen (§2) convierte una filtración en un no-evento.

​
4. Lee el rastro de política — ¿qué intentó hacer?

Los logs de solicitudes te dicen qué llamó la clave; los planos de política te dicen qué intentó hacer que el modelo dijera o hiciera, y si tus guardrails y firewall lo atraparon. Ambos tienen alcance de espacio de trabajo. Las coincidencias de guardrail son legibles por cualquier miembro del espacio de trabajo; la vista de Events / Runs del firewall requiere el rol Developer o superior (las políticas y configuraciones del firewall permanecen abiertas a cada miembro).

Coincidencias de guardrail

Cada vez que el tráfico de la clave golpeó una regla de guardrail, un registro de coincidencia aterrizó en GET /api/guardrail/match — llevando el tipo de regla, action (block / mask / flag), stage, y el detalle infractor. Filtra a la ventana de la clave filtrada para ver qué contenido empujó a través (PII, secretos, intentos de jailbreak).

Eventos de firewall

Cada llamada a herramienta que la clave emitió es un evento de firewall — allow, audit, deny, sanitize, o retenida. Una racha de eventos deny es un agente que intentó algo que no le estaba permitido. Agrúpalos por ejecución en la vista Events / Runs.
Algunos detalles que vale la pena saber mientras lees el rastro:
  • Las coincidencias de guardrail registran la subcadena coincidente solo si “Log raw content” estaba activado para ese guardrail (está apagado por defecto) — así que una fila de coincidencia puede mostrar la regla y la acción sin el texto en bruto. El tipo / acción / etapa siempre están ahí.
  • mark-fp en una coincidencia (POST /api/guardrail/match/:id/mark-fp, Admin) te permite marcar un acierto como falso positivo para que deje de sesgar tu vista del incidente — no lo uses para enterrar mal uso real.
  • Los denies de firewall son pre-herramienta. Un evento deny significa que la llamada a herramienta del atacante se bloqueó antes de alcanzar la herramienta — el firewall ya contuvo esa acción. El evento es tu evidencia de que lo intentó.
Cruza los tres rastros en la misma ventana de tiempo: una IP extranjera en los logs de solicitudes, un pico de coincidencias de guardrail y un grupo de eventos deny de firewall juntos pintan el cuadro completo — qué tenía el atacante, qué intentó, y qué se detuvo.

​
5. Después del incidente

Revisa de nuevo la lista Keys: la clave filtrada debería leer Disabled o haber desaparecido por completo. Si solo la deshabilitaste, programa la eliminación una vez que hayas terminado la auditoría — ver Gestionar claves.
Mueve el tráfico a la clave nueva, con alcance más estrecho, antes de retirar la vieja para que nunca haya un hueco sin-clave-funcional. Traspaso completo: Rotación de claves.
Si la clave filtrada no tenía allow_ips, ni credit_limit_usd, y model_limits amplios, ese es el verdadero hallazgo. Dale a cada agente su propia clave con alcance estrecho — el Checklist de mínima agencia y Alcance y claves recorren toda la postura.

​
6. Relacionado

Gestionar claves

Deshabilitar vs. eliminar, estados de clave, y las puertas de rol detrás de cada acción.

Rotación de claves

El traspaso sin tiempo de inactividad de una clave comprometida a una limpia.

Lista de permitidos de IP

Fija una clave a tus direcciones de origen para que una filtración no pueda usarse en otro lugar.

Exfiltración de datos

La amenaza que una clave filtrada alimenta con más frecuencia, y cómo la superficie de egress del firewall la acota.
Toda la secuencia es corta a propósito: revoca, luego audita. Cuanto más estrecho sea el alcance de cada clave para empezar, menor será la auditoría que tengas que ejecutar — y más rápido una credencial filtrada pasa de emergencia a nota al pie.