Janee API Security
Servidor MCP que fica entre agentes de IA e APIs. Agentes solicitam acesso, Janee faz a chamada com as credenciais reais, agentes nunca veem os segredos.
Documentação
Janee 🔐
Gerenciamento de segredos para agentes de IA via MCP
Seus agentes de IA precisam de acesso a APIs para serem úteis. Mas eles não deveriam ter suas chaves de API brutas. Janee fica entre seus agentes e suas APIs — injetando credenciais, aplicando políticas e registrando tudo.
✨ Recursos
| 🔒 Agentes de conhecimento zero | Agentes chamam APIs sem nunca ver as chaves |
| 📋 Trilha de auditoria completa | Cada requisição registrada com timestamp, método, caminho, status |
| 🛡️ Políticas de requisição | Regras de permitir/negar por capacidade (ex.: Stripe somente leitura) |
| ⏱️ TTLs de sessão | Acesso com tempo limitado e revogação instantânea |
| 🔌 Funciona com qualquer cliente MCP | Claude Desktop, Cursor, OpenClaw e mais |
| 🏠 Local-first | Chaves criptografadas na sua máquina, nunca enviadas para a nuvem |
| 🖥️ Modo exec | Execute ferramentas CLI com credenciais injetadas — agentes nunca veem as chaves |
| 🤖 Autenticação GitHub App | Tokens de curta duração para agentes autônomos — sem PATs estáticos |
| 🐦 Twitter/X OAuth 1.0a | Assinatura OAuth por requisição — 4 segredos permanecem criptografados |
| ☁️ AWS SigV4 | Assine requisições de API AWS no servidor — SES, S3 e mais |
| 🔧 Autenticação git automática | git push/pull funciona automaticamente quando as credenciais incluem tokens GitHub |
O Problema
Agentes de IA precisam de acesso a APIs para serem úteis. A abordagem atual é dar a eles suas chaves e torcer para que se comportem.
- 🔓 Agentes têm acesso total a Stripe, Gmail, bancos de dados
- 📊 Sem trilha de auditoria do que foi acessado ou por quê
- 🚫 Sem interruptor de emergência quando algo dá errado
- 💉 A um prompt injection do desastre
A Solução
Janee é um servidor MCP que gerencia segredos de API para agentes de IA:
- Armazene suas chaves de API — criptografadas localmente em
~/.janee/ - Execute
janee serve— inicia o servidor MCP - Agente solicita acesso — via ferramenta MCP
execute - Janee injeta a chave real — o agente nunca a vê
- Tudo é registrado — trilha de auditoria completa
Suas chaves permanecem na sua máquina. Agentes nunca as veem. Você mantém o controle.
Configure Uma Vez, Use em Todo Lugar
Configure suas APIs no Janee uma vez:
services:
stripe:
baseUrl: https://api.stripe.com
auth: { type: bearer, key: sk_live_xxx }
github:
baseUrl: https://api.github.com
auth: { type: bearer, key: ghp_xxx }
openai:
baseUrl: https://api.openai.com
auth: { type: bearer, key: sk-xxx }
Agora todo agente que se conecta ao Janee pode usá-las:
- Claude Desktop — acesse suas APIs
- Cursor — acesse suas APIs
- OpenClaw — acesse suas APIs
- Qualquer cliente MCP — acesse suas APIs
Chega de copiar chaves entre ferramentas. Chega de "qual agente tem qual API configurada?" Adicionou um novo agente? Ele já tem acesso a tudo. Revogar uma chave? Atualize uma vez no Janee.
Uma configuração. Todo agente. Trilha de auditoria completa.
Início Rápido
Instalação
npm install -g @true-and-useful/janee
Inicialização
janee init
Isso cria ~/.janee/config.yaml com serviços de exemplo.
Adicionar Serviços
Opção 1: Interativo (recomendado para usuários iniciantes)
janee add
Janee vai guiá-lo na adição de um serviço:
Service name: stripe
Base URL: https://api.stripe.com
Auth type: bearer
API key: sk_live_xxx
✓ Added service "stripe"
Create a capability for this service? (Y/n): y
Capability name (default: stripe):
TTL (e.g., 1h, 30m): 1h
Auto-approve? (Y/n): y
✓ Added capability "stripe"
Done! Run 'janee serve' to start.
Usando um agente de IA? Veja Configuração Não-Interativa para flags que pulam prompts, ou os guias específicos por agente abaixo.
Opção 2: Editar configuração diretamente
Edite ~/.janee/config.yaml:
services:
stripe:
baseUrl: https://api.stripe.com
auth:
type: bearer
key: sk_live_xxx
capabilities:
stripe:
service: stripe
ttl: 1h
autoApprove: true
Adicionar ferramentas CLI (modo exec)
Algumas ferramentas precisam de credenciais como variáveis de ambiente, não como cabeçalhos HTTP. O modo exec lida com isso:
janee add twitter --exec \
--key "tvly-xxx" \
--allow-commands "bird,tweet-cli" \
--env-map "TWITTER_API_KEY={{credential}}"
Agora os agentes podem executar ferramentas CLI através do Janee sem nunca ver a chave de API:
// Agent calls janee_exec tool
janee_exec({
capability: "twitter",
command: ["bird", "post", "Hello world!"],
cwd: "/home/agent/project", // optional working directory
reason: "User asked to post a tweet"
})
Janee inicia o processo com TWITTER_API_KEY injetado, executa o comando e retorna stdout/stderr. A credencial nunca entra no contexto do agente.
Flags principais:
--exec— configurar como modo exec (wrapper CLI em vez de proxy HTTP)--allow-commands— lista de permissão de executáveis permitidos (segurança)--env-map— mapear credenciais para variáveis de ambiente--work-dir— diretório de trabalho para o subprocesso--timeout— tempo máximo de execução (padrão: 30s)
Operações Git (autenticação HTTPS automática)
Ao usar o modo exec com credenciais GitHub, Janee lida automaticamente com a autenticação git. Nenhuma configuração extra é necessária — git push, git pull e git clone simplesmente funcionam:
capabilities:
- name: git-ops
service: github
mode: exec
allowCommands: [git]
env:
GH_TOKEN: "{{credential}}"
// Agent can push code without ever seeing the token
janee_exec({
capability: "git-ops",
command: ["git", "push", "origin", "main"],
cwd: "/workspace/my-repo"
})
Janee detecta comandos git com GH_TOKEN/GITHUB_TOKEN no ambiente e cria um script askpass temporário para autenticação HTTPS. O script é limpo automaticamente após a conclusão do comando.
Adicionar autenticação GitHub App (para agentes autônomos)
Tokens estáticos são arriscados para agentes de longa duração. A autenticação GitHub App gera tokens de instalação de curta duração sob demanda — sem PATs de longa duração.
Opção 1: Use create-gh-app (recomendado)
npx @true-and-useful/create-gh-app create my-agent --owner @me
# Opens browser → creates app → saves credentials locally
# Install the app on your repos
# https://github.com/apps/my-agent/installations/new
# Register with Janee in one command
npx @true-and-useful/create-gh-app janee-add my-agent
Pronto. Seu agente agora recebe tokens GitHub de curta duração através do proxy MCP do Janee.
Opção 2: Configuração manual
janee add github-app \
--auth-type github-app \
--app-id 123456 \
--pem-file /path/to/private-key.pem \
--installation-id 789
Ou via configuração:
services:
github:
baseUrl: https://api.github.com
auth:
type: github-app
appId: "123456"
pemFile: /path/to/private-key.pem
installationId: "789"
Como funciona: Quando um agente solicita acesso, Janee assina um JWT com a chave privada do app, troca-o por um token de instalação de 1 hora via API do GitHub e armazena o token em cache até expirar. O agente nunca vê a chave privada — apenas o token de curta duração chega à API.
Iniciar o servidor MCP
janee serve
Usar com seu agente
Agentes que suportam MCP (Claude Desktop, Cursor, OpenClaw) agora podem chamar a ferramenta execute para fazer requisições de API através do Janee:
// Agent calls the execute tool
execute({
capability: "stripe",
method: "GET",
path: "/v1/balance",
reason: "User asked for account balance"
})
Janee descriptografa a chave, faz a requisição, registra tudo e retorna a resposta.
Integrações
Funciona com qualquer agente que fale MCP:
- OpenClaw — Plugin nativo (
@true-and-useful/janee-openclaw)- Agentes em contêineres? Veja Guia de configuração de contêineres
- Cursor — Guia de configuração
- Claude Code — Guia de configuração
- Codex CLI — Guia de configuração
- Qualquer cliente MCP — basta apontar para
janee serve
Integração OpenClaw
Se você está usando OpenClaw, instale o plugin para suporte nativo de ferramentas:
npm install -g @true-and-useful/janee
janee init
# Edit ~/.janee/config.yaml with your services
# Install the OpenClaw plugin
openclaw plugins install @true-and-useful/janee-openclaw
Ative na configuração do seu agente:
{
agents: {
list: [{
id: "main",
tools: { allow: ["janee"] }
}]
}
}
Seu agente agora tem estas ferramentas:
janee_list_services— Descubra APIs disponíveisjanee_execute— Faça requisições de API através do Janee
O plugin inicia janee serve automaticamente. Todas as requisições são registradas em ~/.janee/logs/.
Ferramentas MCP
Janee expõe três ferramentas MCP:
| Ferramenta | Descrição |
|---|---|
list_services | Descubra APIs disponíveis e suas políticas |
execute | Faça uma requisição de API através do Janee (modo proxy HTTP) |
exec | Execute um comando CLI com credenciais injetadas (modo exec) |
manage_credential | Veja, conceda ou revogue acesso a credenciais com escopo de agente |
reload_config | Recarregue a configuração do disco após adicionar/remover serviços (disponível quando iniciado com janee serve) |
Agentes descobrem o que está disponível e então chamam APIs através do Janee. Mesma trilha de auditoria, mesma proteção.
Configuração
A configuração fica em ~/.janee/config.yaml:
server:
host: localhost
services:
stripe:
baseUrl: https://api.stripe.com
auth:
type: bearer
key: sk_live_xxx # encrypted at rest
github:
baseUrl: https://api.github.com
auth:
type: bearer
key: ghp_xxx
capabilities:
stripe:
service: stripe
ttl: 1h
autoApprove: true
stripe_sensitive:
service: stripe
ttl: 5m
requiresReason: true
Serviços = APIs reais com chaves reais
Capacidades = O que os agentes podem solicitar, com políticas
Tipos de autenticação suportados
| Tipo | Descrição | Exemplo |
|---|---|---|
bearer | Token Bearer no cabeçalho Authorization | Stripe, OpenAI, GitHub |
basic | Autenticação Básica HTTP (usuário + senha) | APIs internas |
hmac-bybit | Assinatura HMAC-SHA256 para Bybit | Exchange Bybit |
hmac-okx | HMAC-SHA256 + passphrase para OKX | Exchange OKX |
hmac-mexc | Assinatura HMAC-SHA256 para MEXC | Exchange MEXC |
headers | Cabeçalhos personalizados chave-valor | APIs não padronizadas |
service-account | Chave JSON de conta de serviço Google | Google Cloud |
github-app | Tokens de instalação GitHub de curta duração | API GitHub |
oauth1a-twitter | Assinatura OAuth 1.0a por requisição | API Twitter/X v2 |
aws-sigv4 | Assinatura AWS Signature V4 por requisição | SES, S3 e outros serviços AWS |
Twitter/X OAuth 1.0a
Janee calcula assinaturas OAuth 1.0a (HMAC-SHA1) no servidor, então seus 4 segredos do Twitter permanecem criptografados em repouso e nunca entram no contexto do agente:
services:
twitter:
baseUrl: https://api.x.com
auth:
type: oauth1a-twitter
consumerKey: xxx # encrypted at rest
consumerSecret: xxx # encrypted at rest
accessToken: xxx # encrypted at rest
accessTokenSecret: xxx # encrypted at rest
capabilities:
twitter:
service: twitter
ttl: 1h
autoApprove: true
Ou use o template integrado:
janee add twitter
AWS SigV4
Janee calcula AWS Signature V4 (HMAC-SHA256) por requisição, mantendo suas chaves de acesso criptografadas em repouso. Campos não secretos (region, awsService) permanecem em configuração simples:
services:
aws-ses:
baseUrl: https://email.us-east-1.amazonaws.com
auth:
type: aws-sigv4
accessKeyId: AKIA... # encrypted at rest
secretAccessKey: xxx # encrypted at rest
region: us-east-1
awsService: ses
capabilities:
aws-ses:
service: aws-ses
ttl: 1h
autoApprove: true
Templates integrados para serviços AWS comuns:
janee add aws-ses # Amazon SES
janee add aws-s3 # Amazon S3
Controle de acesso
Controle quais agentes podem usar quais capacidades:
server:
host: localhost
defaultAccess: restricted # capabilities require explicit allowlist
capabilities:
stripe:
service: stripe
ttl: 1h
allowedAgents: ["agent-a", "agent-b"] # only these agents can use it
github:
service: github
ttl: 1h
# no allowedAgents + defaultAccess: restricted → no agent can use this
defaultAccess: restricted— capacidades sem uma listaallowedAgentsficam ocultas de todos os agentesdefaultAccess: open(padrão) — capacidades sem uma listaallowedAgentsficam disponíveis para todos os agentesallowedAgents— lista por capacidade de nomes de agentes (comparada comclientInfo.namedo handshake de inicialização MCP)
Credenciais criadas por agentes em tempo de execução têm como padrão acesso agent-only — apenas o agente criador pode usá-las, a menos que conceda acesso explicitamente via ferramenta manage_credential.
Capacidades de modo exec
services:
twitter:
auth:
type: bearer
key: tvly-xxx
capabilities:
twitter:
service: twitter
mode: exec
allowCommands: ["bird", "tweet-cli"]
envMap:
TWITTER_API_KEY: "{{credential}}"
ttl: 1h
autoApprove: true
Capacidades de modo exec usam janee_exec em vez de execute. A credencial é injetada como variável de ambiente — o agente vê apenas stdout/stderr.
Padrões de endurecimento do runner no modo exec:
- ambiente mínimo isolado (sem herança completa do ambiente do host)
HOMEtemporário por comando- timeout mata o grupo de processos
Modo Runner/Authority (para contêineres)
Quando agentes rodam dentro de contêineres Docker, janee_exec em um host remoto não pode acessar o sistema de arquivos do contêiner. A arquitetura Runner/Authority resolve isso:
- Authority roda no host: mantém credenciais, aplica políticas, faz proxy de requisições de API
- Runner roda dentro de cada contêiner: serve MCP para o agente, encaminha chamadas não-exec para o Authority, executa
janee_execlocalmente
# Host: start Authority (MCP + exec authorization on one port)
janee serve -t http -p 3100 --host 0.0.0.0 --runner-key "$JANEE_RUNNER_KEY"
# Container: start Runner (agent talks to this)
janee serve -t http -p 3200 --host 127.0.0.1 \
--authority http://host.docker.internal:3100 --runner-key "$JANEE_RUNNER_KEY"
O agente só precisa de JANEE_URL=http://localhost:3200.
Você também pode executar o Authority como um processo independente:
janee authority --runner-key "$JANEE_RUNNER_KEY" --host 127.0.0.1 --port 9120
Veja o Guia Runner/Authority para a arquitetura completa, fluxo de autorização exec, exemplo Docker Compose e solução de problemas.
Políticas de Requisição
Controle exatamente quais requisições cada capacidade pode fazer usando rules:
capabilities:
stripe_readonly:
service: stripe
ttl: 1h
rules:
allow:
- GET *
deny:
- POST *
- PUT *
- DELETE *
stripe_billing:
service: stripe
ttl: 15m
requiresReason: true
rules:
allow:
- GET *
- POST /v1/refunds/*
- POST /v1/invoices/*
deny:
- POST /v1/charges/* # Can't charge cards
- DELETE *
Como as regras funcionam:
- Padrões
denysão verificados primeiro — negação explícita sempre vence - Depois padrões
allowsão verificados — devem corresponder para prosseguir - Nenhuma regra definida → permitir tudo (compatível com versões anteriores)
- Regras definidas mas sem correspondência → negado por padrão
Formato do padrão: METHOD PATH
GET *→ qualquer requisição GETPOST /v1/charges/*→ POST para /v1/charges/ e subcaminhos* /v1/customers→ qualquer método para /v1/customersDELETE /v1/customers/*→ DELETE qualquer cliente
Isso torna a segurança real: Mesmo que um agente minta sobre seu "motivo", ele só pode acessar os endpoints que a política permite. A aplicação acontece no servidor.
Referência CLI
janee init # Set up ~/.janee/ with example config
janee add # Add a service (interactive)
janee add stripe -u https://api.stripe.com -k sk_xxx # Add with args
janee remove <service> # Remove a service
janee remove <service> --yes # Remove without confirmation
janee list # List configured services
janee list --json # Output as JSON (for integrations)
janee search [query] # Search service directory
janee search stripe --json # Search with JSON output
janee cap list # List capabilities
janee cap list --json # List capabilities as JSON
janee cap add <name> --service <service> # Add capability
janee cap edit <name> # Edit capability
janee cap remove <name> # Remove capability
janee serve # Start MCP server (stdio, default)
janee serve --transport http --port 9100 # Start with HTTP transport (for containers)
janee serve --authority https://janee.example.com --runner-key $JANEE_RUNNER_KEY # Runner mode
janee authority --runner-key $JANEE_RUNNER_KEY # Start authority API
janee logs # View audit log
janee logs -f # Tail audit log
janee logs --json # Output as JSON
janee sessions # List active sessions
janee sessions --json # Output as JSON
janee revoke <id> # Kill a session
Configuração Não-Interativa (para agentes de IA)
Agentes de IA não podem responder a prompts interativos. Use flags --*-from-env para ler credenciais de variáveis de ambiente — isso mantém segredos fora da janela de contexto do agente:
# Bearer auth (Stripe, OpenAI, etc.)
janee add stripe -u https://api.stripe.com --auth-type bearer --key-from-env STRIPE_KEY
# HMAC auth (Bybit)
janee add bybit --auth-type hmac-bybit --key-from-env BYBIT_KEY --secret-from-env BYBIT_SECRET
# HMAC auth with passphrase (OKX)
janee add okx --auth-type hmac-okx --key-from-env OKX_KEY --secret-from-env OKX_SECRET --passphrase-from-env OKX_PASS
# GitHub App auth (short-lived tokens)
janee add github --auth-type github-app --app-id-from-env GH_APP_ID --pem-from-env GH_PEM --installation-id-from-env GH_INSTALL_ID
# Twitter/X OAuth 1.0a (per-request signing)
janee add twitter --consumer-key $TWITTER_CONSUMER_KEY --consumer-secret $TWITTER_CONSUMER_SECRET \
--access-token $TWITTER_ACCESS_TOKEN --access-token-secret $TWITTER_ACCESS_TOKEN_SECRET
# AWS SigV4 (SES, S3, etc.)
janee add aws-ses --access-key-id $AWS_ACCESS_KEY_ID --secret-access-key $AWS_SECRET_ACCESS_KEY \
--region us-east-1 --aws-service ses
Quando todas as credenciais necessárias são fornecidas via flags, Janee:
- Nunca abre readline (sem travamento no stdin)
- Cria automaticamente uma capacidade com padrões sensatos (TTL de 1h, aprovação automática)
Você também pode editar ~/.janee/config.yaml diretamente se preferir.
Como Funciona
┌─────────────┐ ┌──────────┐ ┌─────────┐
│ AI Agent │─────▶│ Janee │─────▶│ Stripe │
│ │ MCP │ MCP │ HTTP │ API │
└─────────────┘ └──────────┘ └─────────┘
│ │
No key Injects key
+ logs request
- Agente chama a ferramenta MCP
executecom capacidade, método, caminho - Janee consulta a configuração do serviço, descriptografa a chave real
- Faz requisição HTTP para a API real com a chave
- Registra: timestamp, serviço, método, caminho, status
- Retorna a resposta para o agente
O agente nunca toca na chave real.
📐 Aprofundamento: Veja Arquitetura & Modelo de Segurança para diagramas detalhados, modelo de ameaças e comparação com alternativas.
Segurança
- Criptografia: Chaves armazenadas com AES-256-GCM
- Identidade do agente: Derivada de
clientInfo.nameno handshake de inicialização do MCP — nenhum cabeçalho personalizado necessário - Isolamento do agente: Cada agente recebe sua própria sessão com identidade isolada (o transporte HTTP cria um Server+Transport por sessão)
- Controle de acesso: Lista de permissões
allowedAgentspor capacidade + políticadefaultAccessem todo o servidor - Escopo de credenciais: Credenciais criadas pelo agente usam
agent-onlypor padrão - Log de auditoria: Cada solicitação registrada em
~/.janee/logs/ - Sessões: Com limite de tempo e revogáveis
- Interruptor de emergência:
janee revokeou excluir a configuração
Docker
Execute o Janee como um contêiner — sem necessidade de Node.js local:
# Build
docker build -t janee .
# Run in HTTP mode
docker run -d -p 3000:3000 \
-v ~/.janee:/root/.janee:ro \
janee --transport http --port 3000 --host 0.0.0.0
Ou use Docker Compose:
mkdir -p config && cp ~/.janee/config.yaml config/
docker compose up -d
Para Claude Desktop com Docker, consulte a documentação do Docker.
Contribuindo
Aceitamos contribuições! Leia CONTRIBUTING.md antes de enviar um PR — inclui a lista de verificação obrigatória para PRs (testes, changelog, incremento de versão, etc.).
Licença
MIT — Criado pela True and Useful LLC
Pare de dar suas chaves a agentes de IA. Comece a controlar o acesso. 🔐