Security

Infrastructure

Omako runs on Amazon Web Services (AWS), Mumbai region (ap-south-1). Your data never leaves India-region infrastructure as part of normal service operations. We use managed services where possible (RDS for databases, S3 for file storage, CloudFront for delivery) to inherit AWS's underlying physical and network security controls.

All production systems run inside a private VPC with strict security-group rules. No database or internal service is directly accessible from the public internet.

Encryption

• In transit: All connections to Omako use TLS 1.2 or higher. We redirect all HTTP to HTTPS and set HSTS headers with a long max-age. Cipher suites are reviewed quarterly.
• At rest: Database volumes and S3 buckets are encrypted with AES-256 using AWS-managed keys (SSE-KMS). Backups are encrypted with the same keys.
• Secrets: API keys, tokens, and credentials are stored in AWS Secrets Manager and rotated on a schedule. They are never committed to source code or logged.

Authentication and access

Magic-link login

Omako uses magic-link authentication. We never store passwords. When you sign in, a short-lived, single-use token is emailed to you. Tokens expire after 15 minutes and are invalidated after use.

Client portal access

Your clients access their portal via a signed link sent to their email. No account creation, no password, no friction. Each link is scoped to a specific project and expires as configured by you.

Internal access controls

Access to production systems is restricted to core engineers via SSO with phishing-resistant MFA. All privileged access is logged and reviewed. No engineer has standing access to customer data. Queries to production require a formal access request with a defined scope and duration.

Omi and AI inference

Omi's suggestions are generated by sending relevant project context to a third-party language model API over an encrypted, server-side connection. We apply the following safeguards:

• Inference calls include only the minimum context needed to generate a response (principle of data minimisation).
• Our model provider agreement prohibits using your data to train or fine-tune any model.
• Inference requests are not logged beyond what is needed for abuse detection (30-day rolling retention).
• Prompt injection attempts are monitored and blocked at the API layer.

Application security

• Input validation: All user input is validated server-side. We use parameterised queries throughout and do not construct SQL from user input.
• CSRF protection: All state-changing requests require a valid CSRF token.
• Content Security Policy: CSP headers are set on all pages to limit XSS risk.
• Dependency scanning: We run automated dependency vulnerability scanning in CI and patch critical issues within 48 hours.
• Rate limiting: API endpoints are rate-limited per IP and per account to prevent brute force and abuse.

Data backups and recovery

Automated daily backups are retained for 30 days. Database snapshots are taken before every major deployment. We test restore procedures quarterly. Our target RTO (recovery time objective) is 4 hours; our RPO (recovery point objective) is 24 hours.

Compliance roadmap

Responsible disclosure

We welcome security researchers. If you find a vulnerability in Omako, please report it to security@omako.app before disclosing it publicly. Include:

• A clear description of the vulnerability and its potential impact.
• Steps to reproduce, including any payloads or proof-of-concept code.
• The URL, endpoint, or component affected.

We will acknowledge your report within 2 business days and aim to resolve confirmed vulnerabilities within 30 days. We ask for a 90-day coordinated disclosure window before public release. We don't currently offer a bug bounty programme, but we do recognise researchers in our security acknowledgements page.

Please do not test in a way that could affect other users, access data you are not authorised to access, or run denial-of-service tests.