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

npm version npm downloads License: MIT GitHub stars

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 zeroAgentes chamam APIs sem nunca ver as chaves
📋 Trilha de auditoria completaCada requisição registrada com timestamp, método, caminho, status
🛡️ Políticas de requisiçãoRegras de permitir/negar por capacidade (ex.: Stripe somente leitura)
⏱️ TTLs de sessãoAcesso com tempo limitado e revogação instantânea
🔌 Funciona com qualquer cliente MCPClaude Desktop, Cursor, OpenClaw e mais
🏠 Local-firstChaves criptografadas na sua máquina, nunca enviadas para a nuvem
🖥️ Modo execExecute ferramentas CLI com credenciais injetadas — agentes nunca veem as chaves
🤖 Autenticação GitHub AppTokens de curta duração para agentes autônomos — sem PATs estáticos
🐦 Twitter/X OAuth 1.0aAssinatura OAuth por requisição — 4 segredos permanecem criptografados
☁️ AWS SigV4Assine requisições de API AWS no servidor — SES, S3 e mais
🔧 Autenticação git automáticagit 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:

  1. Armazene suas chaves de API — criptografadas localmente em ~/.janee/
  2. Execute janee serve — inicia o servidor MCP
  3. Agente solicita acesso — via ferramenta MCP execute
  4. Janee injeta a chave real — o agente nunca a vê
  5. 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:


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íveis
  • janee_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:

FerramentaDescrição
list_servicesDescubra APIs disponíveis e suas políticas
executeFaça uma requisição de API através do Janee (modo proxy HTTP)
execExecute um comando CLI com credenciais injetadas (modo exec)
manage_credentialVeja, conceda ou revogue acesso a credenciais com escopo de agente
reload_configRecarregue 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

TipoDescriçãoExemplo
bearerToken Bearer no cabeçalho AuthorizationStripe, OpenAI, GitHub
basicAutenticação Básica HTTP (usuário + senha)APIs internas
hmac-bybitAssinatura HMAC-SHA256 para BybitExchange Bybit
hmac-okxHMAC-SHA256 + passphrase para OKXExchange OKX
hmac-mexcAssinatura HMAC-SHA256 para MEXCExchange MEXC
headersCabeçalhos personalizados chave-valorAPIs não padronizadas
service-accountChave JSON de conta de serviço GoogleGoogle Cloud
github-appTokens de instalação GitHub de curta duraçãoAPI GitHub
oauth1a-twitterAssinatura OAuth 1.0a por requisiçãoAPI Twitter/X v2
aws-sigv4Assinatura AWS Signature V4 por requisiçãoSES, 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 lista allowedAgents ficam ocultas de todos os agentes
  • defaultAccess: open (padrão) — capacidades sem uma lista allowedAgents ficam disponíveis para todos os agentes
  • allowedAgents — lista por capacidade de nomes de agentes (comparada com clientInfo.name do 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)
  • HOME temporá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_exec localmente
# 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:

  1. Padrões deny são verificados primeiro — negação explícita sempre vence
  2. Depois padrões allow são verificados — devem corresponder para prosseguir
  3. Nenhuma regra definida → permitir tudo (compatível com versões anteriores)
  4. Regras definidas mas sem correspondência → negado por padrão

Formato do padrão: METHOD PATH

  • GET * → qualquer requisição GET
  • POST /v1/charges/* → POST para /v1/charges/ e subcaminhos
  • * /v1/customers → qualquer método para /v1/customers
  • DELETE /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
  1. Agente chama a ferramenta MCP execute com capacidade, método, caminho
  2. Janee consulta a configuração do serviço, descriptografa a chave real
  3. Faz requisição HTTP para a API real com a chave
  4. Registra: timestamp, serviço, método, caminho, status
  5. 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.name no 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 allowedAgents por capacidade + política defaultAccess em todo o servidor
  • Escopo de credenciais: Credenciais criadas pelo agente usam agent-only por 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 revoke ou 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. 🔐