Chaves de serviço e os agentes que as usam
Salve uma chave do catálogo, da sua própria API HTTP ou de um banco de dados, escolha quais agentes a usam, verifique e troque a chave.
Nesta página
O que é uma chave
Uma chave de serviço é o que o Sallyport guarda para um serviço: uma chave de API, um token, um login no provedor ou a senha de um banco de dados. O Sallyport a adiciona ele mesmo a cada chamada. Nenhum agente, pessoa ou API consegue lê-la de volta.
Uma chave salva vai para todos os agentes do espaço de trabalho dela, inclusive os que um proprietário ou administrador criar depois. Um cliente de IA que um membro conecta pelo login começa sem chaves, e um proprietário ou administrador as adiciona na lista “Acesso” dele. Adicionar chaves exige o papel de proprietário ou de administrador.
Escolha a origem
Abra Adicionar chave. “Origem da chave” tem seis opções:
| Origem da chave | Use para |
|---|---|
| Catálogo | Um serviço que o Sallyport conhece, como GitHub, Stripe ou Cloudflare. O endereço e a forma de enviar a chave já estão definidos. |
| API própria | Qualquer API HTTPS pública fora do catálogo. |
| MCP remoto | Um servidor MCP na internet. Veja Clientes MCP e servidores remotos. |
| Host SSH | Um servidor onde seus agentes executam comandos. Veja Comandos SSH. |
| Banco de dados | Seu PostgreSQL, MySQL, SQL Server, ClickHouse, MongoDB ou Redis em um endereço público. Os agentes recebem uma ferramenta para ler e outra para alterar. |
| Armazenamento S3 | Um bucket do Amazon S3, Cloudflare R2, Backblaze B2, Wasabi, DigitalOcean Spaces, Google Cloud Storage ou de qualquer armazenamento compatível com S3. Veja Armazenamento S3. |
| Sua caixa de correio no Gmail, Outlook, Yahoo, iCloud, Fastmail, Zoho ou no seu próprio servidor de e-mail. Os agentes enviam, leem e organizam o correio. Veja E-mail. |
Adicione um serviço do catálogo
Escolha o serviço em “Serviço do catálogo”. “Nome no console” se preenche sozinho, por exemplo github-live. Com vários espaços de trabalho, escolha também o “Espaço de trabalho”.
Deixe “Produção” em “Ambiente”. Agentes criados no console são de produção, e um agente de produção só vê chaves de produção.
Em “Como conectar …”, escolha um caminho. “Entrar com …” leva você ao provedor e traz de volta; o Sallyport guarda o acesso e o renova. “Token de acesso”, “Chave de API” e os outros caminhos recebem uma chave que você cola.
“Criar a chave em …” abre a página do provedor para uma chave nova. Um serviço em um endereço seu também pede “Seu endereço em …”. Clique em “Salvar a chave”, ou no botão de login.
Alguns logins precisam de um aplicativo seu no provedor. O formulário então mostra uma “URI de redirecionamento”: registre-a no aplicativo e cole o “Client ID” e o “Client secret” dele.
Serviços que usam o ID de cliente e o segredo de um app
Greenhouse Harvest v3, apps Server-to-Server do Zoom, aplicações machine-to-machine do Auth0, Bandwidth e a Sinch Conversation API usam o ID de cliente e o segredo de um app que você cria no provedor. Cole os dois; o Sallyport obtém um token de curta duração no endereço que o provedor indica e o renova antes de expirar. O Zoom pede também o ID da conta; o Greenhouse usa o ID do usuário em nome de quem o token age e, sem ele, age como o usuário do próprio app.
PlanetScale e Etsy querem duas partes de uma chave em um único cabeçalho. Digite cada parte em seu próprio campo; o Sallyport as junta em cada chamada.
Serviços que assinam cada requisição
Alguns serviços não aceitam a chave na requisição: cada chamada leva uma assinatura feita com um secret ou uma chave privada. Binance, Bybit, OKX, Kraken, Coinbase, App Store Connect, GitHub Apps, Snowflake com par de chaves, NetSuite e Azure Service Bus funcionam assim. Cole a chave como o formulário pede; o Sallyport assina cada chamada no momento do envio e a chave nunca sai.
| Como conectar | O que o Sallyport faz em cada chamada |
|---|---|
| Chave de API e secret | Adiciona a hora e uma assinatura da requisição feita com o secret, no cabeçalho ou parâmetro de consulta que o serviço indica. |
| Chave privada | Assina com a chave um token de vida curta e o envia como bearer. Para um GitHub App, esse token compra antes um token de instalação. |
| Tokens OAuth 1.0a | Assina a requisição com os secrets do consumer e do token e envia o cabeçalho Authorization: OAuth …. |
Quem aprova uma chamada aprova a requisição em si. A hora e a assinatura entram no envio, depois do sim, então uma aprovação dada minutos antes continua valendo. O agente não as envia; se enviar as próprias, o Sallyport as descarta.
Conecte sua própria API HTTP
Escolha “API própria” e informe a “URL HTTPS do serviço”, por exemplo https://api.example.com:8443/v1. Inclua a porta quando não for a 443. Deixe de fora usuário, parâmetros de consulta e fragmento.
O caminho limita a chave: com /v1, as chamadas só chegam a /v1 e aos caminhos abaixo dele. Escolha a “Autenticação”, informe a chave e clique em “Salvar chave e conectar”.
| Autenticação | O que o Sallyport adiciona a cada chamada |
|---|---|
| Token Bearer | Authorization: Bearer … |
| Basic | O usuário e a senha como Authorization: Basic …. |
| Chave de API | A chave em um “Cabeçalho da solicitação” (X-API-Key, Authorization: token … ou cabeçalhos com o nome que você escolher), um “Parâmetro de consulta”, um campo do “Corpo JSON da solicitação” ou o “Caminho da URL”. |
| Digest | O usuário e a senha respondem ao desafio Digest do serviço. A senha nunca trafega pela rede. |
| Endpoint de login | Um token de sessão. O Sallyport envia o usuário e a senha para a “URL de login”, lê o token da resposta JSON, de um cabeçalho de resposta ou de um cookie e o envia no cabeçalho que você indicar. Ele faz login de novo quando a sessão termina. |
| Certificado de cliente | Nada em um cabeçalho: o Sallyport apresenta o “Certificado” e a “Chave privada”, em PEM, no handshake TLS. |
| OAuth: login | Um token obtido ao entrar no provedor. Você informa a “URL de autorização”, a “URL do token”, os “Escopos” e o ID e o segredo do seu aplicativo. Registre https://mcp.sallyport.cloud/callback/upstream como URI de redirecionamento desse aplicativo. |
| Conta de serviço do Google | Um token do Google que o Sallyport gera com o “JSON da conta de serviço” que você cola, para os “Escopos” que você listar. |
| OAuth: client credentials | Um token que o Sallyport obtém para o seu aplicativo na “URL do token” e renova antes de expirar. A URL do token pode estar em outro host que não o da API, como login.microsoftonline.com no Azure. |
| AWS Signature V4 | Uma assinatura em cada requisição, feita com o seu “ID da chave de acesso” e a sua “Chave de acesso secreta” para a “Região” e o “Serviço de assinatura” que você informar. Para buckets S3, a origem “Armazenamento S3” faz isso por você. |
| Assinatura HMAC | Uma assinatura em cada requisição, feita com o seu “Segredo de assinatura” pelo “Modelo de assinatura” que você cola da documentação do serviço: o algoritmo, o que é assinado e onde vai a assinatura. Uma “Chave de API (opcional)” vai junto no “Cabeçalho da chave de API”. |
| JWT assinado | Um JWT de curta duração que o Sallyport assina com a sua “Chave privada” pelo “Modelo de JWT”: o algoritmo, as claims, a validade e uma troca quando o serviço troca o JWT por um token. |
| OAuth 1.0a | Uma assinatura em cada requisição com o seu “Consumer key”, “Consumer secret”, “ID do token” e “Segredo do token”, com o “Método de assinatura” que você escolhe e um “Realm (opcional)”, como o ID da conta NetSuite. |
“Como a chave será enviada” mostra o que sai em cada chamada. “Opções avançadas da conexão” adiciona cabeçalhos e parâmetros de consulta a todas as chamadas. São configurações, então não coloque chaves ali.
Um serviço que pede um certificado de cliente além da chave o recebe em “Adicionar um certificado de cliente”, selado com a chave. Alguns serviços, como um servidor de API do Kubernetes, usam um certificado que nenhuma autoridade pública assinou. Cole a CA deles em “Certificados de CA confiáveis” dentro de “Opções avançadas da conexão”. Só essa conexão confia nela, e ela continua chegando apenas a endereços públicos.
“O que são as chamadas” distingue uma leitura de uma alteração. “REST” se guia pelo método. “GraphQL” trata uma query como leitura e uma mutation como alteração. “JSON-RPC” trata como leituras os “Métodos de leitura” que você lista e qualquer outro método como alteração. “SQL no corpo” lê a consulta em “Onde está a consulta”, por exemplo /statement no Snowflake: um SELECT é uma leitura, e DROP ou um DELETE sem WHERE é destrutivo.
Escolha quais agentes usam uma chave
A página da chave lista “Agentes que podem usar esta chave”. “Remover” tira a chave de um agente.
Para devolver, abra o agente em Agentes e vá até “Acesso”. “Adicionar conexão” adiciona uma chave, e “Adicionar todas” adiciona todas as chaves do espaço de trabalho.
Cada linha tem “Perguntar sempre” e uma regra para “Leitura”, “Escrita” e “Destrutiva”: “Automático”, “Exige aprovação” ou “Recusado”. Linhas novas executam cada chamada sem perguntar. Veja Aprovações.
Verifique se uma chave funciona
Quando o serviço tem uma verificação, o Sallyport a executa ao salvar a chave. No GitHub, é GET /user. O resultado fica em “Para onde vai esta chave”, na página da chave, e “Verificar de novo” repete a verificação.
Troque uma chave
Crie primeiro uma chave nova no provedor. Na página da chave, clique em “Trocar chave”, informe o novo valor e clique em “Salvar a nova chave”.
A nova versão funciona na hora, e o Sallyport a verifica. A versão anterior continua funcionando por 24 horas para que as chamadas em andamento terminem.
Depois revogue a chave antiga no provedor; “Revogue-a em …” abre a página. Clique em “Já revoguei” para registrar isso. Para renomear uma chave, clique no nome dela no topo da página. “Excluir chave”, no fim, remove a chave e as conexões dela; o diálogo antes nomeia os agentes que as perdem.