Requisitos de Segurança do Programa de Verificação Cibernética

Contato de Segurança. O Cliente deve fornecer à Anthropic um contato de segurança nomeado que possa receber alertas de segurança e abuso e seja capaz de agir sobre eles.

Relatório de Incidentes. O Cliente deve relatar suspeitas de violações ou abuso envolvendo a concessão à Anthropic dentro de 72 horas, ou dentro de 24 horas para um incidente de segurança. O relatório pode ser feito em [email protected] ou através do contato da sua equipe de contas.

Cooperação. O Cliente deve investigar qualquer abuso identificado pela Anthropic dentro de 48 horas, trabalhar com a Anthropic para remediá-lo e responder a consultas de abuso dentro de sete (7) dias.

Acesso Pessoal. Cada Usuário Aprovado deve fazer login como ele mesmo. Logins compartilhados, assentos, sessões e identidades de carga de trabalho, e extensões de navegador ou ferramentas de proxy que expõem uma sessão a outras pessoas que não são explicitamente um Usuário Aprovado atendendo a todos os requisitos abaixo não são permitidos.

Atribuição de Uso. Os perfis de usuário devem permanecer habilitados no Espaço de Trabalho Concedido para que as solicitações possam ser atribuídas a um usuário nomeado ou identidade de carga de trabalho.

Notificação de Alterações. O Cliente deve notificar a Anthropic dentro de trinta (30) dias de uma alteração material em sua postura de segurança, propriedade, sede ou contato de segurança.

Revisão Contínua. A Anthropic pode solicitar que o Cliente forneça evidência de conformidade com esses Requisitos de Segurança do Programa de Verificação Cibernética.

Autenticação Multifator. No momento do acesso do Cliente ao CVP, todas as contas que podem fazer login no Espaço de Trabalho Concedido ou manter credenciais para ele devem ter autenticação multifator habilitada. Até 15 de dezembro de 2026 (a "Data Limite"), todas essas contas devem usar autenticação multifator resistente a phishing conforme definido na folha de fatos do CISA "Implementando MFA Resistente a Phishing" e com NIST SP 800-63B-4, significando (i) uma chave de segurança FIDO2/WebAuthn, (ii) uma passkey, no dispositivo ou em um gerenciador de senhas, ou (iii) um smartcard/PIV, e o login por link mágico de email deve ser desabilitado. SMS, voz, códigos enviados por email, códigos de aplicativo autenticador e aprovações por push não se qualificam.

Gerenciamento de Credenciais. Até a Data Limite, credenciais estáticas baixadas, exportadas ou de longa duração, incluindo chaves de API, não devem ser usadas para acessar o modelo. Os seguintes requisitos se aplicam ao Cliente com base na(s) plataforma(s) de implantação através da(s) qual(is) o Cliente acessa o modelo. Para cada plataforma aplicável, todos os Usuários Aprovados e todas as cargas de trabalho devem se autenticar usando credenciais de curta duração emitidas e gerenciadas pelo serviço de identidade nativo dessa plataforma.

Chaves de API Provisórias. Até a Data Limite, chaves de API são permitidas sob uma concessão de Acesso de Defesa apenas se cada chave for (i) armazenada em um gerenciador de segredos ou gerenciador de senhas, (ii) atribuída a uma única pessoa ou carga de trabalho, (iii) mantida fora do código-fonte e (iv) substituída pelo menos a cada 7 dias. A Anthropic pode limitar o tempo de vida das chaves de API sob uma concessão de Acesso de Defesa a 7 dias e pode desabilitar chaves de API no Espaço de Trabalho Concedido a partir da Data Limite.

Usuários Aprovados. Não há limite padrão no número de Usuários Aprovados neste Nível de Acesso.

Indivíduos são elegíveis apenas para Acesso de Defesa. Quando a concessão é mantida por um indivíduo, esta seção se aplica

Gerenciamento de Credenciais. Os seguintes requisitos se aplicam ao Cliente com base na(s) plataforma(s) de implantação através da(s) qual(is) o Cliente acessa o modelo. Para cada plataforma aplicável, todos os Usuários Aprovados e todas as cargas de trabalho devem se autenticar usando credenciais de curta duração emitidas e gerenciadas pelo serviço de identidade nativo dessa plataforma.

Autenticação Multifator. No momento do acesso do Cliente ao CVP, autenticação multifator resistente a phishing deve proteger (i) todas as contas que podem fazer login no Espaço de Trabalho Concedido ou manter credenciais para ele, (ii) contas de Usuários Aprovados no provedor de identidade do Cliente, (iii) identidades AWS, Google Cloud ou Azure que podem chamar o modelo, (iv) acesso administrativo a qualquer coisa que emita ou armazene credenciais de modelo e (v) qualquer desktop virtual ou enclave usado para atender a esses requisitos. Autenticação multifator resistente a phishing significa (i) uma chave de segurança FIDO2/WebAuthn, (ii) uma passkey, no dispositivo ou em um gerenciador de senhas, ou (iii) um smartcard/PIV, consistente com a folha de fatos do CISA "Implementando MFA Resistente a Phishing" e NIST SP 800-63B-4. SMS, voz, códigos enviados por email, códigos de aplicativo autenticador e aprovações por push não se qualificam, e o login por link mágico de email deve ser desabilitado.

Contas Organizacionais. Usuários Aprovados devem fazer login com contas no domínio do Cliente. Contas pessoais e de webmail não são permitidas.

Usuários Aprovados. O Espaço de Trabalho Concedido é limitado a setenta e cinco (75) Usuários Aprovados que pessoalmente realizam ou supervisionam diretamente o trabalho para o qual a concessão foi aprovada. Identidades de carga de trabalho não contam para esse número. O Cliente pode solicitar assentos adicionais de Usuários Aprovados por escrito (email é suficiente). Apenas administradores nomeados podem adicionar membros, alterar funções ou criar identidades de carga de trabalho ou credenciais no Espaço de Trabalho Concedido.

Gateways. Se o Cliente operar um gateway ou proxy na frente do modelo, ele deve admitir apenas Usuários Aprovados ou suas identidades de carga de trabalho, usar uma credencial de curta duração própria e manter seus logs e transcrições restritos aos Usuários Aprovados e às equipes de segurança, administração de TI ou confiança e segurança do Cliente.

Sistemas de Credenciais Operados pelo Cliente. Credenciais emitidas pelos próprios sistemas do Cliente devem expirar dentro de 12 horas, devem ser emitidas apenas após autenticação multifator resistente a phishing (para pessoas) ou uma identidade de carga de trabalho verificada (para serviços) e não devem deixar nenhuma credencial estática em endpoints, código-fonte ou armazenamentos compartilhados. As chaves e segredos que podem emitir credenciais de modelo devem ser mantidos em um gerenciador de segredos ou serviço de gerenciamento de chaves com registro de acesso.

Revogação. O Cliente deve ser capaz de revogar qualquer credencial ou identidade comprometida dentro de 24 horas.

Desligamento. O Cliente deve remover Usuários Aprovados que saíram ou foram reatribuídos e suas identidades de carga de trabalho do Espaço de Trabalho Concedido dentro de três (3) dias úteis.

Saída de Rede. Onde quer que o modelo execute trabalho ofensivo ou agêntico, o tráfego de saída deve ser limitado a uma lista de permissões aplicada fora do host e deve ser registrado. Estações de trabalho usadas apenas para prompts interativos podem usar uma lista de permissões no host se o próprio trabalho agêntico for executado em uma sandbox que não possa alterar essa lista.

Dispositivos Gerenciados. Usuários Aprovados devem acessar o Espaço de Trabalho Concedido apenas de dispositivos que o Cliente controla e que recebem atualizações automáticas ou regularmente agendadas do sistema operacional, não de dispositivos pessoais.

Verificações de Antecedentes. Todo Usuário Aprovado, incluindo contratados, deve ter passado por uma verificação de identidade e, onde legal, uma verificação de histórico criminal. Onde a lei local restringe verificações criminais, verificação de identidade, direito de trabalho ou verificação de emprego é aceita. Verificação governamental ou uma autorização satisfaz esse requisito.

Procedimento de Incidente. O Cliente deve manter um procedimento documentado para suspeita de comprometimento ou abuso da concessão que cubra revogação de credenciais e suspensão de assento.

Entidades Governamentais. Uma Autoridade FISMA para Operar com uma avaliação anual independente do Inspetor Geral contra NIST SP 800-53 ou um esquema nacional equivalente satisfaz os requisitos de Dispositivos Gerenciados, Verificações de Antecedentes e Procedimento de Incidente. Todos os outros requisitos continuam a se aplicar.

Autenticação Multifator. No momento do acesso do Cliente ao CVP, autenticação multifator resistente a phishing deve proteger (i) todas as contas que podem fazer login no Espaço de Trabalho Concedido ou manter credenciais para ele, (ii) contas de Usuários Aprovados no provedor de identidade do Cliente, (iii) identidades AWS, Google Cloud ou Azure que podem chamar o modelo, (iv) acesso administrativo a qualquer coisa que emita ou armazene credenciais de modelo e (v) qualquer desktop virtual ou enclave usado para atender a esses requisitos. Autenticação multifator resistente a phishing significa (i) uma chave de segurança FIDO2/WebAuthn, (ii) uma passkey, no dispositivo ou em um gerenciador de senhas, ou (iii) um smartcard/PIV, consistente com a folha de fatos do CISA "Implementando MFA Resistente a Phishing" e NIST SP 800-63B-4. SMS, voz, códigos enviados por email, códigos de aplicativo autenticador e aprovações por push não se qualificam, e o login por link mágico de email deve ser desabilitado.

Gerenciamento de Credenciais. Os seguintes requisitos se aplicam ao Cliente com base na(s) plataforma(s) de implantação através da(s) qual(is) o Cliente acessa o modelo. Para cada plataforma aplicável, todos os Usuários Aprovados e todas as cargas de trabalho devem se autenticar usando credenciais de curta duração emitidas e gerenciadas pelo serviço de identidade nativo dessa plataforma.

Logon Único e Contas Organizacionais. Usuários Aprovados devem fazer login com contas no próprio domínio do Cliente. Usuários Aprovados devem fazer login com identidades de domínio organizacional federadas através do logon único do Cliente. Contas pessoais, de webmail e não federadas não são permitidas.

Usuários Aprovados. O Espaço de Trabalho Concedido é limitado a 25 Usuários Aprovados que pessoalmente realizam ou supervisionam diretamente o trabalho para o qual a concessão foi aprovada. Identidades de carga de trabalho não contam para esse número. O Cliente pode solicitar assentos adicionais de Usuários Aprovados por escrito (email é suficiente). Apenas administradores nomeados podem adicionar membros, alterar funções ou criar identidades de carga de trabalho ou credenciais no Espaço de Trabalho Concedido.

Gateways. Se o Cliente operar um gateway ou proxy na frente do modelo, ele deve admitir apenas Usuários Aprovados ou suas identidades de carga de trabalho, usar uma credencial de curta duração própria e manter seus logs e transcrições restritos aos Usuários Aprovados e às equipes de segurança, administração de TI ou confiança e segurança do Cliente.

Sistemas de Credenciais Operados pelo Cliente. Credenciais emitidas pelos próprios sistemas do Cliente devem expirar dentro de 12 horas, devem ser emitidas apenas após autenticação multifator resistente a phishing (para pessoas) ou uma identidade de carga de trabalho verificada (para serviços) e não devem deixar nenhuma credencial estática em endpoints, código-fonte ou armazenamentos compartilhados. As chaves e segredos que podem emitir credenciais de modelo devem ser mantidos em um gerenciador de segredos ou serviço de gerenciamento de chaves com registro de acesso.

Revogação. O Cliente deve ser capaz de revogar qualquer credencial ou identidade comprometida dentro de 24 horas.

Desligamento. O Cliente deve remover Usuários Aprovados que saíram ou foram reatribuídos e suas identidades de carga de trabalho do Espaço de Trabalho Concedido dentro de 3 dias úteis.

Saída de Rede. Onde quer que o modelo execute trabalho ofensivo ou agêntico, o tráfego de saída deve ser limitado a uma lista de permissões aplicada fora do host e deve ser registrado. Estações de trabalho usadas apenas para prompts interativos podem usar uma lista de permissões no host se o próprio trabalho agêntico for executado em uma sandbox que não possa alterar essa lista.

Dispositivos Gerenciados e Proteção contra Malware. Usuários Aprovados devem acessar o Espaço de Trabalho Concedido apenas de dispositivos que o Cliente controla, não de dispositivos pessoais, e que recebem atualizações automáticas ou regularmente agendadas do sistema operacional. Todo dispositivo que um Usuário Aprovado usa para acessar o Espaço de Trabalho Concedido deve ser gerenciado pelo Cliente e deve executar lista de permissões ou negação de aplicativos em modo de aplicação ou um agente de detecção e resposta de endpoint em modo de bloqueio ou prevenção. Um desktop virtual gerenciado ou enclave que atenda a esse padrão também se qualifica.

Verificações de Antecedentes. Todo Usuário Aprovado, incluindo contratados, deve ter passado por uma verificação de identidade e, onde legal, uma verificação de histórico criminal. Onde a lei local restringe verificações criminais, verificação de identidade, direito de trabalho ou verificação de emprego é aceita. Verificação governamental ou uma autorização satisfaz esse requisito.

Procedimento de Incidente. O Cliente deve manter um procedimento documentado para suspeita de comprometimento ou abuso da concessão que cubra revogação de credenciais, suspensão de assento e notificação da Anthropic.

Entidades Governamentais. Uma Autoridade FISMA para Operar com uma avaliação anual independente do Inspetor Geral contra NIST SP 800-53 ou um esquema nacional equivalente satisfaz os requisitos de Dispositivos Gerenciados e Proteção contra Malware, Verificações de Antecedentes e Procedimento de Incidente. Todos os outros requisitos continuam a se aplicar.