Security
Summary
Logethos is one person operating a small, deliberately simple stack. This page describes the controls that exist, the internal policies that govern them, and the things a reader might expect that are not in place. It covers the company. The detail of what a specific product does with a specific document is in that product's own security overview.
Two facts a security reviewer usually wants first. Data is stored in Mumbai, India, on a single-tenant virtual private server. Full-disk encryption at the storage layer is not enabled, so stored documents and database records are not represented as encrypted at rest; application secrets and customer-supplied provider keys are encrypted, and everything in transit is over TLS.
1. How security is governed
Nine internal policies define how Logethos runs. They are governance documents rather than marketing pages and are not published, but their names and substance are these:
| Internal policy | What it governs |
|---|---|
| Information Security Policy | Scope, principles, the control set, and who is accountable |
| Access Control Policy | Who and what may reach systems and data, at the application, infrastructure, and secrets layers |
| Password and Authentication Policy | The rules the product enforces on users, and the credential rules for company systems |
| Change Management Policy | How a change reaches production: review, gates, migrations, rollback |
| Secure Development Lifecycle | How code is built, tested, and released, and the automated gates that block a release |
| Vendor and Subprocessor Management Policy | How a vendor is assessed before it receives data, and how the register is reviewed |
| Backup Policy | What is backed up, how often, how long it is kept |
| Disaster Recovery Policy | How the service is restored after a major failure, and the recovery objectives |
| Incident Response Plan | How an incident is triaged, contained, resolved, and notified |
Each is reviewed at least annually and after any material change or incident. The security owner is the founder. Logethos is a sole proprietorship: there is no security team, no separate reviewer, and no rota. Where a control depends on a person rather than on code, this page says so.
2. What runs where
The website and the products run on a virtual private server in Mumbai, India, rented from Hostinger. The server is single-tenant. The database and the object storage that holds uploaded files run on that same host rather than on a managed service. The full vendor list is at Subprocessors.
3. Encryption
- In transit. All traffic is over TLS. HTTP Strict Transport Security is enforced at the reverse proxy, so a browser that has seen the site once will not fall back to plain HTTP.
- Secrets at rest. Customer-supplied provider API keys are held under authenticated encryption and are decrypted only at the moment of the call to that provider. They are never returned to a browser and never written to a log. Account passwords are hashed with scrypt. Platform credentials are server-side environment variables, never sent to a browser.
- Storage at rest. Disk-level encryption is not enabled on the server, and the self-hosted database and object storage do not perform separate at-rest encryption. Stored documents and database records therefore sit on an access-controlled single-tenant host without a storage-layer encryption boundary. This is stated rather than worked around because a reader evaluating the service should be able to weigh it.
4. Access
- Application access is scoped to an organisation, and for evidence to a project, on every query. Cross-organisation and cross-project access is covered by automated tests that run in the release gate.
- Administrative access to hosting, the database, source control, DNS, and provider accounts is least privilege and limited to named accounts. Multi-factor authentication is required on every account that supports it. Credentials are held in a password manager and are not shared.
- The privileged internal surface in the product fails closed and is restricted to a single configured operator address.
- Credentials are rotated on suspected compromise. Because there is one operator, the joiner and leaver process that a larger company would run is a rotation procedure rather than a workflow.
5. How changes reach production
Every change passes an automated gate before release: lint, database migrations, a schema drift check that fails the build if models and migrations disagree, the unit and integration test suite, an end to end smoke test, and per-feature acceptance checks, plus a frontend build and lint. The gate runs against real database and object storage containers with fake AI and billing providers, so it is offline and costs nothing to run.
Migrations run once per deploy as a release step rather than inside a container start command. Deploys are built images, so a rollback is redeploying the previous image. Post-deploy health and version endpoints are checked, and changes that touch a model provider get a smoke run that distinguishes a real cited answer from a wall of abstentions.
6. Vendors
A vendor that would receive customer data is assessed before it is engaged: whether it offers a data processing agreement, whether AI providers commit to not training on the data they receive, where it processes data, and whether the integration can be limited to the minimum content. The register is reviewed at least annually and whenever a vendor is added, changed, or removed, and the public Subprocessors page is updated in the same change.
7. Backups and recovery
| Item | Position |
|---|---|
| What is backed up | The database, including account, content metadata, and vector data, and the object store holding uploaded files |
| Frequency | Daily, at 02:30 UTC |
| Retention | 14 days |
| Point-in-time recovery | Not available. The recovery point is the most recent daily backup |
| Recovery point objective | Up to 24 hours of data |
| Recovery time objective | Best effort restoration from the daily backup. There is no contractual recovery-time guarantee |
| Off-site copy | Not yet in place. Backups currently live alongside the host they protect, so a total host loss is not covered. Configuring a secondary off-site destination is an open item |
| Restore testing | An operator commitment rather than an automated job. A backup that has never been restored is not a backup, and this is the control most in need of evidence |
The frequency, retention, and objectives above describe the schedule that is configured. They have not been validated by a documented test restore, so treat them as the intended recovery position rather than a measured one. They will be restated as measured figures once a restore has been run and recorded.
The application layer is stateless and single replica, which makes rebuilding it fast: it is a redeploy from source control. Recovery time is dominated by restoring data, not by restoring the application.
8. Incidents
Incidents are graded by severity, with confirmed exposure of customer content or a full outage at the top. The response sequence is triage and declare, contain, eradicate, recover, notify, then a written post-incident review with corrective actions. Containment measures available immediately include revoking sessions and keys, rotating secrets, blocking abusive sources, and disabling an affected feature by configuration.
If a personal data breach is confirmed, Logethos notifies the Data Protection Board of India and the affected people as the Digital Personal Data Protection Act, 2023 requires, and notifies affected customers without undue delay so they can meet their own obligations. Reports of an incident from outside are received at security@logethos.com.
Logethos is operated by one person and does not run a 24/7 on-call rota. A report is picked up within the acknowledgement window in the Responsible Disclosure Policy rather than within minutes.
9. Logging
Document contents and full model prompts are never written to logs. Each request carries an identifier for tracing. Error tracking, where enabled, records error metadata and a request identifier rather than content.
10. What Logethos does not claim
- No third-party certification. Logethos holds no SOC 2 report, no ISO 27001 certificate, and no equivalent from any other scheme. Nothing on this site should be read as one.
- No external audit. No independent auditor has examined these controls.
- No penetration test cadence. No scheduled third-party testing programme is in place.
- No bug bounty. Reports are welcome and credited, but there is no paid programme. See the Responsible Disclosure Policy.
- No cyber insurance is held.
- No storage-layer encryption at rest, restated here because it is the item most often assumed rather than checked.
Where that list changes, this page changes with it, with a date and a version.
11. Product detail
This page is the company posture. What a specific product does with a specific document, including what leaves the server, what a model provider receives, and what a customer can delete, is documented by that product. For Evigate, see the security overview at evigate.logethos.com/policies/.
12. Contact
Security reports and questions: security@logethos.com.