Security Overview
This overview describes the security controls implemented in the Routero AI service ("Service") in the operator's reference deployment.
It is a description of current state, not a binding commitment. We update it as the Service evolves.
1. Hosting and network
Hosting: AWS, region ap-southeast-1 (Singapore).
Compute: AWS ECS Fargate. Tasks run in private subnets across multiple Availability Zones.
Network ingress: Only the Application Load Balancer is public. The proxy and the background worker run in private subnets and have no direct public IP.
TLS: Terminated at the ALB using AWS Certificate Manager certificates. HTTP traffic is redirected to HTTPS.
Outbound: Tasks reach upstream LLM provider APIs and AWS services through NAT gateways from private subnets.
DNS: Per-environment subdomains (platform.routero.ai, platform-uat.routero.ai, platform-sandbox.routero.ai) hosted in AWS Route 53. The apex domain routero.ai is hosted at Cloudflare (DNS-only, no proxying).
2. Authentication & access
Service API: API-key authentication. Keys are issued from the management UI/API. Each key has an alias, scoped models, scoped budgets, and scoped rate limits.
Key storage: API keys are stored hashed (one-way) in PostgreSQL (LiteLLM_VerificationToken.token). Plaintext keys are never recoverable from the database.
Provider API keys (the keys used by the proxy to call upstream providers) are stored encrypted at rest in LiteLLM_ProviderKeyTable.api_key. The encryption mechanism is [TBD: KMS / master-key derivation — counsel/operator to confirm and document].
Admin SSO: Supports Google, Microsoft, Okta, and generic OIDC providers. Configured per-deployment.
Roles: Admin, internal-user, end-user roles are enforced at the management API.
Multi-tenant isolation: Every tenant-scoped resource (keys, models, spend logs, audit logs, agents) carries an organization_id foreign key. Queries filter by organization scope at the API and DB-query level.
Operator access (ECS Exec): Engineers may shell into a running container via AWS SSM (ECS Exec) for debugging. The connection is opened over AWS SSM (no inbound port, no SSH). Every session is recorded in CloudTrail. There is no bastion host and no SSH server in the image.
3. Data at rest
Database (Amazon RDS PostgreSQL): Storage encrypted using AWS-managed keys. Single-AZ during beta; Multi-AZ at GA. Daily automated backups; retention is environment-specific (current: 7 days production, 1 day UAT, 0 days sandbox). Backups are encrypted at the same level as the primary store.
Cache (Amazon ElastiCache Redis): Single-node during beta. Caches authentication lookups, rate-limit counters, and the spend-update transaction buffer. LLM-response caching is disabled by default in current deployments (CACHE_LLM=false) but the cache subsystem is initialized.
Object storage: No Customer Content is stored in S3. S3 is used only for Terraform state (in a separate, IAM-restricted bucket with object-level encryption and versioning).
Container logs: AWS CloudWatch Logs, retention varies by environment; encryption at rest is AWS-managed.
Email: AWS SES, transactional only; noreply@routero.ai sender identity, DKIM-signed and SPF-aligned.
4. Data in transit
Client → ALB: HTTPS only (TLS 1.2+).
ALB → proxy task: HTTP within the VPC private subnets.
Proxy → RDS: TLS-capable (sslmode configurable); current default in this deployment is RDS-managed without enforced sslmode=require [TBD: tighten to require and document].
Proxy → Redis: Within VPC private subnets; encryption-in-transit toggle is available on ElastiCache and is [TBD: not currently enabled — operator decision].
Proxy → upstream LLM provider: HTTPS to the provider's published API endpoint.
AWS service-to-service: AWS-managed TLS.
5. Application-level controls
Rate limiting / abuse prevention: Per-key, per-user, per-team, per-organization request-per-minute (RPM) and tokens-per-minute (TPM) limits, plus parallel-request limits.
Budgets: Per-key, per-user, per-team, per-organization. Spend tracked in cents-precision; budget exceeded → request blocked.
Audit logging: LiteLLM_AuditLog records create/update/delete on teams, users, models, keys with the actor identifier, hashed actor API key, action, and JSON before/after diff.
Optional moderation hooks (off by default; operator opts in):
- Prompt-injection detection
- Azure Content Safety
- Presidio PII redaction
- Custom guardrails framework (litellm/proxy/guardrails/)
Optional rate-limit denial-of-service controls: dynamic rate limiting based on real-time pressure metrics.
6. Vulnerability management
[TBD: counsel/operator to confirm SDLC + dependency-scanning posture. Items observed in repo: - Dependency lockfiles in requirements.txt, package-lock.json - Codecov integration (codecov.yaml) - CI test workflow exists in .github/workflows/ - No SCA/SAST tool obviously wired in; if you adopt Snyk/Dependabot/etc., update this section.]
7. Secret management
Application secrets (DB password, Redis URL, master key, provider keys, SMTP creds) are sourced at runtime from the ECS task-definition environment, which is populated by the Terraform state (encrypted in S3). The container does not embed long-lived secrets.
CI/CD credentials use GitHub OIDC federation to assume short-lived AWS roles per environment. No long-lived AWS keys are stored in GitHub.
Provider keys in the database are encrypted at rest per the schema [TBD: encryption mechanism to be documented].
8. Backups and disaster recovery
RDS automated backups with environment-specific retention (current: production 7 days, UAT 1 day, sandbox 0 days).
Multi-AZ: off during beta, on at GA.
Restore: point-in-time restore is supported via RDS within the retention window.
Disaster recovery objectives: [TBD: RPO and RTO to be defined].
9. Incident response
[TBD: operator to document the incident-response process — paging path, severity levels, customer-notification timelines. The DPA §9 commits Provider to notify Customers of Personal Data Breaches "without undue delay" and within [TBD: 72 hours]; the operational process behind that commitment must be documented separately.]
10. Compliance posture
Certifications: None held at this time. [TBD: confirm with leadership whether SOC 2 Type II / ISO 27001 / HIPAA / PCI / FedRAMP is in scope.]
GDPR / CCPA / PDPA: the Service is designed to operate as a Processor under these regimes; controller obligations sit with Customer. See the Data Processing Addendum.
Open-source license: the underlying code is MIT (with the enterprise/ subdirectory under a separate license).
11. Reporting a security issue
If you believe you have found a security vulnerability in Routero AI, please report it to [TBD: security@routero.ai] with sufficient detail to reproduce the issue. We commit to:
- Acknowledging your report within [TBD: 3 business days];
- Investigating and triaging within [TBD: 10 business days];
- Coordinating disclosure on a reasonable timeline;
- Crediting reporters where they wish (we do not currently run a paid bug-bounty programme).
We do not authorize unauthorized testing against production systems. Coordinate any active testing with [TBD: security@routero.ai] in advance.