Zelaros Security

Credential Storage

Every API key, OAuth token, and access credential you enter in Zelaros is encrypted before it touches our database.

Encryption standard: AES-256-GCM - the same standard used by financial institutions and government agencies.

How it works: Credentials are encrypted at the application layer the moment you submit them. The encrypted value is what gets written to the database. The encryption key itself is never stored in the database - it lives in a separate, environment-isolated secrets store. Plaintext credentials are not accessible through standard database access. Decryption requires the encryption key, which is stored separately from the database in an isolated environment. Decryption happens only at job execution time, in memory, for the duration of the API call, and nowhere else.

What this means in practice: Even if someone gained read access to our database, your credentials would be useless to them.

Read-Only Access Only

Zelaros requests the minimum permissions required to read billing and usage data - nothing more.

When you connect a provider, Zelaros asks for:

• OpenAI: Admin API key scoped to usage and cost data
• Anthropic: Read-only console access for cost export
• AWS Bedrock: IAM policy with ce:GetCostAndUsage and CloudWatch read permissions - no ability to create, modify, or delete resources
• Azure OpenAI: Cost Management Reader role - read-only
• GitHub Copilot: copilot:read scope - no write access to your codebase or repositories
• Cursor: Enterprise analytics read access
• Microsoft 365 Copilot: Reports.Read.All - no access to email, files, or Teams content
• Claude.ai Teams/Enterprise: Analytics API read access
• Perplexity for Teams: Admin API read access for seat and utilization data
• Harvey: Admin portal read access for billing and seat data
• Jasper: Workspace admin read access for billing and seat utilization data

We never request write permissions. We cannot make API calls, trigger model runs, modify your configurations, or access your prompts or completions through any of the credentials you provide.

What We Access and What We Do Not

Zelaros reads:

• Token counts and request counts
• Cost in USD per model, per API key, per date
• Seat assignments and active user counts for SaaS tools
• Model names and workspace identifiers

Zelaros never accesses:

• Your prompts or completions
• The content of any documents, code, or data processed by AI models
• User messages or conversation history
• Any data that passes through your AI workflows

Connecting Zelaros to your billing API is equivalent to connecting a bank feed to an accounting system. We see the transaction amounts, not what was purchased.

Authentication

Zelaros uses Google OAuth for user authentication. There are no passwords. We do not store, hash, or process passwords of any kind - the attack surface that password databases represent does not exist in Zelaros.

Access tokens expire after 15 minutes. Refresh tokens expire after 30 days and rotate on every use - a compromised refresh token cannot be reused after a single session.

Data Isolation

Every piece of data in Zelaros is scoped to your organization. Every database query - without exception - includes an organization ID filter derived from your verified session token. Zelaros is designed so that one customer's data cannot appear in another customer's dashboard. Every query is scoped to the verified organization in the session token, enforced at the application layer.

Audit Logging

Every state change in Zelaros is recorded in an immutable audit log: who connected an integration, who changed an alert threshold, who exported a report, who invited a team member. Audit records are append-only. No update or delete operations are permitted on the audit log table. Retention: 7 years.

Infrastructure Security

Encryption in transit: TLS 1.2 or higher on all connections. Enforced at the Cloudflare edge - unencrypted connections are rejected.

Encryption at rest: Database encryption at the infrastructure layer (Railway PostgreSQL) in addition to application-layer credential encryption. Object storage (Cloudflare R2) encrypted by default.

Secrets management: No credentials, API keys, or secrets appear in source code or version control. All secrets are stored as environment variables in isolated Railway environments.

Network isolation: Backend services communicate over Railway's private internal network. The database and Redis instances are not accessible from the public internet.

Backups and Recovery

• 7-day point-in-time recovery via Railway PostgreSQL Pro
• Daily full database backups to Cloudflare R2, retained for 90 days
• Monthly archive backups retained for 1 year
• Weekly automated backup verification - we restore to a test environment and run verification queries to confirm recoverability

Security Scanning

We run automated security scans against our deployed application using industry-standard tooling (OWASP ZAP, Mozilla Observatory) before every release. All HTTP security headers are enforced at the Cloudflare edge.

SOC 2 Type II

SOC 2 Type II certification is on our roadmap. We have designed Zelaros from the ground up to meet SOC 2 criteria - immutable audit logs, access controls, encryption at rest and in transit, and data retention policies are all in place. We will pursue formal certification as we scale beyond our initial customer base. If your organization requires SOC 2 before onboarding, contact us directly to discuss a timeline.

Responsible Disclosure

If you discover a security vulnerability in Zelaros, please report it to security@zelaros.com. We will acknowledge your report within 24 hours and keep you informed as we investigate and resolve the issue. We ask that you give us reasonable time to address the vulnerability before public disclosure.

Questions

Security questions that are not answered here can be directed to security@zelaros.com. Enterprise customers evaluating Zelaros can request a security review call with our founding team.