Trust Center
Security & Trust at Meridian AI
Meridian processes deal-flow data for cross-border teams operating in the Gulf-US corridor. This page is the single shareable answer for your General Counsel, Compliance team, or IT Security review.
Last reviewed: October 11, 2026·For security questions: security@meridianai.fyi
1. Compliance & Certifications
Status of the regulatory frameworks customers typically ask about. “Deferred” means an intentional product decision that can be revisited; it is not an oversight.
Not certified. Readiness work only: the Type II observation period has not started and no audit report exists yet.
Self-service data export (Settings → Security → Export My Data) and immediate account erasure are implemented. The export does not yet cover every data category, and there is no consent record or data-subject-request queue yet. Not independently assessed. Region-specific data residency is not currently offered.
Controls are being mapped to PDPL requirements. Not yet independently assessed. Hosting in a specific region, for example in the Gulf, is not offered today; it is a roadmap item for Enterprise contracts. Customer data is hosted in the EU (database, cache, background worker and document-processing services on Railway's EU West region in the Netherlands) and in the United States (the web application on Vercel; uploaded files and database backups on AWS S3).
Planned after SOC 2 Type II, which is still in readiness.
Restricted Gmail scopes (gmail.send, gmail.readonly) requiring CASA Tier 2 assessment ($25k + 6–12 weeks) are intentionally dropped from the default OAuth scope list. Email you send from Meridian goes out from your Meridian address through Resend, so no mailbox connection is needed; the Microsoft Outlook integration provides calendar and contacts sync. Re-enabling Gmail would need the assessment plus wiring the existing Gmail send module into the compose flow.
2. Security Controls
Each control below is implemented in the codebase.
Data routes scope their queries to the signed-in user's organization (and, where relevant, corridor) through shared helpers such as getOrgFilter and dealScopeWhere. Scoping is enforced in application code, not by the database. Cross-organization isolation tests in CI cover the main routes, including deals, contacts, communications and the marketplace.
Every e-signature event is cryptographically anchored to the prior event in the deal's signature chain. Tampering with one event invalidates every subsequent signature.
Deals, contacts, documents, regulatory items, agents, message threads and notifications are soft-deleted (hidden from normal queries) and permanently removed by a daily clean-up job 90 days later.
bcrypt cost 12. Owner-initiated admin unlock flow for locked accounts; rate-limited per IP + per account. No raw passwords stored anywhere.
Refresh tokens (Google, Microsoft) stored encrypted at rest via AES-256-GCM with key in environment scope. Each stored value carries a key-version prefix so a future key rotation can re-encrypt it.
Worker ↔ app and harvester ↔ app traffic authenticated via per-environment INTERNAL_WORKER_SECRET bearer tokens. Inbound to the harvester uses a separate X-Harvester-Secret with constant-time compare.
Agents are owned by their creator's organization. The agent-execute path loads the calling user through a centralized loadAuthUserFromDb so scoping enforcement is identical between bearer-token (mobile/watch/harvester) and NextAuth-session (web) paths.
Per-user daily request and token limits, a per-organization monthly AI budget that refuses further calls made through the platform's AI service once it is used up (not every AI feature is routed through it yet), and a step limit and spend ceiling on every agent run. User input to the chat, drafting, document Q&A, document generation and agent-task AI routes is sanitized (control characters stripped, delimiters escaped, known injection patterns logged), though not every AI feature applies this step yet; third-party content returned by agent tools (documents, news, registry records) is wrapped as untrusted data. These reduce, but do not eliminate, prompt-injection risk.
3. Audit Trail & Retention
Security-relevant actions: integration connections, data exports, account deletion, password changes, agent runs, e-signature events and administrative changes. Not every mutation is audited yet.
Audit-log entries are not deleted automatically; today they are kept indefinitely. The retention periods in our Privacy Policy are policy targets.
Owners and Admins can export the organization's audit log as CSV from Settings → Audit Log (the entries currently loaded in the view).
Hash-chain anchoring on the e-signature audit chain ensures signature events cannot be silently modified. Other audit rows are not tamper-evident yet.
4. Encryption & Key Management
TLS 1.2+ and HTTPS on every public endpoint, with HSTS. Encryption of the application's connections to Postgres and Redis on Railway depends on deployment connection settings that the code does not enforce, and has not been independently verified.
Database backups (logical pg_dump) are uploaded to AWS S3 over HTTPS and encrypted at rest with S3 default server-side encryption (SSE-S3). Encryption of the Postgres storage at rest is a Railway platform control that Meridian has not independently verified.
Refresh tokens stored encrypted via AES-256-GCM with environment-scope key. Each value carries a key-version prefix so a future key rotation can re-encrypt without re-prompting users.
bcrypt cost 12, stored alongside per-user random salts. Cannot be recovered, only reset.
5. Incident Response
The lifecycle of any production incident, from automatic detection to public post-mortem.
Sentry (browser and server) reports uncaught exceptions. A Prometheus metrics endpoint exposes per-route request counts and latency. The public status page at meridianai.fyi/status reports live component health.
Initial acknowledgement within 1 hour during business hours, 4 hours overnight. Severity is assessed against the operations runbook, which today defines a single escalation tier, SEV1 (full outage or data-loss risk), that triggers the incident-response procedure and a written post-mortem. Customer-facing incidents also follow the communication commitments below.
Root-cause analysis with structured logs (Pino, JSON) across the request context. Where the affected action is one that is audited, its audit log entries are consulted alongside the Sentry trace.
Hot-fixes shipped through the same CI pipeline as routine changes (no production-direct edits). Rollback via Vercel revert + Railway redeploy.
Affected customers notified within 4 hours of confirmed material impact. Post-mortem published on the status page (meridianai.fyi/status) within 5 business days for any incident with customer impact greater than 5 minutes.
6. Operational Facts
Customer data is hosted in the EU (database, cache, background worker and document-processing services on Railway's EU West region in the Netherlands) and in the United States (the web application on Vercel; uploaded files and database backups on AWS S3). Hosting in a specific region, for example in the Gulf, is not offered today; it is a roadmap item for Enterprise contracts.
A nightly scheduled job (02:00 UTC) queues a logical pg_dump that the background worker uploads to AWS S3. Retention target: 90 days, not enforced by application code. Restores are manual and follow the operations runbook; automated restore testing is not in place yet.
RPO target: 24 hours (worst case — last successful nightly backup). RTO target: 4 hours (full restore from latest pg_dump + redeploy from main). Not yet validated by a scheduled restore drill.
security@meridianai.fyi. We acknowledge reports within 48 hours. We do not take legal action against good-faith security researchers following standard disclosure practices.
No external penetration test has been performed yet. The first is planned after the pilot, followed by an annual cadence.
7. Data Sources & Freshness
Meridian draws on a mix of live external feeds, hand-curated reference data, and subscription sources. We label each so you know what is real-time, what is periodically verified, and what is not yet connected. Meridian never fabricates: when a source is unavailable, the result is an explicit “unverified” flag for human review, not an invented answer.
SEC EDGAR full-text search, OpenCorporates and OpenOwnership are queried at enrichment time, and CourtListener litigation search when its API key is provisioned. The OFAC SDN list is refreshed nightly and the OpenSanctions consolidated dataset (200+ global lists) is downloaded in bulk; sanctions screening runs inside Meridian against those copies.
GDELT global news/events is queried live across English, Arabic, and 100+ languages. Adverse-media, funding, and M&A signals are classified per run with source URLs retained for citation.
Saudi government tenders (Etimad), Saudi Press Agency and Emirates News Agency (WAM) wires, and MISA investment-opportunity listings are crawled by a self-hosted harvester service and surfaced inside contact briefings. Active only where the harvester is provisioned; when it is not, no placeholder data is shown. A Bahrain source was investigated and deferred.
Listed-company board directories and free-zone registries are a hand-curated, counsel-reviewed reference covering the top issuers by market capitalization — NOT a live registry query. Every record carries an as-of / last-verified date that the agent is required to cite, and a no-match is flagged for human/counsel verification rather than guessed. Live registry scraping is on the roadmap.
LinkedIn profiles (ProxyCurl), EN+AR news (Newscatcher), company data (Crunchbase), MENA venture data (Magnitt) and person enrichment (People Data Labs, Apollo) run only when Meridian has provisioned that provider's API key for the platform. Until a key is configured these sources are skipped — never simulated.
Enterprise market-data terminals require vendor contracts and are not yet integrated. They appear as 'Coming Soon' in Settings → Integrations.
8. Sub-Processors & Data Flow
The full list of third-party service providers that process customer data is maintained on a dedicated page and updated when vendors change. Material changes are announced 30 days in advance per the standard Data Processing Addendum.
View the Sub-Processors page →9. How to Reach Us
For vulnerability reports, security questionnaires, or pen-test coordination. We acknowledge reports within 48 hours.
For GDPR / Saudi PDPL subject-access or deletion requests. We respond within 30 days.
For DPA negotiation, BAA inquiries, or standard contract clause questions.