kontext-security/kontext-cliSegurança em tempo de execução para agentes de IA: descubra agentes, mapeie suas permissões e imponha o que eles podem fazer.
Site | Documentação | Painel | Discord
Agentes de IA fazem mais do que sugerir código. Eles executam comandos de shell, leem arquivos, chamam serviços, alteram infraestrutura e interagem com sistemas de produção.
O Kontext coloca uma política local entre os agentes de IA e as ferramentas que eles chamam. Ele observa as ações suportadas, avalia a política antes que ações consequentes sejam executadas e registra a decisão e o resultado em um livro-razão de autorização.
Comece no modo de observação. Veja o que a política bloquearia. Migre os limites suportados para a aplicação quando estiver pronto.
Erros de avaliação de política, uma política que não está pronta (ausente, corrompida ou expirada) e uma identidade não resolvida permitem a chamada da ferramenta, inclusive no modo de aplicação, e permanecem visíveis como falhas no registro de atividades. Apenas negações de política concluídas e aprovações obrigatórias indisponíveis bloqueiam. Quando o hook não consegue obter uma decisão, porque o daemon está inativo, reiniciando, muito lento ou retorna algo ilegível, a chamada da ferramenta não é bloqueada e o Kontext não retorna nenhuma decisão, então as configurações de permissão do próprio agente se aplicam.
O Kontext atualmente suporta Claude Code, Claude Cowork e Codex. A cobertura exata de eventos e aplicação varia por agente — consulte a matriz de suporte a agentes.
Hooks gerenciados do Claude reconhecem sessões do Cowork com nomes de diretório de sessão completos ou abreviados, preservando sua identidade Cowork nos registros de atividades.
brew install kontext-security/tap/kontext
Crie um token de instalação no Kontext dashboard, depois execute:
kontext setup
Configuração:
Verifique a instalação:
kontext doctor
Em seguida, continue usando o Claude Code ou o Codex normalmente. Você não precisa iniciar o agente por meio de um wrapper separado.
A configuração autônoma atualmente oferece suporte ao macOS. Ambientes gerenciados e de nuvem podem executar o mesmo runtime local quando fornecem um contrato de hook compatível, armazenamento e ciclo de vida do daemon.
Sem uma política de pré-ação, uma ação do agente é executada antes que uma equipe de segurança possa revisar seus logs:
agent requests an action
|
v
action executes
|
v
activity appears in a log
Com Kontext:
agent requests an action
|
v
Kontext receives it through a supported hook
|
v
local policy evaluates the action
|
+---- allow ----------> action continues
|
+---- would deny -----> action continues and evidence is recorded
| (observe mode)
|
+---- deny -----------> action is stopped before execution
(enforce mode)
|
v
decision and outcome enter the authorization ledger
Isso cria um ponto de decisão antes da ação, não apenas um registro depois dela.
Bloquear toda ação desconhecida no primeiro dia gera ruído e interrompe os desenvolvedores. Permitir toda ação indefinidamente deixa a política como monitoramento passivo.
O Kontext separa a implantação em dois modos:
O modo de observação registra a decisão da política sem interromper o agente.
Use-o para responder:
O modo de aplicação retorna uma negação real quando uma política determinística corresponde a um hook síncrono de pré-ação suportado.
As políticas podem definir limites em torno de ações como:
A aplicação é intencionalmente limitada às superfícies de eventos em que o agente aguarda o Kontext antes de continuar. O Kontext não afirma que receber um evento significa que ele pode interromper toda ação desse agente.
Todo evento suportado que chega ao Kontext pode contribuir com evidências para o livro-razão de autorização local.
Um registro pode incluir:
O Kontext registra a atividade de ferramentas e as evidências de decisão. Ele não captura o raciocínio do modelo nem reconstrói o histórico completo da conversa. Cada prompt inicia um turno que agrupa as ações e o uso do modelo relacionado a ferramentas após ele; o registro do turno carrega apenas um trecho de prompt redigido e limitado quando o workspace captura Summaries ou Full payloads e tem a classificação de tipo de trabalho ativada, e apenas o tamanho do prompt caso contrário.
Implantações gerenciadas podem exportar registros redigidos para o painel do Kontext para revisão, retenção e investigação em toda a organização.
As exportações do livro-razão e os heartbeats ociosos relatam a versão CLI do daemon em execução como
device.cli_version, separadamente do marcador de pacote em
device.deployment_version (ou seu fallback self-serve). Uma atualização do marcador de pacote
não altera a versão CLI relatada até que um daemon executando o novo binário
envie telemetria.
O caminho de decisão permanece local: