Security Policy

• No scraping, ever. We read data only through platforms' official APIs.
• No client passwords. We never ask for, receive or store platform login credentials — only official OAuth tokens with the minimum necessary scopes.
• Everything is audited. Every automated action produces a moderation decision and an append-only, immutable audit entry; no executed action exists without one.
• No destructive default. The system takes no destructive action silently; unsupported actions are never faked.
• Fail safe. On uncertainty (token, rate-limit, error), the system does nothing and routes to human review.

Every data row is tenant-scoped; one tenant can never read or act on another's data. Authorisation is role-based (owner/admin/moderator/viewer) and enforced server-side. Production enforces PostgreSQL row-level security (RLS) with a non-superuser application role, providing defence in depth beneath application checks. Access follows least privilege.

OAuth access/refresh tokens are stored only in the persistence layer, never in the domain model, UI, logs or audit metadata. In production, token columns are encrypted at rest (AES-GCM or KMS/envelope encryption); plaintext token storage is rejected in production. Application and client secrets live only in server-side environment configuration and are never committed to source control. Error messages never echo secrets, authorization codes or tokens.

Data is encrypted in transit using TLS. Sensitive credentials (OAuth tokens) are encrypted at rest. Passwords are stored only as salted hashes; federated login avoids password storage entirely.

Inbound platform webhooks are signature-verified (e.g. HMAC-SHA256 with the app secret). Events are stored with a validity flag and take no automatic moderation action. OAuth flows are CSRF-protected via an httpOnly state cookie; a mismatch aborts the flow.

Automated moderation is allowed only when: AI confidence is above the high-confidence threshold; the platform API supports the action; and the category is not sensitive. Sensitive items (legal threats, self-harm) and high/critical severity always require human approval. Global and per-brand kill switches can immediately stop all live actions.

An immutable audit log records who/what/when/why for automated and human actions, including engine version and confidence. Operational logs support security monitoring and incident detection. Logs exclude secrets and are access-controlled.

We make small, reviewable changes with type-checking and build verification. We do not use demo data that impersonates real clients or brands, and make no real platform API calls until a connector is explicitly implemented and authorised. Configuration defaults are fail-closed (e.g. live actions and new connectors are disabled until deliberately enabled).

We take regular backups and design token refresh, rate-limit handling and retries to fail safe. Business continuity and recovery are addressed in our operational runbooks and disaster-recovery procedures.

Infrastructure and operational providers are engaged under written contracts with equivalent security obligations and are listed in the Subprocessor List. We select providers with recognised security practices.

Individuals with access are bound by confidentiality and are granted access on a need-to-know basis. Access is removed promptly when no longer required.

If you believe you have found a security vulnerability, contact info@tamanor.com with details. Please act in good faith, avoid privacy violations and service disruption, and give us reasonable time to remediate before any disclosure. We do not pursue good-faith researchers who follow this guideline.

This Policy is reviewed at least annually and after any material change or significant incident.