Security & Trust

This page describes safeguards visible in the reviewed Coul source as of the updated date. A control in source code is evidence of design and implementation intent; it does not prove that every production service, replica, region, account, vendor, network path, deployment setting, or operational process uses that control correctly.

Claims therefore identify whether a control exists in application code, depends on production configuration, or remains a launch requirement. Coul must update this page after material architecture, vendor, security, certification, or incident-response changes and must remove a claim that monitoring shows is no longer accurate.

No service is perfectly secure. Coul does not guarantee prevention of every vulnerability, attack, outage, accidental disclosure, provider failure, or data loss. Mandatory legal duties and customer remedies are not limited by this transparency statement.

Coul's target program should govern, identify, protect, detect, respond to, and recover from cybersecurity risk. The reviewed repository includes defensive application controls and operational readiness checks, but it does not establish a staffed security organization, approved risk register, asset owner map, risk acceptance process, board reporting, security training record, or complete production control inventory.

Before launch, Coul must assign accountable owners for application, cloud, identity, data, AI providers, social publishing, payment, incident response, privacy, vendor, backup, and business-continuity risk. Exceptions need an owner, reason, compensating control, expiry date, and review rather than an indefinite informal waiver.

NIST CSF, NIST SSDF, and OWASP ASVS can provide useful target outcomes and verification criteria. Referencing them does not mean Coul has been assessed, certified, or found conformant to a particular level.

Coul is responsible for the security of systems and processing it controls. Infrastructure, AI, analytics, social, payment, and other providers are responsible under their own services and agreements, while Coul remains responsible for selecting, configuring, supervising, and responding to those providers as applicable. A vendor certification does not automatically certify Coul.

Customers are responsible for accurate member access, strong unique credentials, secure devices and browsers, prompt removal of former collaborators, least-privilege workspace roles, authorized social accounts, safe share links, lawful uploads, review of publishing destinations, and reporting suspected compromise. These responsibilities do not excuse a Coul defect or duty the law places on Coul.

A connected social platform, public template, exported file, completed publish, or third-party recipient creates a boundary Coul cannot fully control. Disconnect, revoke, quarantine, and delete controls can reduce future use but may not recall an action or copy already outside Coul.

New database-backed passwords are hashed with Argon2id; stored legacy bcrypt hashes can still be verified. Coul does not store a recoverable plaintext password in the database. Login follows a generic invalid-credentials path, access tokens are limited by code to approximately 10–15 minutes, and an active database session and context are checked for authenticated access.

Refresh credentials are random, stored server-side as keyed HMAC-SHA-256 hashes, rotated during refresh, and bounded by a reviewed 30–60 day configuration range. Reuse detection invalidates the affected refresh-token family. Users can list active sessions, revoke another session, change a password, and have relevant sessions or tokens revoked by account or mailbox-security events.

Production requires distinct access-token, refresh-token, provider-envelope, and social-token-fingerprint key material, bounded previous-key rings, key identifiers, and fail-closed checks for unsafe or missing production secrets. Unknown access-token key identifiers fail verification.

The current web client stores Coul access and refresh credentials in localStorage. This supports session continuity and coordinated refresh, but a malicious script running in the same origin can potentially read those credentials. Token rotation and server revocation reduce some risk; they do not neutralize an active cross-site-scripting compromise or a stolen refresh token.

The reviewed API application does not include a complete Content Security Policy or browser security-header middleware, and production edge headers were not available for verification. Before launch, Coul must adopt a defensible session architecture—preferably appropriately scoped Secure, HttpOnly, SameSite cookies where feasible or an equivalently reviewed design—and test CSP, Trusted Types where appropriate, HSTS at the HTTPS edge, framing controls, referrer policy, MIME sniffing protection, logout, multi-tab cleanup, XSS defenses, and token theft response.

Coul must not say that browser credentials are HttpOnly, inaccessible to JavaScript, or protected by a deployed CSP until an authenticated production crawl and header review proves it. The Cookie Policy provides the current browser-storage inventory.

Coul resolves an active personal or workspace context and applies permission checks to sensitive actions. Workspace roles distinguish viewer, editor, admin, and owner capabilities; for example, owners control publishing and billing while lower roles receive narrower access. Administrative and system-only actions use separate authorization policies.

Repository queries, object keys, Redis namespaces, jobs, and vector collections generally carry personal or workspace context. Database constraints and tests protect many context relationships and last-owner or deletion boundaries. This is application-layer logical isolation, not a claim of a separate physical database or encryption key for each customer.

The reviewed PostgreSQL schema does not implement database row-level security as a second tenant boundary. Before launch, Coul must maintain a resource-level authorization matrix and test direct-object-reference, stale-role, invitation, transferred-owner, share-token, export, object-key, queue, cache, vector, admin, deletion, and backup-restore paths across tenants. A route-level permission check is not enough if a deeper query omits context.

Provider integration secrets and connected-social tokens use AES-256-GCM envelopes with authenticated context that binds ciphertext to its intended tenant, provider, field, and record. Envelopes carry key identifiers, support bounded previous decryption keys during rotation, and are accessed through audited secret-resolution paths. Separate HMAC fingerprints support comparison without exposing a token.

The currently implemented secrets provider reads encryption key material from the production environment. Managed KMS or HSM provider names and KMS identifiers are reserved for future implementation; a key-id value alone does not mean AWS KMS, another managed key service, or hardware protection is active. Key rotation requires inventory, re-encryption, overlap, audit, and proof that no active envelope remains on the retired key.

This selected-field encryption does not mean all Coul data is encrypted by application code. Database records, media objects, vectors, caches, logs, backups, and transport encryption depend on deployed infrastructure and configuration that were not available for verification. Coul must publish a broader at-rest and in-transit claim only after confirming every relevant store, replica, backup, key owner, cipher, rotation process, and exception.

The reviewed application authorizes media-read requests and issues time-limited signed URLs for S3-compatible media. It does not verify the deployed bucket policy, public-access blocks, object ACLs, unsigned access, or that every object store is non-public; deployed storage privacy remains a production verification requirement. Upload completion checks the expected session, tenant context, object size, content type, signature or magic bytes where implemented, and content hash before accepting the asset.

A signed URL is a bearer capability and can remain usable until expiry even after a recipient, log, browser extension, or message exposes it. Coul must use the shortest practical duration, avoid logging full URLs, bind purpose where supported, restrict bucket access, prevent guessable keys, review cache behavior, and invalidate or contain access after a deletion, rights hold, or compromise where technically possible.

The repository does not prove universally active malware, archive-bomb, decompression, document-macro, steganography, DLP, or media-safety scanning. Any malware-scanner integration is deployment-dependent and must fail closed for the protected workflow, monitor signature and engine freshness, quarantine suspicious files, handle scanner outages, and test evasive and oversized inputs before Coul calls uploads scanned or safe.

The API uses schema validation, explicit allowed CORS origins, request identifiers, bounded inputs, authentication and permission middleware, endpoint rate-limit policies, trusted-proxy controls, and redacted error envelopes. Redis-backed distributed limits are required for relevant production paths; proxy-derived client addresses are trusted only when the configured edge strips or overwrites inbound forwarding headers and the trusted network is correct.

Webhook paths verify provider signatures from the raw body where implemented, store bounded provider events, use idempotency or unique identifiers, and support current and previous signing secrets during a controlled rotation overlap. Publishing and background jobs use durable ledger state, leases, retries, idempotency, and reconciliation to reduce duplicate or lost actions.

TLS is not enforced by the application client for every PostgreSQL, Redis, Qdrant, internal service, or S3-compatible endpoint. Production must require modern HTTPS/TLS at public and internal boundaries, authenticated private networking, certificate validation, restricted ingress and egress, environment separation, non-public admin surfaces, and tested secret-free health responses. Exact-origin CORS is not a substitute for authentication, CSRF review, or network isolation.

Coul records request identifiers and audit events for many authenticated mutations, administrator changes, billing actions, secret access, publishing actions, and deletion steps. Central redaction helpers remove or mask recognized passwords, bearer tokens, cookies, refresh tokens, JWTs, provider keys, webhook secrets, sensitive URLs, prompts, and metadata before ordinary logs, API errors, or observability events.

These controls reduce accidental exposure but do not prove that every code path, third-party SDK, browser console, infrastructure log, crash dump, query log, AI provider, or support tool is covered. Pattern redaction can miss a novel format and can also remove useful forensic context. Production must test representative secrets and private content end to end and restrict access and retention by role and purpose.

Audit records are not described as complete, tamper-proof, immutable, or a customer-accessible compliance log. Coul must identify audit gaps, protect integrity, synchronize time, monitor missing writes, define retention, separate duties, export to a secured detection system, and preserve lawful incident evidence before making a stronger claim.

The code includes dependency readiness checks, health endpoints, metrics and traces hooks, queue-depth and repair concepts, structured errors, administrative observability views, and durable failure states. These can support detection and diagnosis when properly deployed, alerted, and staffed.

The repository does not prove a 24/7 security operations center, on-call coverage, SIEM, intrusion detection, centralized alert ownership, log-retention period, anomaly baseline, threat-intelligence feed, or tested escalation. A green readiness endpoint proves only the checks it performs at that moment; it is not a security attestation.

Before launch, Coul must define alert sources, severity and ownership, paging and fallback, evidence preservation, false-positive review, privileged-access monitoring, token and role anomalies, cross-tenant signals, provider failures, data-exfiltration indicators, and a schedule for detection tests.

PostgreSQL is designed as the durable source of truth for many queued operations; idempotency, leases, retries, repair workers, tombstones, and readiness checks can reduce inconsistency after a transient Redis or provider failure. Local development uses persistent volumes, but that is not evidence of a production backup program.

The reviewed repository does not establish production backup frequency, encryption, immutability, geographic separation, access controls, retention, restore testing, disaster-recovery architecture, or approved recovery-point and recovery-time objectives. It also does not verify high availability, multi-region operation, a published status page, or an uptime service-level agreement.

Before launch, Coul must inventory stateful systems and providers, configure and monitor backups, isolate and encrypt them, test full and granular restoration, verify tenant and deletion tombstones before recovered data returns to service, document degraded modes, and conduct recovery exercises. No uptime, RPO, RTO, zero-data-loss, or daily-backup promise applies unless a signed plan or order expressly and accurately provides it.

Coul's administrator-triggered context cleanup uses checkpoints and retries across billing, connected OAuth grants, object storage, Redis, Qdrant, database content, sessions, and identifiers. Social disconnection disables publishing and queues provider revocation. The Data Rights page explains the grace period, last-owner rules, provider failures, limited records, and lack of a current user-facing deletion flow.

Deletion is a security control only when it reaches every intended active and derived store and is not undone by a stale job, replica, cache, provider copy, exported file, recipient, or restored backup. Coul must reconcile scope, record partial failures, bound retained encrypted revocation envelopes, preserve only necessary tombstones, and verify that recovered systems reapply deletions and rights holds.

Coul cannot promise instant or complete recall from a connected platform, completed social post, lawful recipient, independent template copy, or provider legal hold. Restricted evidence must remain unavailable for ordinary product use and expire when its approved exception ends.

Coul depends on cloud infrastructure, databases, object storage, Redis, vector search, AI, public-data, social, payment, email, analytics, and observability components. A production inventory must name the deployed legal provider entity, service, purpose, data categories, location, role, transfer mechanism, retention, deletion support, security terms, incident duties, access, and approved subprocessors.

The repository does not establish a complete public subprocessor register, recurring vendor-risk assessment, contract review, breach-notice commitment, access review, exit plan, concentration-risk analysis, or proof that every vendor has a named certification. Coul must not say all vendors are certified, audited, GDPR compliant, or unable to use submitted data without verifying the exact service tier and agreement.

Before onboarding or materially changing a vendor, Coul should assess necessity and least data, authentication, encryption, tenant isolation, support access, training or secondary use, retention, deletion, regional processing, resilience, vulnerabilities, incident history, subcontractors, audit evidence, termination assistance, and a safer replacement or degraded mode.

The reviewed source contains observability and administrative tools that can support investigation, but it does not prove an approved incident-response plan, staffed incident command, legal and privacy decision tree, evidence procedure, communication templates, tabletop exercise, or tested vendor escalation. Coul must establish these before describing incident response as operationally mature.

A production process must triage reports, assign severity, contain and eradicate the cause, protect evidence, rotate exposed secrets, revoke sessions, isolate affected tenants and providers, recover safely, validate fixes, monitor recurrence, document decisions, perform root-cause review, and track corrective actions. Plans must cover cross-tenant access, stolen browser tokens, malicious uploads, insider access, AI or public-data exposure, publishing compromise, payment events, vendor breaches, and destructive or unavailable systems.

Coul will notify affected people, customers, regulators, platforms, insurers, or authorities when and as applicable law or contract requires. It does not promise a universal 24-hour, 72-hour, or other period because the trigger, recipient, risk threshold, content, and deadline vary; applicable mandatory deadlines still control. Notification must not be delayed merely to protect reputation.

The current GitHub workflow installs locked dependencies, runs lint and type checks, unit and database integration tests, builds production artifacts, applies migrations in test, exercises concurrency and deletion cases, and builds production container images. Containers use separated API surfaces and non-root runtime users where configured. These are meaningful quality controls, not a security certification.

The repository does not show mandatory SAST, dependency-vulnerability scanning, secret scanning, container and infrastructure scanning, SBOM generation, signed provenance, branch protection, required independent code review, dynamic security testing, recurring penetration tests, patch SLAs, or a documented supported-software lifecycle. Passing functional tests does not establish absence of exploitable vulnerabilities.

Before launch, Coul must threat-model high-risk flows; automate risk-based code, dependency, secret, container, and configuration scanning; triage findings; monitor exploited-vulnerability sources; patch by severity and exposure; test authorization and abuse; protect build credentials; review third-party actions and images; produce a usable component inventory; and obtain independent testing proportionate to risk.

Coul should publish an easy-to-find vulnerability disclosure policy and RFC 9116 security.txt file that identify in-scope systems, safe testing methods, prohibited disruption and data access, report contents, encrypted channel, acknowledgment expectations, coordinated disclosure process, remediation priorities, and good-faith safe harbor. A bug bounty, reward, response time, or authorization is not offered unless that published policy expressly says so.

Do not access another person's data, use social engineering, disrupt service, persist after proof, exfiltrate data, demand payment, or publish an unremediated exploit. Preserve the minimum evidence and stop when a vulnerability is demonstrated. If personal data or active credentials are exposed, do not include them in ordinary email; use the verified secure intake instructions.

The repository does not currently show a monitored security intake, public disclosure policy, security.txt, triage ownership, or safe-harbor authorization. Coul therefore does not publish an actionable reporting address on this page. Until a verified, tracked intake and those controls exist, this page does not authorize testing or prove that a report will be received.

Coul does not claim SOC 1 or SOC 2 attestation; ISO 27001, ISO 27701, or ISO 42001 certification; PCI DSS compliance or service-provider status; HIPAA compliance or a Business Associate Agreement; FedRAMP authorization; CSA STAR listing; independent penetration-test completion; a bug bounty; GDPR, UK GDPR, CCPA, or other legal certification; or any similar assurance not expressly listed here with current scope and evidence.

Stripe-hosted checkout can reduce the payment-card data Coul directly handles, but it does not by itself prove Coul's PCI scope or compliance. A vendor's audit or certificate covers only its stated entity, product, locations, period, and controls—not Coul's application, configuration, personnel, or other vendors.

If Coul later obtains an assessment, this page must state the exact Coul legal entity, standard and version, report or certificate type, system and region scope, period, exclusions, auditor, availability under NDA where appropriate, and status. Marketing must not shorten that into a broader or perpetual claim.

Coul has selected these risk-based controls as requirements before presenting this page as a production trust center; this list does not state that every control is universally required by law. Each gate needs an accountable owner, documented evidence, representative tests, monitored rollout, exception process, and revalidation after material architecture, vendor, identity, data, or threat changes.

• Verify modern TLS, authenticated private networking, database/Redis/Qdrant/S3 transport settings, storage and backup encryption, key ownership, environment separation, least-privilege service identities, and network ingress and egress.

• Replace or formally risk-accept the localStorage refresh-token design; deploy and test CSP and browser security headers, XSS controls, session cleanup, step-up protection, MFA or passkeys, and safe account recovery.

• Complete cross-tenant authorization tests across APIs, objects, exports, shares, queues, caches, vectors, admin routes, role changes, deletion, backups, and provider callbacks; document the absence or addition of database RLS.

• Operate fail-closed file scanning with freshness and outage monitoring, signed-URL containment, private buckets, upload abuse limits, content validation, quarantine, and deletion or rights-hold propagation.

• Establish centralized logging, protected audit integrity, detection alerts, on-call and escalation, privileged-access review, incident and breach playbooks, exercises, evidence handling, root-cause tracking, and customer or regulator communications.

• Implement encrypted and isolated backups, monitored completion, granular and full restore exercises, deletion replay protection, business-impact analysis, approved RPO and RTO, provider-outage modes, and an accurate status or SLA position.

• Publish a verified subprocessor register and operate vendor due diligence, contract and access review, incident escalation, data-use verification, resilience, concentration, exit, and deletion controls.

• Add SAST, dependency, secret, container and configuration scanning, SBOM and provenance controls, vulnerability intake, severity-based remediation, independent penetration testing, and recurring threat-model review.

• Publish and verify a monitored security reporting address, tracked and secure intake, scoped vulnerability disclosure and safe-harbor policy, security.txt, triage ownership, emergency routing, and non-retaliatory handling before inviting reports.

• Replace every absolute UI or marketing claim with evidence-bounded language; Coul's onboarding now links security posture to this page instead of saying all data is simply encrypted and secure.