Enviar eventos de Security posture a tu SIEM

Esta página te lleva desde una Compliance Access Key hasta las actividades de Security posture que llegan como eventos a tu sistema “security information and event management” (gestión de información y eventos de seguridad), o SIEM, de forma programada. La descripción general indica qué organizaciones tienen estas actividades. Necesitas una Compliance Access Key que cubra la organización, con el alcance read:compliance_activities o read:org_audit.

Solicitar las actividades

Para leer solo estas actividades, filtra el feed con activity_types[]. En esta solicitud, created_at.gte establece el created_at más antiguo que se leerá, y order=asc devuelve primero las actividades más antiguas:

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  -H "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  -H "anthropic-version: 2026-10-21" \
  --data-urlencode "activity_types[]=org_security_control_attestation_updated" \
  --data-urlencode "created_at.gte=2026-10-20T00:00:00Z" \
  --data-urlencode "order=asc" \
  --data-urlencode "limit=5000"

La referencia de la APIVista previa disponible con enlaces a la referencia de la API — presiona Tab hasta que el foco entre a la tarjeta y Escape para volver. describe cada parámetro.

Leer una actividad

Cada elemento del arreglo data de la respuesta es una actividad como esta.

{
  "id": "activity_01Hq7ZtYc4Vb2NmKx8RsPd3W",
  "type": "org_security_control_attestation_updated",
  "created_at": "2026-10-20T15:04:00.220114Z",
  "organization_id": "org_01JuY4bkwkH1x4PodBJaWmh2",
  "organization_uuid": "91012d09-e48b-438e-a489-1bebfd8fa6f9",
  "actor": {
    "type": "user_actor",
    "email_address": "jane.doe@example.com",
    "user_id": "user_01WxYzAbCdEfGhJkMnPqRsTu",
    "ip_address": "192.0.2.34",
    "user_agent": "Mozilla/5.0..."
  },
  "control": "directory_sync_enabled",
  "action": "attested",
  "status": "accepted_risk"
}

• control nombra el control de seguridad, una configuración o práctica recomendada.
• action indica qué le ocurrió a la atestación del control, la declaración registrada de una persona sobre el control. Aquí attested significa que se registró una atestación para un control que no tenía ninguna.
• status es el valor de la atestación. Aquí es Riesgo aceptado (accepted_risk): el control no está implementado y la organización acepta el riesgo.
• Aquí, actor identifica a la persona que atestó, por ID de usuario y dirección de correo electrónico.
• Aquí, created_at es el momento en que esa persona atestó.

La Referencia de eventos de Security posture enumera más campos y valores.

Si la respuesta está vacía

Un arreglo data vacío es válido. El Activity Feed contiene solo los cambios realizados desde que comenzó a registrar estas actividades para la organización. Está vacío hasta que se realiza o se cambia una atestación.

Comprueba que la organización tenga estas actividades. Luego pide a alguien que ateste un control. Después de un tiempo, repite la solicitud.

Ejecutarlo de forma programada

Cualquiera de estas actividades puede volverse consultable más tarde que el retraso de indexación habitual de 1 minuto del Activity Feed, con un created_at que ya está en el pasado. Por eso, una integración que solo avanza, desde un cursor o un created_at.gte que avanza, nunca ve una actividad así. Vuelve a leer una ventana retrospectiva fija de 4 horas en cada ejecución y descarta las actividades que ya almacenaste:

query = activity_types[]=org_security_control_attestation_updated
      & created_at.gte={now - 4 hours}
      & order=asc
      & limit=5000
cursor = null
loop:
  if cursor is null:
    page = GET /v1/compliance/activities?{query}
  else:
    page = GET /v1/compliance/activities?{query}&after_id={cursor}
  for activity in page.data:
    if activity.id is not in stored_ids:
      store(activity)
      add activity.id to stored_ids
  if not page.has_more: break
  cursor = page.last_id

• Ejecuta con frecuencia: Ejecuta el ciclo con la frecuencia que necesiten tus alertas, por ejemplo cada 5 minutos.
• Usa la misma consulta durante toda la ejecución: Calcula created_at.gte, en UTC y codificado para URL, al inicio de cada ejecución. Envía los mismos filtros y el mismo order en cada página. Con order=asc, pasar last_id como after_id devuelve la siguiente página de actividades posteriores. Paginar resultados explica after_id y last_id.
• Elimina los duplicados por id: Este paso es obligatorio, porque las ejecuciones consecutivas se superponen.
• Maneja las ejecuciones fallidas: Si una solicitud falla después de los reintentos descritos en Manejar errores de la Compliance API, termina la ejecución. La siguiente ejecución vuelve a leer toda su ventana. Si las ejecuciones fallan o se detienen durante más de 4 horas, la siguiente relectura diaria lee las actividades que esas ejecuciones perdieron.

Volver a leer 15 días una vez al día

Una vez al día, ejecuta el mismo ciclo con una ventana retrospectiva de 15 días en lugar de 4 horas. Esta relectura diaria también lee una actividad que se vuelve consultable hasta 14 días después de su created_at.

• Registra la hora de inicio de cada relectura diaria que se complete.
• Quita un id almacenado solo si lo almacenaste más de 16 días antes del último inicio registrado.
• Si no hay ningún inicio registrado, establece created_at.gte tan atrás como necesites; el Activity Feed conserva las actividades durante 6 años.
• Si ha pasado más de un día desde el último inicio registrado, ejecuta la siguiente relectura diaria con created_at.gte establecido en 15 días antes de ese inicio.

Si ya ingieres el Activity Feed completo

Una integración que lee todo el Activity Feed, sin un filtro activity_types[] que excluya estas actividades, ya las recibe. Comprueba dos cosas:

• Valores no reconocidos: Tu controlador transmite sin cambios cualquier type o valor de campo que no reconozca. Consulta Comprender el objeto Activity.
• Actividades tardías: Una integración que solo solicita actividades posteriores pierde una actividad que se vuelve consultable tarde. Agrega a la integración la relectura de 4 horas y la relectura diaria de 15 días.

Comprobar que funciona

Después de que alguien realice una atestación sobre un control, ejecuta el ciclo hasta que almacene la nueva actividad. A continuación, vuelve a ejecutarlo: no almacena esa actividad una segunda vez.

Próximos pasos

Para generar alertas según el momento en que almacenaste una actividad, no según su created_at, consulta Detectar cambios en Security posture. Para el “Open Cybersecurity Schema Framework” (marco abierto de esquemas de ciberseguridad), u OCSF, consulta Mapear eventos de Security posture a OCSF. Para los resultados actuales, consulta Referencia de resultados de Security posture.