Governança: leitura primeiro e deny-closed

A governança no Olivares AI assenta em dois princípios que cabem na cabeca de qualquer pessoa: observar antes de aplicar, e quando aplicar, negar por defeito. O produto mapeia e audita o que cada agente pode alcançar muito antes de bloquear uma única ação, e os bloqueios que executa são deny-closed.

Leitura primeiro: observação antes da aplicação

A postura predefinida da plataforma e detetiva, não preventiva. Constroi o mapa de acesso leitura/escrita ingerindo registos, OpenTelemetry e auditoria nativa fora de banda — nunca esta no caminho de dados do agente, portanto um coletor que falha não pode derrubar a produção. A partir desse mapa compara permitido contra observado e apresenta desvios para um humano julgar.

Isto importa para como le o resto desta página. O produto observa e governa amplamente; não atua amplamente. Onde pode executar uma ação na sua infraestrutura, essa capacidade e uma de três coisas, e o catalogo de módulos marca qual:

• live — ligado e ativo hoje (um conjunto restrito);
• on-demand — o backend esta construído e ligado a um ponto de injeção mas permanece deny-closed ou degradado até que o provisione (um executor, um despachante, uma credencial de inferência);
• seam — uma interface declarada, deny-closed, sem backend no binário predefinido.

Portanto, uma ausência de aplicação e geralmente por design, não uma falha. Leitura primeiro significa que o padrão honesto e observar e registar, e bloquear apenas as superficies que ativou explicitamente.

O modelo de autorização dentro do qual governa

Cada decisão governada passa pelo mesmo núcleo de autorização que protege o resto da API. Três propriedades merecem ser interiorizadas antes de mudar algo.

RBAC e deny-by-default. Um principal sem membros num inquilino e negado — não existe concessão implicita. As permissões tem escopo de inquilino, e um handler atua apenas no único inquilino para o qual o pedido foi resolvido, o que fecha classes de confused-deputy e IDOR por construção. Os papeis formam uma escada: viewer le, editor escreve, admin gere IAM do inquilino, owner detém tudo. Ler o grafo de acesso e deliberadamente um privilégio de editor ou superior — um mapa completo do que cada agente pode tocar e um roteiro de reconhecimento — e cada tal leitura e escrita no registo de auditoria.

A camada de políticas só restringe. Sobre RBAC pode ligar um ponto de decisão de políticas baseado em atributos. A composição e uma intersecao — RBAC ∩ ABAC nativo ∩ PDP externo — portanto uma política só pode restringir ainda mais o que RBAC já permitiu; nunca pode ampliar uma concessão. Isto é aplicado, não uma convencao. Escolhe no máximo um motor externo:

# Cedar embebido (Go puro, sem sidecar) ou OPA via HTTP. Predefinicao: none.
OLIVARES_PDP_ENGINE=cedar   # ou: opa | none

Com Cedar escreve regras forbid; um conjunto de regras vazio deixa a decisão RBAC intacta. Com OPA o seu Rego deve ser permit-by-default, onde um resultado em falta ou qualquer erro de transporte falha fechado. Uma configuração PDP invalida desativa apenas o PDP externo e regista o facto — ABAC nativo e RBAC continuam a governar, e um motor mal configurado nunca deixa um pedido sem governança. Cada restrição que o PDP aplica e auditada.

Níveis de risco e o piso de duplo controlo

As ações que chegam a fila de aprovação são classificadas em quatro níveis de risco — low, medium, high, critical — seguindo a taxonomia de agentes AI da OWASP. (Este e um eixo separado dos níveis de conformidade do EU AI Act; não confundir os dois.) O nível e re-derivado da política em vigor a cada decisão de segurança, nunca lido de um snapshot armazenado, portanto uma mudança de política tem efeito imediato e uma linha obsoleta nunca pode manter a fasquia abaixo da classificação atual.

Uma ação critical transporta um piso obrigatório de duas pessoas: pelo menos dois aprovadores humanos distintos, retirado de NIST SP 800-53 AC-3(2) autorização dupla. O piso e aplicado duas vezes — na criacao (o limiar armazenado nunca pode começar abaixo dele) e re-derivado na decisão (uma linha rebaixada ou legada ainda não pode passar com um aprovador) — portanto mesmo uma política de operador que explicitamente baixe o nível não pode tornar uma ação crítica unilateral. O conjunto crítico incorporado e a familia irreversivel e moldadora do ambiente: implantação e retirada em produção, eliminação de dados, alterações de aplicação de segurança, custódia e rotação de chaves, e reativação do ambiente após um kill switch.

Níveis inferiores não alteram a mecanica do motor — uma aprovação que já existe exige pelo menos um humano — são o vocabulário em que outros controlos se baseiam (por exemplo, elevar a autenticação numa ação crítica).

O portão de aprovação human-in-the-loop

Onde o produto bloqueia uma ação, o ciclo e: uma superficie apresenta (desvio do mapa de acesso, um achado do módulo de segurança) → um operador autorizado decide → a decisão e registada no registo de auditoria. O motor de aprovação que suporta isto é real hoje: um pedido abre deny-closed, vinculado a um hash de plano, e com limite temporal. Os invariantes são aplicados do lado do servidor, baseados na identidade estavel do utilizador (um token de sistema não tem identidade e não pode decidir):

• Separação de deveres — o requerente nunca pode decidir o seu próprio pedido.
• Guarda de decisor duplicado — um humano conta uma vez para um limiar.
• Expiracao — derivada na leitura, portanto um pedido expirado nunca pode vincular mesmo antes de uma varredura materializar a sua expiracao.

O que ainda esta a amadurecer e a consola de revisão de operador mais rica; os endpoints e o motor já estão implementados. O guia Governar e aprovar percorre o fluxo ao vivo.

A dependência que torna qualquer disto credivel e a identidade por agente. A auditoria atribui atividade a uma credencial, não inerentemente a um agente; uma conta de serviço partilhada colapsa a atribuição ao nível de identidade — apresentada honestamente como um achado, nunca silenciosamente recuperada. Veja permitido vs observado e fidelidade para o que isso faz ao sinal sobre o qual governa.

Break-glass: a válvula de escape auditada

O controlo de duas pessoas precisa de uma válvula de escape para o incidente das 03:00 onde um aprovador esta inalcançável. O break-glass e essa válvula, e e ruidoso por construção. A ativação e de nível admin e exige um humano real (um token de sistema e recusado), uma verificação de hardware (AAL3), uma justificacao escrita e uma sessão ativamente gravada como pre-condicao. A concessão tem limite temporal — predefinido de uma hora, máximo de um dia — e uma concessão expirada não pode autorizar nada.

Enquanto uma concessão esta ativa, uma ação dentro do escopo pode prosseguir sem o seu quorum de aprovação, mas cada utilizacao e adicionada a uma trilha imutável e ao registo de auditoria, nomeando a concessão, a ação e o sujeito — uma ação que prosseguiu sob break-glass e permanentemente distinguivel de uma aprovada. Uma revisão pos-facto obrigatória fecha o ciclo: uma nova concessão não pode ser ativada enquanto uma anterior esteja por rever, e a revisão deve vir de um humano diferente do ativador.

O kill switch: o portão de negação de todo o ambiente

O kill switch e a paragem de emergência com um clique, e inverte a ergonomia habitual de propósito. Ativar e deliberadamente barato — nível admin, uma razao obrigatória, sem quorum de aprovação, sem elevação, sem break-glass — porque uma paragem que espera por consenso não é uma paragem. O nível de garantia da sessão que ativa e registado para perícia; abuso da ativação custa apenas disponibilidade, que é a direcao segura.

A linha de paragem e a única fonte de verdade. Cada portão de atuação governado consulta-a ao vivo em cada ação e falha fechado num erro de leitura — o inverso exato do contrato fail-open dos portões de orçamento, porque um estado de paragem ilegível nunca deve significar “avança”. Ativar também revoga o trabalho em fila que os portões não podem alcançar: cada aprovação de atuação pendente dentro do escopo e cancelada na mesma transacao, portanto uma intencao pre-paragem não pode amadurecer numa concessão que despacha no momento em que o ambiente volta. As ações de governança propriamente ditas estão isentas — a paragem interrompe o ambiente agentivo, nunca os controlos que o governam.

Reativar nunca e unilateral. Esta bloqueado por uma aprovação de duplo controlo fresca (o piso critical de dois humanos distintos, re-verificado estruturalmente na mudança para que uma política rebaixada não possa torna-lo unilateral), e deliberadamente não há caminho de break-glass para reativar: “o ambiente permanece parado” e o estado seguro. Uma revisão pos-facto obrigatória por um humano não envolvido fecha o incidente.

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 grafo de acesso, o próprio registo) auto-auditam numa escrita confirmada. O registo e apenas adicao e encadeado por hash, cada registo transportando os campos de integridade de cadeia, portanto reescrever a historia e detetável e nunca contém PII. Não pode fazer uma mudança sem governança que o registo silenciosamente esqueca.

Relacionado

• Permitido vs observado — o desvio sobre o qual estas decisões atuam.
• Fidelidade — quao confiante e o sinal subjacente a uma decisão.
• Governar e aprovar — o fluxo de aprovação ao vivo, passo a passo.
• Kill switch — o portão de negação de todo o ambiente em termos de produto.
• Honestidade e limites — a postura deny-closed, detetiva por defeito completa.