macOS Keychain para ferramentas de programação autônomas

macOS Keychain protege bem uma credencial enquanto ninguém a usa. Isso não ou convierte en um limite de segurança completo para uma ferramenta de programação autónoma. Cuando um processo pode recuperar um token de API ou uma chave privada, normalmente também pode copiarlo, imprimirlo, enviarlo a outro sitio ou continuar usándolo quando o operador cree que a tarefa já terminó.

Esta diferencia pesa mais com um agente que com uma aplicativo de mesa convencional. Uma pessoa escolhe um comando de menú e ve o resultado inmediato. Un agente interpreta texto, invoca ferramentas, continua as saídas e pode continuar durante horas. O armazenamento de Keychain responde: « Quién pode ler este segredo ». A execução intermediada responde algo mais difícil: « Pode este processo concreto realizar ahora esta ação concreta sem receber nunca o segredo ». A autenticação de sessão PAM responde outra pergunta relacionada, acerca de quem abrió uma sessão. Confundir estos tres controles deja huecos difíciles de ver en uma demostración e dolorosos de reconstruir tras um incidente.

Keychain protege credenciais almacenadas, não cada uso

Keychain cifra o material segredo almacenado e media o acesso mediante os servicios de segurança de macOS. Es um lugar mucho mejor para um token que um arquivo .env, o historial do shell, um repositorio ou a configuración do agente. Un elemento pode ter controles de acesso e o sistema pode exigir a presencia do usuário antes de entregarlo. Son defensas reales ante o robo casual de arquivos e as lecturas não autorizadas.

O limite termina ao revelar o dato. Si uma ferramenta llama a um auxiliar que devolve um token como texto, o token já existe en o auxiliar, en a caminho IPC e en o processo receptor. Pode aparecer en um mensaje de depuración, um objeto de excepción, uma transcripción, um informe de falha, a memoria de intercambio, um ambiente copiado, um processo filho ou uma solicitação saliente maliciosa. Keychain não pode recuperar esos bytes. Bloquearlo depois tampoco invalida um token portador já copiado en memoria.

A documentación Keychain Services de Apple habla de armazenar e recuperar senhas, chaves e certificados. A formulación importa: recuperar é um resultado admitido. A veces se describe Keychain como si convirtiera cada segredo en uma chave de assinatura não exportable. No é así. Algunas chaves criptográficas podem crearse com controles de acesso e usarse mediante as API de segurança sem exportar su parte privada, mas um token de API común deve acabar en alguna cabecera HTTP. A pergunta de segurança é que componente de confianza construye e envía esa solicitação.

Puedes mostrar o problema com uma conta de teste en vez de um token de producción. Guarda um valor desechable, deja que ou recupere a mesma caminho que usa o agente e examina que pode fazer o processo com os bytes devueltos:

security find-generic-password -a agent-test -s example-api -w

A saída tem o segredo seguido de um salto de línea:

test_token_7f3a...

Si o agente ou um shell sob su control ejecutan a comando com éxito, a capa de armazenamento já tomó su decisão. Ocultar o texto en o terminal apenas cambia ou que ve uma pessoa. No impide que o processo redirija a saída, a codifique ou a incluya en uma solicitação.

Un lector autorizado pode convertirse en exportador

O principal peligroso não suele ser um atacante desconocido. Es a ferramenta a a que permitiste trabalhar. Un processo autônomo necesita acesso amplio a arquivos, ferramentas de compilación, gestores de paquetes e clientes de rede para resultar útil. Si também pode ler credenciais, uma inyección de instruções, uma dependencia comprometida ou uma comando equivocada pode convertir o acesso normal en uma exportación.

Os requisitos de assinatura de código podem limitar que aplicativo accede a um elemento de Keychain. Ayudan quando a amenaza é outro processo sem assinatura ou com uma assinatura distinta. Ayudan mucho menos si a aplicativo aprovada admite extensiones, inicia shells, carga complementos, acepta instruções não fiables do repositorio ou expone um protocolo de ferramentas. O binario assinado pode ser justo o processo que executa o comportamiento influido por o atacante.

También hay um problema de delegación. Un auxiliar de mesa aprovado pode ler um token e pasarlo ao agente por a entrada estándar. Keychain ve ao auxiliar aprovado, não ao consumidor final. Si o auxiliar pone o token en uma variable de ambiente, todos os filhos que hereden ese ambiente podem recibirlo. A decisão de acesso original não expresa que operação posterior se pretendía realizar.

Una revisión útil continua o segredo como dato, não como uma caja de um diagrama. Plantea cuatro perguntas concretas:

• Que processo recebe primeiro o texto sem cifrar
• Pode obtener uma cópia algún filho, complemento, comando de shell ou transcripción
• Pode o receptor escolher destino, método HTTP, caminho ou host SSH
• Que fato termina su autoridade e borra ou não o material já revelado

Muchos equipos responden a primeira e omiten as otras. O diseño parece protegido en reposo, mas se comporta como uma credencial duradera entexto simples en cuanto arranca o agente.

PAM demuestra um inicio de sessão, não a intención do agente

Os módulos PAM permiten que um servicio aplique uma política de autenticação en o limite de inicio de sessão. En macOS, servicios como sudo, login e as caminhos de acesso remoto usan configuraciones PAM com nombre. Uma pila PAM pode autenticar ao usuário, comprobar a conta, establecer credenciais e abrir ou cerrar uma sessão. Sirve para decidir si alguien pode iniciar uma sessão privilegiada do sistema operativo.

PAM não suele mediar cada chamada HTTP de um agente que já está en marcha. Tras autenticarse, o processo actúa com a identidade e as capacidades do sistema operativo que recibió. Si pode ler um token, PAM não vincula o gesto anterior de Touch ID ou a senha com uma única solicitação posterior. Tampoco sabe que POST /releases é mais sensible que GET /status, salvo que outro componente implemente esa distinción de aplicativo.

A palabra «sessão» confunde porque nombra vidas distintas. Uma sessão PAM pode envolver um inicio de sessão ou uma actividad de sudo. Uma sessão de terminal pode persistir en uma ventana. Uma sessão de agente pode significar uma execução, uma conversación ou uma tarefa reanudada. Uma sessão de API pode durar ou mesmo que um token portador. Terminar uma não termina necesariamente as demás.

O falha pode ocurrir así: um operador se autentica para abrir um shell, inicia o agente e aprueba o acesso a Keychain. O agente lee um token de implantação. Horas depois, o operador cierra a conversación visible, mas continua vivo um filho que conserva o token en o ambiente. PAM autenticó correctamente a sessão original e Keychain autorizó bem a leitura. Ninguno impidió o uso posterior porque ninguno controlaba a vida da ação.

Use PAM quando a decisão sea si uma conta do sistema pode establecer uma sessão. No presentes esa autenticação como teste de uma intención humana reciente en cada ação interior. Isso exige a PAM uma semántica que não tem.

Autenticação e autorização responden perguntas distintas

A autenticação establece quem é um principal, ou ao menos que credencial presentó. A autorização decide que pode fazer en um contexto. O armazenamento conserva material hasta uma leitura u operação criptográfica autorizada. Os controles se apoyan, mas não se sustituyen.

Con ferramentas autônomas hay que nombrar ao principal com precisión. «O usuário» é demasiado vago. O operador, o ejecutable assinado do agente, um novo processo, um servidor MCP, um shell filho e a conta remota de API são principales distintos. Si uma aprovação abarca a todos, o diseño deve decirlo.

A unidad práctica para o trabalho rutinario suele ser a execução do processo. O operador autoriza um processo reconocido hasta que sale e toma outra decisão para uma execução nueva. Así um reinicio silencioso não hereda o permiso anterior. Para uma credencial muy sensible, a autorização deve ser aún mais estrecha e pedir aprovação en cada uso.

A aprovação por chamada tampoco é segura por sim sola. Un diálogo que apenas diga « Permitir acesso a a rede » não permite juzgar casi nada. Debe identificar o processo e mostrar os detalles que cambian o risco, como o alias de credencial, método e destino HTTP, ou usuário e host SSH. También deve evitar a fatiga. Si uma leitura inocua interrumpe igual que uma escrita de producción, a gente aprobará ambas sem mirar.

A identidade do processo merece mais que uma caminho ou um nombre visible, pues ambos se copian. En macOS, um requisito de assinatura pode vincular a decisão com a autoridade firmante e o requisito designado, enquanto o credencial distingue uma instancia de outra. Muestra o fato de assinatura que o sistema verificó, não um nombre amable que outro binario pueda imitar.

A assinatura não demuestra buen comportamiento. Establece procedencia según su modelo, não intención. Un agente bem assinado pode obedecer instruções hostiles de um repositorio, e um host assinado pode cargar contenido controlado por um atacante. Aprobar a sessão deve significar «este processo identificado pode pedir ações hasta que salga», não «todas as solicitaçãoes de este programa são seguras».

Define antes cómo se relacionan os descendientes. Confiar automáticamente en todos crea árboles difíciles de revogar e permite que um shell general herede demasiada autoridade. Pedir aprovação para cada auxiliar breve vuelve inútil a automatización. Un diseño limpio mantiene a autorização en a conexión do intermediário que posee o agente aprovado. Os filhos não heredan credenciais e apenas alcanzan ações protegidas por um canal mediado que se revoca com a sessão padre.

A saída do processo é um final automático útil, mas o operador também necesita revogação inmediata. O intermediário deve rechazar ações en cola e futuras, invalidar a sessão e registrar a decisão. Poder detener uma solicitação já transmitida depende do protocolo e do servicio remoto; a interfaz não deve fingir que revogar deshace trabalho completo.

Prueba também os reinicios. Algunos clientes se actualizan, reconectan tras um falha auxiliar ou reanudan uma conversación en outro processo. O código cómodo suele tratarlo como uma mesma sessão lógica. O limite de segurança deve verlo como processo novo salvo que um protocolo de traspaso deliberado e autenticado demuestre continuidad. Un credencial de conversación aportado por o agente não é teste porque pode copiarlo.

O resultado é uma escala de decisões, não um permiso enorme:

1. Está desbloqueado e disponible o armazenamento
2. Pode actuar este novo processo durante su vida
3. Exige esta credencial uma decisão en cada uso
4. Limitará e registrará a operação um executor de confianza

As tres primeras gobiernan autoridade. A cuarta gobierna execução e evidencia. Fundirlas en uma opción vaga de «agente fiable» complica a revogação e a investigación.

A execução intermediada mantiene a credencial fora do agente

Un intermediário cambia «dame o token» por «realiza esta ação definida». O agente aporta parámetros não segredos. O intermediário comprueba a autoridade, recupera a credencial dentro de su limite, a inyecta en o protocolo, executa a operação e devolve apenas o resultado necesario.

Para uma API HTTP, a solicitação podría ser:

{
  "credential": "staging-release-api",
  "method": "POST",
  "url": "https://api.example.invalid/v1/releases",
  "headers": {"content-type": "application/json"},
  "body": {"commit": "8a31c2e", "channel": "candidate"}
}

Tras autorizar, o intermediário añade a cabecera bearer, basic ou personalizada. A resposta visible conserva estado, algunas cabeceras e cuerpo, mas omite a credencial:

{
  "status": 201,
  "headers": {"content-type": "application/json"},
  "body": {"release_id": "rel_1042", "state": "queued"}
}

Es um limite mais claro que a censura. Censurar supone que o segredo entró en uma caminho não fiable e intenta ocultarlo depois. A intermediación evita entregarlo. También faz efectiva a revogação: quando se deniega a siguiente solicitação, o agente não conserva um token com o que eludirla.

Aun así hay que cuidar as saídas. Uma API pode reflejar cabeceras, um comando SSH imprimir o ambiente e um cliente detallado incluir autenticação en um error. Filtra ubicaciones conocidas antes de devolver resultados, limita o diagnóstico e teste os falhas com o mesmo rigor. «O agente nunca recebe credenciais» deve cubrir errores e registros.

SSH continua a mesma idea, com um executor que entienda o protocolo. O agente pide executar um comando sobre uma identidade de host nombrada. O executor usa a chave privada internamente, verifica o host, executa e devolve stdout, stderr e estado. Entregar um arquivo temporal com a chave continua siendo revelarla embora luego se borre.

Un intermediário não evita ações autorizadas dañinas

Ocultar o token elimina muchos falhas, mas não vuelve correcta a ação solicitada. Un DELETE autorizado pode borrar dados sem filtrar credenciais. Un comando SSH pode dañar um host com a chave perfectamente protegida. O intermediário controla cómo se ejerce a autoridade, mas não deduce intención empresarial da sintaxis.

O destino importa. Si o agente escolhe cualquier URL e o intermediário añade a credencial a ciegas, pode enviarla a um host atacante. Un executor HTTP sensato vincula cada credencial com destinos apropiados ou garantiza que apenas inyecta autenticação donde corresponde. Os redireccionamientos requieren o mesmo cuidado. En SSH, comprobar a identidade do host deve formar parte da execução, não ser uma opción do agente.

Os dados de resposta siguen expuestos. Uma credencial segura pode autorizar registros de clientes, configuración de implantação u outro segredo. O agente apenas necesita a resposta mínima, mas uma API genérica dificulta imponerlo. A intermediación reduce a exposición de credenciais; não evita por sim sola a pérdida de dados.

A inyección de instruções tampoco desaparece. O texto do repositorio, comentarios, saídas de compilación e documentación recuperada podem inducir uma ação válida mas não deseada. A aprovação humana ayuda si a tarjeta mostra detalles suficientes e a pessoa lee. Os sistemas de alto risco podem necesitar credenciais remotas mais estrechas, ámbitos en a API, ramas protegidas, ambientes de ensayo, listas de comandos ou um motor de flujo separado.

O consejo popular «pon todos os segredos en Keychain e exige Touch ID» mezcla uma buena decisão de armazenamento com uma decisão de uso demasiado amplia. Touch ID teste presencia ao liberar material, mas não evita que o receptor aprovado ou copie ou use mal. Pide biometría en o limite da ação quando ou merezca e não entregues o token ao agente.

A evidencia de auditoría deve describir ações

Un registro útil dice quem pidió a ação, que instancia ou hizo, que alias eligió, que destino e operação usó, que autorização ocurrió, cuándo se ejecutó e cómo acabó. No contiene a credencial. Uma transcripción de consola rara vez basta: mezcla texto do modelo, mensajes de ferramentas, comandos e saídas truncadas sem um modelo estable.

Separa eventos de sessão e chamadas, conservando su relación. O diário de sesiones mostra cuándo apareció um processo, cómo se identificó, quem ou aprobó, si se revocó e cuándo terminó. O de actividad mostra cada operação HTTP ou SSH e su resultado. Así se responde tanto « se autorizó esta execução » como « que hizo ».

Un registro criptografado protege a confidencialidad en reposo, mas não teste que ninguém borró ou recomandoó entradas. Uma cadeia de hashes enlaza cada entrada com a anterior e permite detectar cambios, ausencias u comando alterado en o texto criptografado. No teste que se registraran todos os hechos ni impide borrar todo o armazenamento. Aporta evidencia sobre a integridad dos registros restantes.

A verificación deve producir um resultado sencillo e automatizable. Sallyport proyecta sus diários Sessions e Activity desde um único registro criptografado, encadeiado por hash e sem leitura de vuelta; o verificador trabaja sem conexión sobre o texto criptografado e sem chave de descriptografado:

sp audit verify

O éxito deve informar da cadeia comprobada e devolver cero; um enlace roto deve señalar falha e devolver outro estado. Incluye a teste en a recopilación de incidentes e en as copias de segurança. Un icono verde mostrado por a mesma aplicativo mutable não é evidencia independiente.

Os registros necesitan um contrato de censura. Guarda alias, não valores. Decide si cuerpos e saídas se guardan, truncan, resumen com hash ou excluyen. Prueba solicitações mal formadas e errores de transporte: os falhas suelen recoger mais contexto bruto.

Evalúa toda a caminho com testes adversarias

Una afirmación arquitectónica apenas cobra sentido quando uma teste intenta romperla. Crea uma credencial e um endpoint desechables, e usa exactamente os binarios e límites do trabalho normal. Uma captura de um diálogo não demuestra que llega a memoria ou sobrevive en descendientes.

Un plan compacto cubre os límites principales:

1. Inicia um agente novo e confirma que não hereda a aprovação anterior. Anota a identidade mostrada.
2. Pide uma leitura de sob risco e depois uma escrita protegida por chamada. Verifique que a tarjeta distingue destino e operação.
3. Busca o segredo e sus codificaciones en stdout, stderr, ambiente, transcripciones, cargas de ferramentas e informes de falha visibles ao agente.
4. Revogue a sessão e reintenta desde o padre e um filho existente. Ambos devem fallar antes de abrir rede ou SSH.
5. Modifica, elimina e recomandoa copias do registro. A verificación sem conexión deve fallar en cada cadeia dañada.

Añade dos abusos omitidos com frecuencia. Haz que o endpoint redirija a outro origen e comprueba que a autenticação não ou continua. Haz que refleje todas as cabeceras e falle com um error detallado; o intermediário deve retirar a credencial antes de responder ao agente.

Para SSH, teste uma chave de host desconocida, uma cambiada, uma solicitação interactiva de senha e uma comando que imprima o ambiente. Confirma quem toma cada decisão. Un auxiliar sem estado não deve crear outro caché ni heredar mais ambiente do necesario.

Os criterios devem ser observables. «Secreto protegido» não se pode probar. «A secuencia e su base64 nunca aparecen en arquivos, ambiente, respostas ni registros visibles» sim. «A revogação funciona» é vago. «Toda chamada do processo revocado e sus filhos falla antes de abrir um socket» se pode medir.

Elige controles según a autoridade do agente

Keychain pode bastar quando uma aplicativo convencional recupera uma credencial de sob impacto, su caminho é estrecha, o usuário inicia cada operação e o modelo acepta revelársela. Sigue siendo uma buena capa dentro de um diseño mais fuerte. No conviene sustituir um armazenamento criptografado maduro por um arquivo casero.

A resposta cambia si a ferramenta escolhe operações, executa código não fiable, crea filhos arbitrarios ou trabaja sem atención continua. Dale capacidades de ação, não bytes segredos. Autentica cada processo nuevo, reserva confirmación por chamada para chaves sensibles, vincula credenciais com protocolos e destinos, e haz que revogar corte de inmediato o uso futuro.

Antes de escolher o desenho, escreva a afirmação mais forte que precisa sustentar. Criptografia em disco exige controle de armazenamento; restringir operações a este processo assinado exige identidade e sessão; chamar uma API sem entregar o token exige um intermediário; detectar alterações nos registros restantes exige evidência de integridade. Cada afirmação tem teste e responsável próprios.

Registre também o risco residual. Um intermediário não desfaz uma gravação remota, uma sessão não remove dados já devolvidos, a assinatura não prova instruções benignas e uma cadeia de hashes não prova que todo o armazenamento foi preservado. Assim a revisão não atribui a um controle trabalhos que ele não executa.

A migração pode ser gradual. Comece por tokens de implantação, chaves de infraestrutura e identidades SSH com acesso a sistemas compartilhados. Troque a interface de leitura por pequenas ações, remova variáveis e auxiliares antigos e mantenha uma credencial de teste até provar que os caminhos antigos falham.

Defina responsáveis por desbloquear, aprovar processos, exigir confirmação por uso, revogar, alternar credenciais e verificar a cadeia. Se o agente agir de modo estranho, revogue primeiro a sessão, preserve e verifique a auditoria e depois altere qualquer credencial que possa ter chegado à memória.

Sallyport aplica este modelo em macOS: os agentes conectan mediante su servidor sp mcp para ações HTTP e SSH, enquanto as chaves permanecen en su bóveda cifrada dentro do processo. Su escala fija tem uma puerta absoluta de bóveda, autorização predeterminada para cada processo novo e aprovação opcional en cada uso de uma chave elegida.

No confundas esto com um motor general de políticas ni com um proxy de interceptación. Un intermediário estrecho pode fazer afirmaciones fuertes sobre custodia porque posee caminhos definidas. Lo que quede fora necesita otros controles, e os servicios remotos devem aplicar ámbitos, separar ambientes e revogar contas.

A pergunta decisiva é concreta: depois de aprobar, pode o processo imprimir, copiar ou reutilizar a credencial por su conta Si puede, Keychain protegió o armazenamento, mas não contuvo o uso. Conserva Keychain para ou que faz bem e mueve o limite de autoridade ao executor que realiza e registra a ação.