Acceso y secretos

El problema

Los workflows de IA dependen de múltiples API keys — proveedores de modelos, servicios de transcripción, almacenamiento en la nube, control de versiones. Hardcodearlas es un riesgo de seguridad. Filtrar una sola key puede comprometer todo tu setup.

El verdadero desafío no es simplemente "no pongas keys en el código." Es gestionar keys a través de diferentes contextos: tu shell, servicios en segundo plano, cron jobs y aplicaciones web — cada uno con reglas distintas de alcance de entorno.

Un stack típico de workflow de IA

Un setup personal de IA puede usar 4-6 servicios, cada uno requiriendo credenciales separadas:

Cada servicio necesita su propia key, almacenada de forma segura y accesible desde el contexto de ejecución correcto.

Variables de entorno: lo básico

El approach más simple son las variables de entorno. Sin secretos en archivos que se commitean. Sin valores hardcodeados.

Para shells interactivos

Agregá keys a tu perfil de shell (ej: ~/.bashrc o ~/.zshrc):

export MY_SERVICE_API_KEY="your-key-here"
export ANOTHER_SERVICE_KEY="your-key-here"

Recargá con source ~/.bashrc.

Limitación: Esto solo funciona cuando vos estás logueado. Los servicios en segundo plano y los cron jobs no cargan tu perfil de shell.

Para servicios systemd

Si tu agente de IA corre como servicio systemd, el servicio necesita su propio entorno:

[Service]
Environment="MY_SERVICE_API_KEY=your-key-here"

O usá un EnvironmentFile para una separación más limpia:

[Service]
EnvironmentFile=/etc/your-service/env

Donde el archivo env contiene tus keys, una por línea.

Importante: Establecé permisos restrictivos en el archivo env:

sudo chmod 600 /etc/your-service/env
sudo chown root:root /etc/your-service/env

Después de cambios, recargá systemd:

sudo systemctl daemon-reload
sudo systemctl restart your-service

Experimento: el problema de alcance de entorno

Al configurar un workflow de IA con un servicio de transcripción por primera vez, un error común sale a la luz: la API key funciona en tu shell interactivo pero falla cuando se llama desde un servicio en segundo plano.

Qué pasa:

1. Agregás la API key a ~/.bashrc ✅
2. Corrés el servicio manualmente — funciona ✅
3. El agente en segundo plano intenta llamar al mismo servicio — 401 Unauthorized ❌

Causa raíz: Los servicios systemd no heredan el entorno del shell del usuario. Corren en un contexto de proceso aislado.

Solución: Agregá la key tanto a tu perfil de shell (para uso manual) COMO al entorno del servicio systemd. Después de daemon-reload y restart, el servicio funciona desde ambos contextos.

Lección aprendida: Siempre testeá tus keys desde el mismo contexto en el que realmente van a correr. Una key que funciona en tu terminal puede no existir en el entorno de tu servicio. Este es uno de los errores más comunes en infraestructura personal de IA.

Autenticación basada en OAuth

No todo usa API keys. Algunos servicios usan flujos OAuth que requieren autenticación basada en navegador.

CLIs de control de versiones (como gh de GitHub) típicamente usan un flujo OAuth en el navegador y almacenan el token localmente. El CLI maneja el refresh del token automáticamente.

Herramientas de sync de almacenamiento en la nube (como rclone) te guían a través de un flujo OAuth2 y almacenan los tokens de refresh en un archivo de configuración local. Estos tokens otorgan acceso continuo sin re-autenticación.

Buenas prácticas para credenciales OAuth:

• Establecé permisos restrictivos en cualquier archivo de configuración que almacene tokens (chmod 600)
• Limitá el acceso al mínimo necesario (ej: restringir el acceso al almacenamiento en la nube a una sola carpeta en vez de dar acceso completo al drive)
• El alcance de acceso es a veces una decisión de política que se aplica por disciplina, no una restricción técnica. Documentá tus límites.

Qué NO hacer

• Nunca commitees keys a git. Auditá todos los repos antes de hacerlos públicos. Buscá patrones comunes: grep -rn "API_KEY\|SECRET\|TOKEN" .
• Nunca pongas keys en scripts. Los scripts deben leer de variables de entorno, no contener keys directamente.
• Nunca compartas keys entre servicios innecesariamente. Cada servicio recibe solo las keys que necesita.
• Nunca uses la misma key para dev y producción. Entornos separados limitan el radio de impacto.

Dónde mejorar a partir de acá

Áreas comunes donde los setups personales de IA pueden subir de nivel en gestión de secretos:

• Rotación de keys. Rotar API keys y tokens con un calendario (mensual o trimestral) limita el radio de impacto si una key se expone.
• Gestores de secretos dedicados. HashiCorp Vault, AWS Secrets Manager, o incluso archivos env encriptados ofrecen mejor protección que variables de entorno en texto plano. Para setups de una sola máquina, los archivos env son pragmáticos; para algo más grande, un gestor de secretos se paga solo.
• Separación de entornos. Usar keys diferentes para desarrollo y producción evita que un error de dev comprometa el acceso de producción.
• Registros de auditoría. Logear qué key se usó y cuándo ayuda a detectar acceso no autorizado. La mayoría de los proveedores de API ofrecen dashboards de uso — revisalos periódicamente.

Checklist

Antes de agregar un nuevo servicio a tu workflow de IA:

1. ☐ Generá una API key dedicada (no reutilices entre servicios)
2. ☐ Agregala a tu perfil de shell para uso interactivo
3. ☐ Agregala al entorno del servicio systemd si corre como daemon
4. ☐ Testeá desde el contexto de ejecución real (shell, servicio, cron)
5. ☐ Establecé permisos restrictivos en archivos de credenciales (600)
6. ☐ Verificá que las credenciales NO estén en ningún archivo commiteado
7. ☐ Documentá para qué es cada key en un archivo de referencia privado

Fuentes

• Directivas de entorno de systemd — docs oficiales sobre variables de entorno de servicios
• 12-Factor App: Config — principios de configuración basada en entorno