Seguridad sin claims
que no podamos defender.
Este documento lista cada control de seguridad de AxOS, su estado real y la evidencia que lo respalda. También lista lo que NO tenemos hoy — porque mentir sobre seguridad a una empresa legal o clínica genera daño real cuando lo descubren.
La fuente de verdad es el código del repo, no este texto. Si eres auditor o head de IT del cliente, pide acceso read-only y verificá. AxOS es agencia boutique — el founder responde directo.
01 · Aislamiento de datos entre clientes
verificableCada tabla en Postgres con columna tenant_id tiene Row-Level Security habilitado y una policy que niega queries cross-tenant. La policy lee current_setting('axos.tenant_id'), que se setea desde el JWT del request — nunca desde el body — vía el helper withTenant(tenantId, fn) en cada transacción.
Para tenants con datos especialmente sensibles (clínicas, estudios jurídicos con archivo confidencial), provisionamos la instancia en un Neon project físicamente separado. No es solo RLS lógico — es base de datos distinta, credenciales distintas, posible región distinta si se requiere.
- Migrations:
core/db/migrations/0002_enable_rls.sqlhabilita RLS en 18+ tablas críticas - Helper:
core/db/client.tsejecutaSET LOCAL axos.tenant_iden cada transacción - ADR-009 (Data Studio): Neon project separado para tenants data-heavy
02 · Autenticación
verificableAuth manejado por Clerk (provider US-based, certificado SOC 2 Type II). Sesiones HttpOnly cookies con expiry de 8 horas. Passwords bcrypt si se usa email/password, OAuth si se usa Google/Microsoft.
2FA disponible y obligatorio en onboarding para clientes con compliance requirements. Si tu equipo lo necesita, lo activamos desde el primer día.
Rate limiting en login: 8 intentos por 60 segundos por IP, luego bloqueo de 15 minutos.
core/auth/session.ts: integración Clerkcore/auth/rate-limit.ts: sliding window 8/60s- Clerk SOC 2 Type II: clerk.com/trust
03 · Encriptación
verificableAt rest: Postgres Neon encripta toda la base con AES-256 por default. Embeddings, mensajes, audit logs — todo encriptado.
In transit: TLS 1.3 forzado por Vercel. Header HSTS activo con max-age=63072000 (dos años), includeSubDomains y preload para registro en HSTS preload list.
- Neon encryption: neon.com/docs/security
- HSTS header:
next.config.ts, verificable concurl -I
04 · Audit logging
verificableTres tablas de auditoría:
auth_audit: cada login, logout, password change. IP + user agent + tenant_id.audit_log: acciones del agente (queries, outputs aprobados, configs modificados). Incluye lineage de cada query a sus source tables.share_link_views: cada vez que alguien abre un link compartido. IP + referrer + viewed_at.
Los logs son exportables. Si tu compliance auditor pide registros, los entregamos en CSV con tenant scope.
05 · Secrets per-tenant
verificableCada tenant tiene secrets propios en variables de entorno separadas (JWT_SECRET_HUX, JWT_SECRET_BYVA, etc.). Comprometer el secret de un cliente no abre los datos de otro.
API keys de model providers (Anthropic, Cohere) son globales de AxOS — el aislamiento de prompts entre clientes ocurre en código, no en API key.
06 · Residencia de datos
parcialPostgres y Vercel Functions: São Paulo (sa-east-1 y gru1 respectivamente).
Auth (Clerk): US-based. Si tu compliance exige residencia LATAM total, hablamos — podemos evaluar self-hosted auth para tu instancia (costo adicional).
Trigger.dev workflows: cloud global. Logs de ejecución pueden vivir en US. Los datos del cliente NO pasan por Trigger.dev — solo metadata de las tasks (estado, timestamp, ID).
07 · No-training con LLM providers
parcialPor default no está garantizado. Anthropic y Cohere pueden usar los prompts para training según los términos de su API estándar. Para clientes con datos sensibles, contratamos plan Enterprise con Zero Data Retention activado.
En el onboarding te confirmamos el plan vigente con cada provider. Si la tarea lo amerita, activamos ZDR antes del go-live.
08 · Lo que NO tenemos hoy
roadmapLista honesta de gaps. Si alguno bloquea tu compliance, menciónalo en la primera llamada — no firmamos un contrato sabiendo que vamos a fallar.
- SOC 2 propio. Apoyamos en SOC 2 de Vercel, Neon y Clerk underlying — pero AxOS no tiene certificación propia. Roadmap: evaluar en 2027 si la demanda lo pide.
- Pentest formal. No ejecutado todavía. Roadmap Q3 2026 antes de buscar clientes en sectores regulados.
- Bug bounty program. No tenemos.
- WAF dedicado. Usamos el default de Vercel. Suficiente para mayoría de tráfico pero no es WAF enterprise.
- Golden test cross-tenant en CI. La RLS está implementada y verificada manualmente. El test automatizado que valida aislamiento cada commit está en backlog F1.T16.
- Política de borrado formal (derecho GDPR). Técnicamente podemos borrar a pedido, pero no hay política escrita ni SLA. Se documenta por cliente cuando aplica.
09 · Modelo boutique como control de seguridad
La mejor seguridad operacional que ofrezco es estructural: AxOS es operada por una sola persona. No subcontratamos developers ni DBAs. El único humano con acceso a tu instancia, tus secrets y tu base soy yo.
Esto tiene un upside (auditabilidad humana absoluta) y un downside (single point of failure operacional). Lo segundo lo mitigamos con backup automático de Neon (7 días) y procedimiento de continuidad documentado por cliente.
¿Quieres validar tú mismo?
Si eres head de IT, compliance officer o auditor del cliente prospect, te doy acceso read-only al repo de AxOS y te paso por cada control. Cero NDA inicial necesario para revisar la arquitectura — la transparencia es parte del modelo.