<p>
<a href="https://kontext.security">Website</a>
|
<a href="https://docs.kontext.security/getting-started/welcome">Documentation</a>
|
<a href="https://app.kontext.security">Dashboard</a>
|
<a href="https://discord.gg/gw9UpFUhyY">Discord</a>
</p>

</div>

# Impeça ações arriscadas de agentes de IA antes que elas sejam executadas

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 impediria. Mova os limites suportados para o modo de aplicação quando estiver pronto.

Erros de avaliação de política permitem a chamada da ferramenta, inclusive no modo de aplicação, e permanecem visíveis como falhas no registro de atividades. Negações de política concluídas e aprovações obrigatórias indisponíveis ainda bloqueiam. Esse fallback de erro não altera o comportamento quando o daemon está indisponível ou quando a aplicação não tem uma política utilizável.

- **Decisões locais:** a avaliação de política acontece junto ao agente.
- **Aplicação pré-ação:** ações correspondentes podem ser negadas em hooks síncronos suportados.
- **Sem comando wrapper:** instale o Kontext uma vez e continue usando seus agentes normalmente.
- **Evidência atribuível:** preserve o agente, a sessão, a ação, a decisão de política e o resultado.
- **Implantação gerenciada:** distribua políticas e revise registros redigidos em toda uma organização.

Atualmente, o Kontext oferece suporte a **Claude Code, Claude Cowork e Codex**. A cobertura exata de eventos e aplicação varia por agente — consulte a
[matriz de suporte de agentes](https://github.com/kontext-security/kontext-cli/blob/main/docs/coverage.md).

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.

---

## Início rápido

### Instale o Kontext

```bash
brew install kontext-security/tap/kontext
```

### Conecte este Mac

Crie um token de instalação no
[dashboard do Kontext](https://app.kontext.security) e execute:

```bash
kontext setup
```

O modelo de risco local opcional precisa do llama.cpp: execute `brew install llama.cpp` e depois `kontext setup --with-local-llm`.

O setup:

- armazena o token de instalação no keychain de login do macOS;
- instala hooks para os agentes suportados;
- inicia o daemon local do Kontext;
- conecta a instalação à sua organização Kontext.

Verifique a instalação:

```bash
kontext doctor
```

Depois, continue usando o Claude Code ou o Codex normalmente. Você não precisa iniciar o agente por meio de um wrapper separado.

> O setup self-serve atualmente oferece suporte a macOS. Ambientes gerenciados e de nuvem podem executar o mesmo runtime local quando fornecem um contrato de hook suportado, armazenamento e ciclo de vida do daemon.

---

## O que muda após o setup?

Sem uma política pré-ação, uma ação do agente é executada antes que uma equipe de segurança possa revisar seus logs:

```text
agent requests an action
|
v
action executes
|
v
activity appears in a log
```

Com o Kontext:

```text
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.

---

## Observe primeiro. Aplique quando estiver pronto.

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:

### Modo de observação

O modo de observação registra a decisão de política sem interromper o agente.

Use-o para responder:

- Quais ferramentas os agentes estão chamando?
- Quais ações a política atual negaria?
- Quais repositórios, arquivos e sistemas estão envolvidos?
- Onde a aplicação interromperia trabalho legítimo?
- Quais superfícies de eventos realmente conseguem parar a ação?

### Modo de aplicação

O modo de aplicação retorna uma negação real quando uma política determinística corresponde a um hook pré-ação síncrono suportado.

As políticas podem definir limites em torno de ações como:

- comandos destrutivos;
- acesso a arquivos sensíveis;
- operações em sistemas de produção;
- acesso a credenciais;
- exportações de dados.

A aplicação é intencionalmente limitada a superfícies de eventos em que o agente espera pelo Kontext antes de continuar. O Kontext não afirma que receber um evento significa que ele pode parar toda ação desse agente.

---

## Saiba o que aconteceu — e por quê

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 agente e a sessão;
- o evento de ciclo de vida ou de ferramenta;
- o nome da ferramenta e a entrada disponível;
- a decisão de política local;
- a política responsável por essa decisão;
- o resultado disponível da ação;
- evidências redigidas para revisão posterior.

O Kontext registra a atividade das 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.

Implantações gerenciadas podem exportar registros redigidos para o dashboard do Kontext para revisão, retenção e investigação em toda a organização.

Exportações do livro-razão e heartbeats ociosos relatam a versão da 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 da CLI relatada até que um daemon executando o novo binário
envie telemetria.

---

## Política onde o agente é executado

O caminho de decisão permanece local:

Um serviço hospedado não precisa responder a cada chamada de ferramenta.

Implantações gerenciadas adicionam configuração organizacional, distribuição de políticas, exportação de registros, identidade e retenção. Elas não movem o caminho de decisão síncrono para fora do ambiente do agente.

---

## Agentes suportados

“Suportado” significa mais do que aceitar um evento. O Kontext documenta quais eventos
recebe, quais eventos podem bloquear e como cada integração é instalada.

| Agent | What Kontext records | Pre-action blocking | Installation |
| --- | --- | --- | --- |
| **Claude Code** | Session lifecycle, pre-tool-use, successful and failed post-tool-use | Pre-tool-use | Installed by `kontext setup` |
| **Codex** | Session start, pre-tool-use, post-tool-use, prompt submission, stop | Pre-tool-use | Installed by `kontext setup`; hooks must be trusted in Codex |
| **Claude Cowork** | Claude Code-compatible session and tool events | Pre-tool-use | Configure the hook inside the Cowork environment |

Consulte a [matriz de suporte de agentes](https://github.com/kontext-security/kontext-cli/blob/main/docs/coverage.md) para o comportamento exato, o escopo de implantação e as lacunas conhecidas. Ela é a fonte autoritativa para a cobertura de aplicação.

---

## Kontext e sandboxes resolvem problemas diferentes

Um sandbox de processo pergunta:

> Quais arquivos, destinos de rede, credenciais e recursos do sistema operacional
> este processo pode acessar?

O Kontext pergunta:

> Qual agente está tentando qual ação, qual política se aplica, a ação deve
> prosseguir e qual evidência comprova a decisão?

Sandboxes de kernel são limites de contenção fortes. O Kontext fornece política semântica e atribuição em hooks suportados de agentes e ferramentas.

Eles são complementares:

```text
Kontext
decides whether the action is authorized
|
v
sandbox
constrains what the process can physically access
```

O Kontext não reivindica isolamento em nível de kernel. Use um sandbox apropriado quando o modelo de ameaça exigir contenção de processo, sistema de arquivos ou rede.

---

## Por que não apenas coletar logs dos agentes?

Logs informam o que um agente relatou após um evento.

O Kontext cria uma decisão de autorização antes que ações consequentes suportadas sejam executadas e, em seguida, vincula essa decisão ao resultado disponível.

Essa distinção importa durante:

- implantação de políticas;
- investigação de incidentes;
- revisão de acesso a produção;
- tratamento de exceções de desenvolvedores;
- revisão de conformidade e auditoria.

O resultado não é apenas “o agente chamou uma ferramenta”. É evidência do que foi solicitado, qual política se aplicou, se foi permitido e o que aconteceu em seguida.

---

## Execute o Kontext em toda a sua organização

Implantações gerenciadas adicionam:

- política determinística gerenciada centralmente;
- identidade corporativa e controles organizacionais;
- implantação de observação para aplicação;
- suporte a implantação gerenciada de agentes e nuvem;
- exportação de evidências redigidas;
- retenção de auditoria;
- monitoramento de integridade e backlog de implantação;
- onboarding para equipes de segurança e plataforma.

Para planejamento de implantação e onboarding da organização, entre em contato com
[[email protected]](mailto:[email protected]) ou
[agende uma conversa](https://calendar.superhuman.com/book/11W5Y8b5JsB8dOzQbd/YECs9).

---

## Diagnostique uma instalação

```bash
kontext doctor
```

O `doctor` verifica:

- hooks de agentes instalados;
- integridade e versão do daemon;
- integridade da exportação gerenciada;
- backlog de exportação pendente.

Ele sai com código diferente de zero quando uma instalação configurada está não saudável.

A validação de hooks do Claude aceita aspas de shell equivalentes, mas ainda exige
o executável, os argumentos e as configurações de eventos esperados. O diagnóstico de hooks do Codex
verifica arquivos de sistema e de usuário: um arquivo ausente ou vazio é válido quando o outro
contém uma instalação completa. Arquivos não vazios malformados ou incompletos e
instalações conflitantes ainda relatam uma configuração não saudável.

Quando um drop-in do Claude de propriedade própria está sem apenas os eventos exigidos pela versão
atual, o doctor nomeia os eventos ausentes e o comando `hooks install` específico do escopo.
Reparos self-serve solicitam sudo apenas para atualizar o arquivo de sistema do Claude;
reparos de organização exigem `sudo` com `--scope system`. `doctor --fix` não
reinstala hooks.

Quando um daemon self-serve está desatualizado:

```bash
kontext doctor --fix
```

Rotacione o token de instalação executando o setup novamente:

```bash
kontext setup
```

Remova a instalação self-serve:

```bash
kontext setup --uninstall
```

---

## Tratamento de dados

- As decisões de política acontecem localmente.
- A atividade das ferramentas e as evidências de decisão são armazenadas localmente.
- Valores sensíveis são redigidos antes do armazenamento local e da exportação gerenciada.
- O Kontext não armazena raciocínio do modelo nem histórico completo da conversa.
- Implantações gerenciadas podem exportar registros redigidos para o dashboard da organização.

Consulte a [documentação do Guard](https://github.com/kontext-security/kontext-cli/blob/main/docs/guard.md) para o runtime e o limite de dados.

---

## Desenvolvimento

```bash
go build -o bin/kontext ./cmd/kontext
go test ./...
go test -race ./...
go vet ./...
```

## Comunidade

- Leia o [SUPPORT.md](https://github.com/kontext-security/kontext-cli/blob/main/SUPPORT.md) para os canais de suporte.
- Leia o [CONTRIBUTING.md](https://github.com/kontext-security/kontext-cli/blob/main/CONTRIBUTING.md) antes de abrir uma contribuição.
- Relate vulnerabilidades por meio da nossa [Política de Segurança](https://github.com/kontext-security/kontext-cli/blob/main/SECURITY.md).
- O Kontext é distribuído sob a [Licença MIT](https://github.com/kontext-security/kontext-cli/blob/main/LICENSE).

### Relatório de autoridade

`kontext report` mostra os agentes descobertos e a autoridade exatamente como aceitos pela última vez
pela nuvem. Use `kontext report --json` para o payload bruto. Antes do primeiro
envio bem-sucedido, ele não relata dados.

Defina `KONTEXT_AUTHORITY_SCAN=off` no ambiente do daemon para desativar a coleta e transmissão de autoridade neste Mac.

Baixar ferramenta

kontext-cli

Mais Populares