Capítulo 19 — Identidade e criptografia

Capítulo 19 — Identidade e criptografia

Mapa da aula

Aula 19 publicada. Mapa, exemplo, EX055.

flowchart TD
  N0["19.1 Identidades para agentes"]
  N1["19.2 Hashing e manifestos"]
  N2["19.3 Assinaturas e proveniência"]
  N3["19.4 Criptografia"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX055"]

Desenho lógico

flowchart LR
  N0["19.1 Identidades para agentes"]
  N1["19.2 Hashing e manifestos"]
  N2["19.3 Assinaturas e proveniência"]
  N3["19.4 Criptografia"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX055"]

[19.1 Identidades para agentes]
    |
    v
[19.2 Hashing e manifestos]
    |
    v
[19.3 Assinaturas e proveniência]
    |
    v
[19.4 Criptografia]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX055]

Objetivos de aprendizagem

Você vai (1) projetar identidade e acesso para usuários, serviços e agentes de IA; (2) aplicar hashing, assinaturas e criptografia a artefatos de IA; (3) verificar a integridade de modelos e conjuntos de dados com manifestos; e (4) explicar proveniência e assinatura na cadeia de suprimentos de IA.

19.1 Identidades para agentes

Toda ação precisa ser atribuível. Um agente de IA deve agir em nome de um usuário, com permissões delegadas e de escopo definido (por exemplo, tokens OAuth restritos a escopos específicos), e não com uma conta de serviço poderosa. Credenciais de curta duração limitam o dano se vazarem; nunca coloque credenciais em prompts. Delegação significa que o agente nunca pode fazer mais do que o usuário poderia, e os logs mostram ambos: o usuário em nome de quem a ação foi executada e o agente que a propôs. Uma conta de serviço compartilhada apaga essa distinção, de modo que, depois de um incidente, ninguém consegue dizer qual conversa causou qual ação. Tokens que duram minutos em vez de meses também fazem com que uma credencial copiada de um log já seja inútil quando alguém tentar usá-la.

19.2 Hashing e manifestos

Um hash criptográfico como o SHA-256 mapeia um arquivo para um resumo de tamanho fixo; qualquer mudança — mesmo de um bit — produz um resumo diferente. Um manifesto lista o resumo esperado de cada artefato (pesos, tokenizador, configuração). O laboratório detecta tanto a mudança de um bit nos pesos quanto uma linha de configuração acrescentada.

"""Lab H: integrity of model artefacts with SHA-256 manifests (stdlib only).
Creates synthetic 'artefact' bytes, records a manifest, then detects a
one-byte tampering and a swapped file. No real models are involved."""
import hashlib, json
files = {"model.bin": bytes(range(256)) * 40, "tokenizer.json": b'{"vocab": ["a", "b"]}',
         "config.yaml": b"layers: 4\nheads: 8\n"}
manifest = {n: hashlib.sha256(b).hexdigest() for n, b in files.items()}
print(json.dumps({k: v[:16] for k, v in manifest.items()}, indent=1))
received = dict(files)
tampered = bytearray(received["model.bin"]); tampered[5000] ^= 1
received["model.bin"] = bytes(tampered)
received["config.yaml"] = b"layers: 4\nheads: 8\ntrust_remote_code: true\n"
for n, b in sorted(received.items()):
    ok = hashlib.sha256(b).hexdigest() == manifest[n]
    print(f"{n:15s} {'OK' if ok else 'MISMATCH'}")

Saída esperada:

{
 "model.bin": "e96760a87768717b",
 "tokenizer.json": "f63d2ddabc61f2d9",
 "config.yaml": "e5bbb570ca0fcb87"
}
config.yaml     MISMATCH
model.bin       MISMATCH
tokenizer.json  OK

A saída mostra por que cada arquivo precisa de sua própria entrada: o tokenizador não foi tocado e passa, enquanto duas mudanças diferentes em dois arquivos são detectadas cada uma de forma independente. Um único bit invertido no deslocamento 5000 basta para mudar por completo o resumo do arquivo de pesos.

19.3 Assinaturas e proveniência

Um hash prova que um arquivo corresponde a um manifesto; uma assinatura digital sobre o manifesto prova quem o produziu. Assinar artefatos de modelos e registrar a proveniência (quais dados, código e pipeline os produziram) permite aos consumidores verificar a origem. Isso trata o OWASP LLM03 (cadeia de suprimentos) e os riscos de backdoor em modelos de terceiros (Gu et al., arXiv:1708.06733). As assinaturas deslocam a questão da confiança para a chave de assinatura: quem a detém, como é protegida e como um consumidor fica sabendo qual chave esperar. A proveniência acrescenta um contexto que a assinatura sozinha não dá, como a versão do conjunto de dados usada, para que o consumidor possa julgar se o modelo é adequado ao seu uso, e não apenas autêntico.

19.4 Criptografia

Criptografe dados de treinamento e pesos em repouso e todo o tráfego em trânsito (TLS). A criptografia protege a confidencialidade contra o roubo do armazenamento e a interceptação, mas não contra uma consulta de aparência legítima que extrai informações do modelo. As chaves precisam ser gerenciadas separadamente dos dados que protegem; um arquivo de pesos criptografado guardado ao lado de sua chave não protege nada. A criptografia também deixa intacto o comportamento do próprio modelo. Um usuário com acesso comum de consulta ainda pode extrair dados de treinamento ou reconstruir um modelo por meio de suas respostas, então a criptografia é combinada com limites de consulta e controles de saída. Os engenheiros registram quais ameaças cada controle de criptografia trata e quais explicitamente não trata.

19.5 Exemplo resolvido (caso sintético da NRS)

A NRS recebe atualizações do modelo do TrackEye de um fornecedor de modelos de visão. Sam exigiu um manifesto assinado com resumos SHA-256 de cada arquivo, verificado no computador do trem de inspeção antes do carregamento. Em um teste, uma configuração modificada que habilitava o carregamento de código remoto foi rejeitada, em linha com o config.yaml MISMATCH do laboratório. Verificar no trem, e não no depósito, importa porque os arquivos poderiam ser alterados em qualquer ponto entre o fornecedor e o dispositivo. A assinatura do manifesto é verificada primeiro; os hashes dos arquivos só são considerados confiáveis depois que se comprova que a assinatura vem da chave esperada do fornecedor.

19.6 Erros e limites

Três erros são comuns: agentes usando contas de serviço administrativas compartilhadas; hashes obtidos do mesmo lugar que os arquivos (um atacante pode mudar ambos); e supor que a criptografia impede o vazamento no nível do modelo. Contas administrativas compartilhadas tornam toda ação de agente tão poderosa quanto a tarefa mais poderosa de que qualquer agente precise. Um hash baixado do mesmo servidor que o arquivo prova apenas que o servidor é coerente consigo mesmo, então o resumo esperado precisa chegar por um canal separado e confiável, como um manifesto assinado. A criptografia protege dados em repouso e em trânsito, mas um modelo que responde a consultas ainda pode revelar o que aprendeu.

Exercícios

• EX055 — Leitura do laboratório. Quais arquivos falham no Laboratório H e por que o tokenizer.json passa? Rubrica: 3 = model.bin (bit invertido) e config.yaml (linha acrescentada); tokenizador inalterado; 2 = parcial; 1 = vago; 0 = errado.
• EX056 — Hashes da mesma origem. Por que um manifesto baixado do mesmo servidor que o modelo é fraco, e o que corrige isso? Rubrica: 3 = um atacante que controla o servidor muda ambos; manifesto assinado com chave fixada; 2 = parcial; 1 = vago; 0 = errado.
• EX057 — Delegação. Projete a credencial da ferramenta de ordens de serviço do Wrench. Rubrica: 3 = delegada por usuário, com escopo de criar rascunho, de curta duração, registrada em log; 2 = três; 1 = um; 0 = nenhum.

Síntese

A identidade torna as ações dos agentes atribuíveis e limitadas; hashes, assinaturas e proveniência tornam os artefatos de IA verificáveis. Juntos, ancoram a confiança na cadeia de suprimentos de IA.

Continue estudando — capítulo 19 de 50

← Capítulo 18 (rascunho) · Índice de capítulos do curso · Capítulo 20 (rascunho) →