Memgate

Controle de acesso, resolução de conflitos e auditoria para memória de agente compartilhada.

Documentação

Memgate

Controle de acesso, resolução de conflitos e auditoria para memória compartilhada de agentes.

O Memgate fica à frente da memória que seus agentes de IA compartilham. Ele decide quem pode ler e escrever o quê, resolve gravações conflitantes e registra cada operação — para que a memória de um sistema multiagente permaneça confiável à medida que cresce.

Ele fala MCP, então os agentes se conectam com uma entrada de configuração e sem alterações de código.

Status: em fase inicial, mas funcional. O núcleo (política, tratamento de conflitos, auditoria, ferramentas MCP) roda e é testado de ponta a ponta com agentes reais. Adaptadores para backends de memória externos e um painel hospedado estão no roadmap, ainda não construídos. Feedback e problemas são bem-vindos.

Demo

O problema

A memória de um único agente é fácil: manter a conversa no contexto, pronto. Mas quando vários agentes compartilham um mesmo pool de memória — um lidando com suporte, outro escrevendo código, outro fazendo cobrança — esse pool se degrada:

Gravações conflitantes. Um agente registra "cliente está feliz", outro registra "cliente está irritado". Ninguém sabe qual é a atual.
Sem limites de acesso. O agente de cobrança pode ler PII do cliente; o agente de suporte pode sobrescrever registros financeiros. Nada impede isso.
Sem responsabilização. Quando algo dá errado, não há registro de qual agente escreveu o quê, ou quando.

Armazenamentos de memória como pgvector, Mem0 ou Zep guardam memória bem. Eles não governam ela. O Memgate é a camada de governança que fica por cima.

A ideia

Pense na memória compartilhada como um livro-razão, e o Memgate como o porteiro que fica na frente dele. Os agentes nunca tocam o livro-razão diretamente — cada requisição passa pelo portão, que faz três coisas:

Política — verifica se o papel deste agente pode ler ou escrever neste namespace. O padrão é negar.
Resolução de conflitos — quando um registro já existe para uma entidade, aplica a estratégia do namespace (last-write-wins, versioned, ou require-review) em vez de sobrescrevê-lo silenciosamente.
Auditoria — anexa cada operação, permitida ou negada, a um log somente de anexação.

A identidade está vinculada à chave de API, não a qualquer coisa que o agente diga. Um agente não pode elevar seus próprios privilégios alegando um papel diferente.

Como funciona

Agent A ─┐
Agent B ─┼── MCP ──▶ [ Memgate ] ──▶ Postgres + pgvector
Agent C ─┘             policy · conflict · audit

Os agentes chamam três ferramentas via MCP:

Ferramenta	O que faz
`memory_write(namespace, entity_key, content)`	Verificação de política → resolução de conflitos → gravação → auditoria
`memory_read(namespace, entity_key)`	Verificação de política → retorna o registro ativo → auditoria
`memory_search(namespace, query)`	Verificação de política → busca semântica nos namespaces autorizados → auditoria

Início rápido

Requer Docker.

git clone https://github.com/denizayhan04/memgate
cd memgate
docker compose up --build

Isso inicia o Postgres (com pgvector), executa migrações e serve o endpoint MCP em :8088.

Crie um agente e obtenha sua chave de API:

docker compose exec memgate memgate agent create --name support-bot --role support
# → API key (shown once): mg_live_...

Conecte um cliente MCP (Claude Code, Cursor, ou qualquer coisa que fale MCP). Adicione ao .mcp.json do seu projeto:

{
  "mcpServers": {
    "memgate": {
      "type": "http",
      "url": "http://localhost:8088/mcp",
      "headers": { "Authorization": "Bearer mg_live_YOUR_KEY" }
    }
  }
}

Agora o agente tem as ferramentas memory_write, memory_read, e memory_search, com escopo limitado ao que seu papel permite.

Inspecione o que aconteceu:

docker compose exec memgate memgate audit --entity "customer:acme"

ID  AT                    AGENT         ACTION  NAMESPACE      ENTITY_KEY     RESULT
14  2026-07-08T15:43:30Z  test-eng      write   customer-data  customer:acme  denied
13  2026-07-08T15:43:14Z  test-eng      read    customer-data  customer:acme  allowed
12  2026-07-08T15:41:05Z  test-support  read    customer-data  customer:acme  allowed
11  2026-07-08T15:41:02Z  test-support  write   customer-data  customer:acme  allowed

Dois agentes, um registro compartilhado, permissões diferentes — o agente de suporte escreve e lê; o engenheiro lê, mas não pode escrever. Cada tentativa, permitida ou negada, fica registrada.

Políticas

As políticas vivem em um arquivo YAML (config/policies.example.yaml por padrão), não no banco de dados — para que sejam versionadas no git e revisadas como qualquer outra configuração. A regra é negação por padrão: qualquer coisa não explicitamente concedida está fechada.

namespaces:
  customer-data:
    conflict_strategy: versioned        # old record superseded, new active; history queryable
  tech-context:
    conflict_strategy: last-write-wins  # new record overwrites old
  billing:
    conflict_strategy: require-review   # write parked as pending until a human approves

roles:
  support:
    customer-data: [read, write]
    tech-context:  [read]
  engineer:
    tech-context:  [read, write]
    customer-data: [read]
  finance-bot:
    billing:       [read, write]
    customer-data: [read]
  auditor:
    "*":           [read]

O servidor em execução recarrega o arquivo de política sem reiniciar, em SIGHUP ou via memgate reload.

Estratégias de conflito

Quando uma gravação tem como alvo uma entidade que já possui um registro ativo:

last-write-wins — o novo registro se torna ativo, o antigo é marcado como substituído.
versioned — o mesmo, mas o histórico é preservado e consultável (o que sabíamos e quando).
require-review — a nova gravação é estacionada como pending_review; o registro existente permanece ativo até que um humano o aprove.

Revisando gravações estacionadas:

memgate review list              # list memories awaiting review
memgate review approve <id>      # make a pending memory active
memgate review reject <id>       # reject it

CLI

memgate serve                            Start the MCP (Streamable HTTP) server
memgate migrate                          Apply SQL migrations
memgate agent create --name N --role R   Create an agent and print its API key
memgate review list                      List memories awaiting review
memgate review approve <id>              Approve a pending memory
memgate review reject <id>               Reject a pending memory
memgate reload                           Reload the policy YAML in a running server
memgate audit [--entity K] [--namespace N] [--agent A] [--limit N]
                                         Show audit log, most recent first

Ambiente

Variável	Finalidade
`MEMGATE_DATABASE_URL`	DSN do Postgres (obrigatório)
`MEMGATE_POLICY_FILE`	Caminho do YAML de política (padrão `config/policies.example.yaml`)
`MEMGATE_LISTEN_ADDR`	Endereço de escuta para `serve` (padrão `:8080`)
`MEMGATE_MIGRATIONS_DIR`	Diretório de migrações (padrão `migrations`)
`MEMGATE_PID_FILE`	Arquivo PID escrito por `serve`, lido por `reload`
`MEMGATE_OPENAI_API_KEY`	Opcional. Defina para embeddings reais; se não definido, usa um embedder offline determinístico, para que a busca funcione sem chave.

Desenvolvimento local

make build      # compile to bin/memgate
make test       # run tests
make migrate    # apply migrations (needs MEMGATE_DATABASE_URL)
make run        # run the MCP server locally
make up         # docker compose up --build
make down       # stop and remove services

Executando a partir do código-fonte sem Docker:

export MEMGATE_DATABASE_URL="postgres://memgate:memgate@localhost:5432/memgate?sslmode=disable"
go run ./cmd/memgate agent create --name support-bot --role support

Notas de design

Agnóstico de backend por design. O armazenamento de memória está atrás de uma interface. Hoje a única implementação é Postgres + pgvector; adaptadores para armazenamentos externos (Mem0, Zep) podem ser adicionados sem tocar nas camadas de política, conflito ou auditoria.
A identidade é a chave, não a alegação. O papel de um agente é resolvido a partir de sua chave de API em cada requisição. O que o agente diz sobre seu papel é irrelevante — não há como auto-elevar privilégios.
A auditoria é somente de anexação. O log de auditoria rejeita atualizações e exclusões no nível do banco de dados, não apenas no código da aplicação.

Roadmap

Adaptadores de backend (Mem0, Zep)
Endpoints REST junto com MCP, para clientes que não falam MCP
Um painel de auditoria somente leitura
Gerenciamento de políticas de equipe e SSO (hospedado)

Tecnologia

Go · Postgres + pgvector · mark3labs/mcp-go · transporte HTTP MCP Streamable.

Licença

Apache 2.0. Veja LICENSE.