Identidade
O agente deixa de usar a credencial ampla do banco. Cada chamada carrega o token pessoal do desenvolvedor.
GateKeeper
Agents
A IA pode sugerir qualquer coisa. Executar, só o que você autorizar.
O GatekeeperID opera o controle dos agentes. O Connector fica na sua infraestrutura e só aplica o que a política permite, um humano aprovou ou uma liberação antecipada concedeu.
Cursor → Connector → Política → Aprovação → PostgreSQL
O que você ganha
- Token pessoal de quem acionou o agente
- SQL destrutivo bloqueado sem autorização
- Aprovação humana no painel, com substituto
- A mesma chamada executa uma única vez
- Auditoria da cadeia inteira, por 90 dias
MCP
PostgreSQL
24h
política offline
O acesso humano limitado não vira acesso ilimitado do agente.
O Gatekeeper ID autentica pessoas. O Agents controla o que o agente executa no banco: identidade de quem acionou, política por efeito, aprovação humana e auditoria.
Recursos
O primeiro corte é o MCP PostgreSQL, com o Cursor como primeiro cliente.
Política por efeito
O Connector classifica o SQL antes de chegar ao PostgreSQL. Leitura, escrita e destruição não recebem a mesma resposta.
Aprovação
DROP, DELETE, TRUNCATE e ALTER sem autorização abrem um pedido. A cadeia de aprovadores decide no painel.
Uso único
Depois da aprovação, a mesma chamada executa uma vez. Outra chamada, mesmo parecida, pede de novo.
Auditoria
Quem pediu, quem aprovou e qual foi o efeito ficam registrados. O SQL completo permanece na sua infraestrutura.
Fail-closed
Sem o Cloud, leitura segue a política assinada por até 24 horas. Operação destrutiva não executa.
Como funciona
01
O Connector fica na sua rede
Ele fica na frente do MCP PostgreSQL. O banco e a senha não saem da infraestrutura do cliente.
02
O Cursor chama com o token pessoal
O desenvolvedor cria o token no painel e usa no agente. A credencial da instalação é outra, e fica com o administrador.
03
Destrutivo só passa com autorização
Leitura segue a política. O que apaga ou altera estrutura espera aprovação e, então, executa uma única vez.
Antes
- A credencial do banco é ampla e compartilhada
- Não dá para saber quem pediu a operação
- O SQL destrutivo chega direto no PostgreSQL
- Não existe trilha de aprovação
Com o Agents
- Token pessoal de quem acionou o agente
- Classificação por efeito antes da execução
- Pedido mascarado e grant de uso único
- Auditoria no painel, SQL completo no cliente
Agente direto no banco e Agents
| Sem controle | GatekeeperID Agents | |
|---|---|---|
| Credencial | Acesso amplo do banco, compartilhado | Token pessoal de quem acionou |
| Destrutivo | Executa na hora | Bloqueado até aprovação |
| Responsável | Não há como atribuir | Cadeia de aprovadores e auditoria |
| SQL no Cloud | O texto completo viaja | Mascarado; o completo fica no cliente |
| Sem Cloud | Tudo para, ou tudo passa | Leitura por 24h; destrutivo não passa |
Perguntas frequentes
O banco sai da minha rede?+
Não. O Connector fica na sua infraestrutura e inicia a conexão de saída. A senha do PostgreSQL não vai para o Cloud.
O que acontece se o Cloud estiver fora?+
Leitura, e a escrita que a política local já permite, seguem com a política assinada por até 24 horas. Operação destrutiva não executa.
A IA executa o que quiser?+
Ela pode sugerir qualquer coisa. Executar, só o que a política permite ou um humano autorizou. O problema que o Agents resolve é a ausência de identidade, restrição e auditoria.
Preciso de outra conta?+
Não. Quem já administra o Gatekeeper entra com a mesma conta em agents.gatekeeperid.cloud.
O que entra agora?+
PostgreSQL via MCP, com o Cursor como primeiro cliente. O administrador instala o Connector, o desenvolvedor usa o token pessoal, e o aprovador decide no painel.
A mesma conta do Gatekeeper.
Entre no painel para aprovar, emitir o token pessoal e acompanhar a auditoria.
Entrar