Security overview

Version 2026-10-19 draft · The legal documents are published in English. The English version governs.

For customers' security and procurement reviewers. Every claim below is implemented and tested in the codebase. The Service has not launched; where a control depends on production infrastructure it is marked pending, and we will not answer a questionnaire "yes" to anything so marked.

Tenant isolation

• Every tenant table has PostgreSQL row-level security, forced so it applies to the table owner as well, keyed on the organisation in the transaction.
• The application connects as a least-privilege role that cannot bypass row-level security, and a startup check refuses an unsafe role.
• Every route is classified and tested: guests are refused and another tenant's identifiers return not found. Twenty-one deliberate faults prove the tests can fail.
• Operators work inside each tenant's row-level security; the console role has no bypass.

Encryption and secrets

• Customer credentials (Google tokens, CMS passwords, SMTP, webhook and sign-on secrets) are envelope-encrypted with AES-256-GCM under a separate key per organisation, bound to that organisation, with every decryption audited.
• Deleting an organisation destroys its keys.
• Pending: key-encryption keys in a managed key service, TLS termination and private networking, and encryption at rest arrive with production hosting.

Identity and access

• Two-factor authentication is required for owners and can be enforced for everyone; passkeys are supported.
• Five fixed roles; approvals are a role, not a setting. Sensitive actions need a fresh password confirmation.
• Operators sign in on a separate host behind an allow-list with mandatory two-factor, and risky operator actions need two people.

Changes to your sites

• One policy engine checks every write and every send. High-risk changes are never applied automatically; there is no override.
• Every change keeps its previous state and can be rolled back; every applied change is verified and measured.

Outbound requests and crawling

• Every outbound HTTP client lives behind an allow-listed gateway, with hosts resolved once and refused unless public, so a customer cannot point the Service at our own network.
• Our crawlers identify themselves, honour robots.txt and visit only the sites that asked, as described on the crawler page.

Audit and monitoring

• A hash-chained, append-only audit log of every action, verified daily and exportable by the customer.
• Pending: error monitoring and uptime checks on a separate host, backups to two repositories with a performed restore drill, and an external penetration test, all scheduled before launch.

Reporting a vulnerability

Write to security@fikrtna.com. We acknowledge within two working days and will not take action against good-faith research that respects other customers' data.