Requisitos de Seguridad del Programa de Verificación Cibernética

Contacto de Seguridad. El Cliente debe proporcionar a Anthropic un contacto de seguridad designado que pueda recibir alertas de seguridad y abuso, y que sea capaz de actuar sobre ellas.

Reporte de Incidentes. El Cliente debe reportar a Anthropic cualquier sospecha de violación o abuso relacionado con la concesión dentro de 72 horas, o dentro de 24 horas para un incidente de seguridad. El reporte puede realizarse en [email protected] o a través del contacto de tu equipo de cuenta.

Cooperación. El Cliente debe investigar cualquier abuso que Anthropic identifique dentro de 48 horas, trabajar con Anthropic para remediarlo, y responder a consultas de abuso dentro de siete (7) días.

Acceso Personal. Cada Usuario Aprobado debe iniciar sesión como sí mismo. No se permiten inicios de sesión compartidos, asientos compartidos, sesiones compartidas, identidades de carga de trabajo compartidas, ni extensiones de navegador o herramientas proxy que expongan una sesión a otras personas que no sean explícitamente un Usuario Aprobado que cumpla con todos los requisitos a continuación.

Atribución de Uso. Los perfiles de usuario deben permanecer habilitados en el Espacio de Trabajo Otorgado para que las solicitudes puedan atribuirse a un usuario designado o identidad de carga de trabajo.

Notificación de Cambios. El Cliente debe notificar a Anthropic dentro de treinta (30) días de cualquier cambio material en su postura de seguridad, propiedad, sede o contacto de seguridad.

Revisión Continua. Anthropic puede solicitar que el Cliente proporcione evidencia de cumplimiento con estos Requisitos de Seguridad del Programa de Verificación Cibernética.

Autenticación Multifactor. En el momento del acceso del Cliente al CVP, todas las cuentas que puedan iniciar sesión en el Espacio de Trabajo Otorgado o que tengan credenciales para él deben tener autenticación multifactor habilitada. Antes del 15 de diciembre de 2026 (la "Fecha Límite"), todas esas cuentas deben usar autenticación multifactor resistente a phishing según se define en la hoja informativa de CISA "Implementing Phishing-Resistant MFA" y con NIST SP 800-63B-4, lo que significa (i) una clave de seguridad FIDO2/WebAuthn, (ii) una contraseña de acceso, en el dispositivo o en un gestor de contraseñas, o (iii) una tarjeta inteligente/PIV, y el inicio de sesión por enlace mágico de correo electrónico debe deshabilitarse. SMS, voz, códigos enviados por correo electrónico, códigos de aplicación autenticadora y aprobaciones push no califican.

Gestión de Credenciales. Antes de la Fecha Límite, no se deben usar credenciales estáticas descargadas, exportadas u otro tipo de credenciales de larga duración, incluidas claves API, para acceder al modelo. Los siguientes requisitos se aplican al Cliente según las plataformas de implementación a través de las cuales el Cliente accede al modelo. Para cada plataforma aplicable, todos los Usuarios Aprobados y todas las cargas de trabajo deben autenticarse usando credenciales de corta duración emitidas y administradas por el servicio de identidad nativo de esa plataforma.

Claves API Provisionales. Hasta la Fecha Límite, se permiten claves API bajo una concesión de Acceso de Defensa solo si cada clave es (i) almacenada en un gestor de secretos o gestor de contraseñas, (ii) asignada a una sola persona o carga de trabajo, (iii) mantenida fuera del código fuente, y (iv) reemplazada al menos cada 7 días. Anthropic puede limitar la vida útil de las claves API bajo una concesión de Acceso de Defensa a 7 días, y puede deshabilitar claves API en el Espacio de Trabajo Otorgado a partir de la Fecha Límite.

Usuarios Aprobados. No hay límite predeterminado en el número de Usuarios Aprobados en este Nivel de Acceso.

Los individuos son elegibles solo para Acceso de Defensa. Cuando la concesión es mantenida por un individuo, esta sección se aplica.

Gestión de Credenciales. Los siguientes requisitos se aplican al Cliente según las plataformas de implementación a través de las cuales el Cliente accede al modelo. Para cada plataforma aplicable, todos los Usuarios Aprobados y todas las cargas de trabajo deben autenticarse usando credenciales de corta duración emitidas y administradas por el servicio de identidad nativo de esa plataforma.

Autenticación Multifactor. En el momento del acceso del Cliente al CVP, la autenticación multifactor resistente a phishing debe proteger (i) todas las cuentas que puedan iniciar sesión en el Espacio de Trabajo Otorgado o que tengan credenciales para él, (ii) cuentas de Usuarios Aprobados en el proveedor de identidad del Cliente, (iii) identidades de AWS, Google Cloud o Azure que puedan llamar al modelo, (iv) acceso administrativo a cualquier cosa que emita o almacene credenciales del modelo, y (v) cualquier escritorio virtual o enclave usado para cumplir con estos requisitos. Autenticación multifactor resistente a phishing significa (i) una clave de seguridad FIDO2/WebAuthn, (ii) una contraseña de acceso, en el dispositivo o en un gestor de contraseñas, o (iii) una tarjeta inteligente/PIV, consistente con la hoja informativa de CISA "Implementing Phishing-Resistant MFA" y NIST SP 800-63B-4. SMS, voz, códigos enviados por correo electrónico, códigos de aplicación autenticadora y aprobaciones push no califican, y el inicio de sesión por enlace mágico de correo electrónico debe deshabilitarse.

Cuentas Organizacionales. Los Usuarios Aprobados deben iniciar sesión con cuentas en el dominio del Cliente. No se permiten cuentas personales ni de correo web.

Usuarios Aprobados. El Espacio de Trabajo Otorgado se limita a setenta y cinco (75) Usuarios Aprobados que personalmente realizan o supervisan directamente el trabajo para el cual fue aprobada la concesión. Las identidades de carga de trabajo no cuentan hacia ese número. El Cliente puede solicitar asientos adicionales de Usuarios Aprobados por escrito (siendo suficiente el correo electrónico). Solo los administradores designados pueden agregar miembros, cambiar roles, o crear identidades de carga de trabajo o credenciales en el Espacio de Trabajo Otorgado.

Puertas de Enlace. Si el Cliente opera una puerta de enlace o proxy frente al modelo, debe admitir solo Usuarios Aprobados o sus identidades de carga de trabajo, usar una credencial de corta duración propia, y mantener sus registros y transcripciones restringidos a Usuarios Aprobados y equipos de seguridad, administración de TI, o confianza y seguridad del Cliente.

Sistemas de Credenciales Operados por el Cliente. Las credenciales emitidas por los propios sistemas del Cliente deben expirar dentro de 12 horas, deben ser emitidas solo después de autenticación multifactor resistente a phishing (para personas) o una identidad de carga de trabajo verificada (para servicios), y no deben dejar credencial estática en puntos finales, código fuente, o almacenes compartidos. Las claves y secretos que pueden emitir credenciales del modelo deben mantenerse en un gestor de secretos o servicio de gestión de claves con registro de acceso.

Revocación. El Cliente debe ser capaz de revocar cualquier credencial o identidad comprometida dentro de 24 horas.

Desvinculación. El Cliente debe remover Usuarios Aprobados que se hayan ido o sido reasignados, y sus identidades de carga de trabajo, del Espacio de Trabajo Otorgado dentro de tres (3) días hábiles.

Salida de Red. Dondequiera que el modelo realice trabajo ofensivo o agéntico, el tráfico saliente debe limitarse a una lista de permitidos aplicada fuera del host, y debe ser registrado. Las estaciones de trabajo utilizadas solo para solicitudes interactivas pueden usar una lista de permitidos en el host si el trabajo agéntico en sí se ejecuta en una zona aislada que no puede cambiar esa lista.

Dispositivos Administrados. Los Usuarios Aprobados deben acceder al Espacio de Trabajo Otorgado solo desde dispositivos que el Cliente controla que reciben actualizaciones automáticas o regularmente programadas del sistema operativo, no desde dispositivos personales.

Verificaciones de Antecedentes. Cada Usuario Aprobado, incluidos contratistas, debe haber pasado una verificación de identidad y, donde sea legal, una verificación de antecedentes penales. Donde la ley local restringe verificaciones penales, se acepta verificación de identidad, derecho a trabajar, o verificación de empleo. La verificación gubernamental o una autorización satisface este requisito.

Procedimiento de Incidente. El Cliente debe mantener un procedimiento documentado para sospecha de compromiso o abuso de la concesión que cubra revocación de credenciales y suspensión de asiento.

Entidades Gubernamentales. Una Autorización FISMA para Operar con una evaluación anual independiente del Inspector General contra NIST SP 800-53, o un esquema nacional equivalente, satisface los requisitos de Dispositivos Administrados, Verificaciones de Antecedentes, y Procedimiento de Incidente. Todos los demás requisitos continúan aplicándose.

Autenticación Multifactor. En el momento del acceso del Cliente al CVP, la autenticación multifactor resistente a phishing debe proteger (i) todas las cuentas que puedan iniciar sesión en el Espacio de Trabajo Otorgado o que tengan credenciales para él, (ii) cuentas de Usuarios Aprobados en el proveedor de identidad del Cliente, (iii) identidades de AWS, Google Cloud o Azure que puedan llamar al modelo, (iv) acceso administrativo a cualquier cosa que emita o almacene credenciales del modelo, y (v) cualquier escritorio virtual o enclave usado para cumplir con estos requisitos. Autenticación multifactor resistente a phishing significa (i) una clave de seguridad FIDO2/WebAuthn, (ii) una contraseña de acceso, en el dispositivo o en un gestor de contraseñas, o (iii) una tarjeta inteligente/PIV, consistente con la hoja informativa de CISA "Implementing Phishing-Resistant MFA" y NIST SP 800-63B-4. SMS, voz, códigos enviados por correo electrónico, códigos de aplicación autenticadora y aprobaciones push no califican, y el inicio de sesión por enlace mágico de correo electrónico debe deshabilitarse.

Gestión de Credenciales. Los siguientes requisitos se aplican al Cliente según las plataformas de implementación a través de las cuales el Cliente accede al modelo. Para cada plataforma aplicable, todos los Usuarios Aprobados y todas las cargas de trabajo deben autenticarse usando credenciales de corta duración emitidas y administradas por el servicio de identidad nativo de esa plataforma.

Inicio de Sesión Único y Cuentas Organizacionales. Los Usuarios Aprobados deben iniciar sesión con cuentas en el propio dominio del Cliente. Los Usuarios Aprobados deben iniciar sesión con identidades de dominio organizacional federadas a través del inicio de sesión único del Cliente. No se permiten cuentas personales, de correo web, ni no federadas.

Usuarios Aprobados. El Espacio de Trabajo Otorgado se limita a 25 Usuarios Aprobados que personalmente realizan o supervisan directamente el trabajo para el cual fue aprobada la concesión. Las identidades de carga de trabajo no cuentan hacia ese número. El Cliente puede solicitar asientos adicionales de Usuarios Aprobados por escrito (siendo suficiente el correo electrónico). Solo los administradores designados pueden agregar miembros, cambiar roles, o crear identidades de carga de trabajo o credenciales en el Espacio de Trabajo Otorgado.

Puertas de Enlace. Si el Cliente opera una puerta de enlace o proxy frente al modelo, debe admitir solo Usuarios Aprobados o sus identidades de carga de trabajo, usar una credencial de corta duración propia, y mantener sus registros y transcripciones restringidos a Usuarios Aprobados y equipos de seguridad, administración de TI, o confianza y seguridad del Cliente.

Sistemas de Credenciales Operados por el Cliente. Las credenciales emitidas por los propios sistemas del Cliente deben expirar dentro de 12 horas, deben ser emitidas solo después de autenticación multifactor resistente a phishing (para personas) o una identidad de carga de trabajo verificada (para servicios), y no deben dejar credencial estática en puntos finales, código fuente, o almacenes compartidos. Las claves y secretos que pueden emitir credenciales del modelo deben mantenerse en un gestor de secretos o servicio de gestión de claves con registro de acceso.

Revocación. El Cliente debe ser capaz de revocar cualquier credencial o identidad comprometida dentro de 24 horas.

Desvinculación. El Cliente debe remover Usuarios Aprobados que se hayan ido o sido reasignados, y sus identidades de carga de trabajo, del Espacio de Trabajo Otorgado dentro de 3 días hábiles.

Salida de Red. Dondequiera que el modelo realice trabajo ofensivo o agéntico, el tráfico saliente debe limitarse a una lista de permitidos aplicada fuera del host, y debe ser registrado. Las estaciones de trabajo utilizadas solo para solicitudes interactivas pueden usar una lista de permitidos en el host si el trabajo agéntico en sí se ejecuta en una zona aislada que no puede cambiar esa lista.

Dispositivos Administrados y Protección contra Malware. Los Usuarios Aprobados deben acceder al Espacio de Trabajo Otorgado solo desde dispositivos que el Cliente controla, no desde dispositivos personales, y que reciben actualizaciones automáticas o regularmente programadas del sistema operativo. Cada dispositivo que un Usuario Aprobado usa para acceder al Espacio de Trabajo Otorgado debe ser administrado por el Cliente y debe ejecutar lista de permitidos o denegados de aplicaciones en modo de aplicación, o un agente de detección y respuesta de puntos finales en modo de bloqueo o prevención. Un escritorio virtual administrado o enclave que cumpla con este estándar también califica.

Verificaciones de Antecedentes. Cada Usuario Aprobado, incluidos contratistas, debe haber pasado una verificación de identidad y, donde sea legal, una verificación de antecedentes penales. Donde la ley local restringe verificaciones penales, se acepta verificación de identidad, derecho a trabajar, o verificación de empleo. La verificación gubernamental o una autorización satisface este requisito.

Procedimiento de Incidente. El Cliente debe mantener un procedimiento documentado para sospecha de compromiso o abuso de la concesión que cubra revocación de credenciales, suspensión de asiento, y notificación a Anthropic.

Entidades Gubernamentales. Una Autorización FISMA para Operar con una evaluación anual independiente del Inspector General contra NIST SP 800-53, o un esquema nacional equivalente, satisface los requisitos de Dispositivos Administrados y Protección contra Malware, Verificaciones de Antecedentes, y Procedimiento de Incidente. Todos los demás requisitos continúan aplicándose.