Assim que uma fonte esta ligada e o mapa de acesso mostra o que cada agente pode ler e escrever, o próximo trabalho e governa-lo: decidir quem e o que pode agir, e tornar cada decisão um facto registado. Esta página cobre o fluxo de aprovação — níveis de risco, duplo controlo, break-glass e o registo a que todos se ancoram.
A governança e deny-closed por defeito. Um principal sem papel num inquilino e negado; não há concessão implicita. O produto observa amplamente mas não atua amplamente — onde governa uma ação, fa-lo deny-closed, nunca como um executor genérico.
O modelo de autorização
Cada chamada de governança passa pelo mesmo núcleo de autorização que o resto da API: RBAC primeiro, com escopo a um único inquilino, com uma camada de política externa opcional por cima.
Os papeis formam uma escada — viewer (leitura), editor (escrita), admin (IAM de inquilino), owner
(tudo no inquilino). Ler o mapa de acesso deliberadamente não e o nível mais baixo:
um mapa do que cada agente pode tocar e um roteiro de reconhecimento, portanto é concedido de editor para cima,
com escopo de inquilino, e cada leitura e escrita no registo.
Um ponto de decisão de políticas opcional (Cedar embebido, ou OPA via HTTP) pode sobrepor regras baseadas em atributos. Compoe-se como uma intersecao — RBAC ∩ ABAC nativo ∩ PDP externo — e tem um invariante:
A camada de políticas só pode retirar acesso, nunca adiciona-lo. Uma política pode negar algo que RBAC teria permitido; nunca pode conceder algo que RBAC nega. Um PDP mal configurado ou inalcançável falha fechado, e desativar o PDP externo nunca deixa pedidos sem governança — RBAC e ABAC nativos continuam a governar.
Níveis de risco
Uma ação governada e classificada num de quatro níveis — low, medium, high,
critical — derivados da taxonomia de risco de agentes AI da OWASP. O nível determina quanto controlo
humano a ação requer antes de poder prosseguir.
O nível não é armazenado na linha de aprovação. E re-derivado do conjunto de políticas atual mais um predefinido incorporado a cada decisão, portanto uma mudança de política tem efeito imediato e um snapshot obsoleto nunca pode manter a fasquia abaixo da classificação em vigor (deny-closed).
| Nível | Controlo predefinido |
|---|---|
low / medium | atribuído apenas por política explicita |
high | o predefinido para qualquer coisa que chegue a fila de aprovação — uma aprovação humana |
critical | um piso obrigatório de duas pessoas (veja abaixo) |
O conjunto critical incorporado cobre o genuinamente irreversivel: implantação e retirada em produção,
eliminação e apagamento de dados, aplicação de segurança e alterações de kill-switch, custódia
e rotação de chaves, e desligamento de NHI. Uma política de aprovação com um risk_tier explicito pode elevar ou
baixar o predefinido por ação — essa e a palavra auditada do operador — mas nunca pode baixar
uma ação critical abaixo do piso de duplo controlo.
Pedidos de aprovação e duplo controlo
Um pedido de aprovação abre deny-closed e com limite temporal: começa pendente, transporta uma expiracao e não autoriza nada até que humanos suficientes o decidam. Uma política de aprovação correspondente e autoritativa para o limiar e prazos, portanto um requerente nunca pode baixar a sua própria fasquia.
Três invariantes são aplicados do lado do servidor, não por convencao:
- Separação de deveres. O requerente não pode decidir o seu próprio pedido. Baseia-se na identidade estavel do utilizador, não na string de credencial que uma única pessoa poderia variar.
- Uma decisão por humano. Um índice único protege contra uma corrida de decisor duplicado; a mesma pessoa não pode contar duas vezes para o limiar.
- A expiracao vincula. Um pedido expirado nunca pode receber uma decisão vinculante — o estado efetivo e re-derivado a cada decisão, com ou sem varredura.
Para ações critical o limiar tem piso de dois aprovadores humanos distintos (NIST
SP 800-53 AC-3(2) autorização dupla). O piso e aplicado tanto quando o pedido e
criado (o limiar armazenado nunca pode começar abaixo de dois) como re-aplicado no ponto de decisão
(um pedido criado antes de a ação se tornar crítica ainda não pode passar com um
humano). Um único aprovador nunca pode satisfazer uma ação crítica.
Uma decisão critical adicionalmente requer uma sessão verificada por hardware: o humano
decisor deve ter uma elevação WebAuthn ou PIV fresca (AAL3). Um token de sistema não transporta garantia
humana e e recusado — a system token cannot approve.
Cada decisão adiciona uma linha imutável a trilha de decisões do pedido e um evento de registo que regista a decisão, o estado resultante e o nível de risco sob o qual foi tomada.
Break-glass
O controlo de duas pessoas tem uma válvula de escape para o incidente das 03:00 onde o segundo aprovador esta inalcançável. Um admin — sempre um humano real, nunca um token de sistema — ativa uma concessão de emergência com limite temporal que permite uma ação bloqueada prosseguir sem o seu quorum. O caminho nunca e silencioso:
- A ativação requer uma justificacao, auto-audita no registo na mesma transacao e emite um achado crítico para o canal de notificações.
- Cada utilizacao adiciona uma linha imutável e um evento de registo nomeando a concessão, a ação e o sujeito. Uma ação que prosseguiu sob break-glass e permanentemente distinguivel de uma devidamente aprovada.
- A concessão tem limite temporal — predefinido de uma hora, máximo rígido de 24. Uma “emergência” que precisa de mais tempo e um modo operacional, não uma emergência, e deve passar pelo duplo controlo normal.
- Revisão pos-facto obrigatória. Uma nova concessão não pode ser ativada enquanto qualquer concessão anterior esteja por rever, e a revisão deve vir de um humano diferente do ativador. Não pode acumular emergencias para fugir ao escrutinio.
O break-glass relaxa um quorum em falta; nunca sobrepoe uma rejeição humana explicita. Um pedido que alguém deliberadamente negou permanece negado.
A garantia de decisões registadas
Seja qual for a profundidade do fluxo de trabalho acima, uma decisão de governança e um facto registado. Ações mutaveis são adicionadas ao registo de auditoria com o ator real na mesma transacao que a mudança, e leituras sensiveis (o mapa de acesso, o próprio registo) auto-auditam numa escrita confirmada. Não pode fazer uma mudança sem governança que o registo silenciosamente esqueca.
O registo e apenas adicao, encadeado por hash e assinado com Ed25519. Cada registo transporta seq,
prev_hash, hash e sig, portanto reescrever a historia e criptograficamente detetável, e o
registo nunca contém PII. Para a copia externa e imutável que um auditor pede, o registo
e exposto como uma exportação pull autenticada em /v1/audit/export, com valores de format
cef, leef, syslog, otlp e ocsf. Cada registo exportado transporta os campos de integridade
de cadeia, portanto um armazém SIEM ou WORM pode re-verificar a cadeia offline — a assinatura
desanexada defende contra um comprometimento apenas da base de dados, e a copia fora do host contra um host
totalmente comprometido.
Escopo honesto
O núcleo de autorização, o motor de aprovação e o registo funcionam hoje. O que ainda esta a amadurecer e a superficie de revisão de operador mais rica — uma consola completa de fila de aprovação; os endpoints e os invariantes do lado do servidor estão implementados, a interface polida e o caminho a seguir. Como no resto da plataforma, isto é open core pre-1.0: leia Honestidade e limites para o que esta ativo versus em fase de design. O Olivares AI e desenhado para controlos SOC 2, ISO 27001 e EU AI Act, não certificado contra eles.
Relacionado
- Governança — o modelo de autorização e postura de auto-auditoria completa.
- Permitido vs observado — o desvio sobre o qual estas decisões atuam.
- Ligar uma fonte — ligue os sinais a partir dos quais o desvio e construído.
- Kill switch — a paragem de emergência gradual para o ambiente.