Security at Narrative

Infrastructure and subprocessors

Narrative runs entirely on managed infrastructure. We operate no data center and no office network, so physical and environmental security is inherited from the providers below, each of which publishes its own third-party attestations.

• Heroku (a Salesforce company) — the application API, the PostgreSQL database, and the Redis cache and job queue. US region.
• Vercel — the web application and its edge network.
• Cloudflare — DNS and the edge in front of our domains, plus R2 object storage for call-recording audio and data-export bundles.
• Nango — brokers the Salesforce and HubSpot OAuth connections and holds those tokens. Nango publishes a SOC 2 Type II report.
• Stripe — subscription billing and payment processing.
• Sentry — application error monitoring, with PII scrubbing configured on both the web and API projects.

Beyond that infrastructure, Narrative uses subprocessors in a defined set of roles: AI model providers for research and drafting, B2B contact and public-profile enrichment, speech-to-text and meeting transcription (only for customers who turn on call recording), product analytics, e-signature, telephony, and transactional email. The complete current register — each vendor, the data it receives, its region, and its data processing addendum — is available on request at security@getnarrativeai.com. We give 30 days' notice to a customer's billing contact before adding a subprocessor that processes regulated personal data.

How your data is protected

The strongest protections are the ones that are structural — properties of how the system is built, not settings that can be left misconfigured.

• We do not store the mail we read. When you authorize Narrative to read a thread, it produces summaries, context, and suggestions, and keeps only that derived result — the bodies of your incoming messages are not retained in our database. Outreach your reps compose and send through Narrative is a different thing and is stored, because the record of what was sent to a customer is the point of it.
• We never hold your CRM credentials. Salesforce and HubSpot OAuth tokens are held by Nango, not by us. They are not in Narrative's database, so a compromise of Narrative does not yield a token that can call your CRM.
• We never see card data. Stripe collects and processes payments. No card number reaches our systems at any point.
• Encrypted in transit. Every public endpoint is served over HTTPS, and both the web application and the API send HSTS with the preload directive, so compliant browsers refuse to talk to us over plaintext at all.
• Encrypted at rest. The PostgreSQL database and R2 object storage are encrypted at the disk level with AES-256 by the hosting providers. On top of that, the Google and Microsoft OAuth tokens we hold on your behalf, and the seeds behind authenticator-app codes, are encrypted at the application layer with Fernet before they are written. Recovery codes are stored only as hashes, and passkeys are stored as public keys, so for those there is nothing in the database to decrypt at all. A database dump alone does not yield a usable second factor.
• Tenant partitioning. Customer records are partitioned by company: list and retrieve queries resolve the caller's company through a single canonical resolver, and a cross-tenant request returns 404 rather than 403, so the existence of another organization's record is never disclosed. We re-verified this directly against the production database in October 2026 and found no cross-tenant data.
• No secrets in source. The application repositories carry no credentials; secrets exist only in the per-environment configuration of Heroku and Vercel. This was independently re-scanned in October 2026.
• Your data is not a product. We do not sell customer data, do not share it for advertising, and do not use your content to train third-party foundation models for anyone else's benefit.

On the application surface: database access is parameterized throughout, uploads are validated and size-limited, a Content-Security-Policy is set on both tiers, CORS and CSRF origins are explicit allowlists rather than wildcards, and every inbound webhook endpoint verifies the provider's signature before acting on a payload.

Our sending domain is covered by SPF, DKIM, and DMARC at p=reject, and the domain itself is DNSSEC-signed with registrar transfer and delete locks in place. A forged email claiming to come from Narrative is rejected by the receiving mail server rather than delivered to your team.

Access control and authentication

• Sign-in is by email and password or by single sign-on. Passwords are stored only as salted hashes and are checked against length, complexity, and common-password rules.
• Multi-factor authentication is available to every user, in three forms: TOTP (Google Authenticator and equivalents), WebAuthn security keys and passkeys, and single-use backup codes. Enrollment is self-service from account settings.
• Session tokens are not reachable from JavaScript. The web application keeps its tokens in __Host--prefixed, httpOnly, Secure cookies, so there is no readable token for a cross-site scripting bug to steal. Access tokens are short-lived, refresh tokens rotate, and a refresh token is blacklisted on logout.
• Deactivation is immediate. Every authenticated request re-checks that the account is still active, so removing a user takes effect on their next request rather than whenever their token happens to expire.
• Authorization is default-deny. The API refuses unauthenticated access unless an endpoint explicitly opts out, and every endpoint that does opt out has been individually reviewed for what it exposes.
• Sensitive operations require fresh proof of identity. Security-relevant actions prompt for re-authentication even inside a live session, and the internal administrative interface is gated behind multi-factor authentication.
• Support access is impersonation-based and audited. When we need to see what you see in order to help, it happens through an impersonation path, and every action taken under it is written to the audit trail with the operator's identity attached.
• The browser extension holds no credentials of its own. It authenticates off your existing Narrative web session and has no separate login.

How changes reach production

This is the control we lean on hardest, so it is worth describing exactly. Nobody pushes to production. Development lands on a staging trunk that deploys to an isolated staging environment; the production branch is written only by a single promote workflow. The direct production-write commands are additionally blocked at the tooling layer by a deny list, so they cannot be run by hand even deliberately.

• Blocking gates on every push. A staging deploy happens only if all of these pass: framework system checks, a migration-graph consistency check, a registry membership gate that fails the deploy when a changed product surface is missing from the checked-in workflow registry, dependency CVE scanning on both tiers (pip-audit --strict on the API, a production-dependency audit on the web application), lint and type checking, the scoped test selection executed against PostgreSQL with migrations applied, and a real authenticated login round-trip against the deployed environment. A red gate stops the deploy.
• Every landed change is reviewed, and the verdict is permanent. Each landed commit range carries an automated code-review verdict recorded as a GitHub commit status, which cannot be rewritten after the fact.
• Production has exactly one door. Promotion runs only through a single gate script, behind a GitHub deployment environment with a required reviewer. Approvals are pinned to a specific commit and recorded immutably in the workflow run history.
• What ships is what was tested. The production deploy reuses the artifact already built and tested on staging — the API slug is promoted, the web build is redeployed — so the code running in production is byte-identical to the code the gates passed.
• Automatic rollback on a failed deploy. Production is health-checked immediately after every promote, and a failed check rolls back to the previous release without waiting for a human. This is not theoretical: it fired on 20 September 2026 and completed the rollback and its verification in 62 seconds.
• Risk is assessed per change. All 130 product workflows carry a risk tier in a checked-in registry, and the engineering ceremony required for a change scales to the tier of whatever it touches.
• Dependencies. Dependabot runs weekly against both application repositories, CVE-driven upgrades land within days, and the full test suite runs nightly against the staging tip.

Audit trail and monitoring

Every sensitive API request is written to an audit table in the application database — who acted, on what, and with what outcome. It is a durable database record rather than a log line, which means it is queryable after the fact and is not subject to the lifetime of a platform log stream. At the time of writing it holds a continuous five-month history.

Runtime errors are captured by Sentry on both the web and API projects, with PII scrubbing configured, including a deep scrubber for nested payloads.

Data retention, export, and deletion

Your organization can export its data and request deletion from within the product; the export path has been exercised in production. A deletion request opens a 30-day grace window during which the account becomes read-only, so you can still export or cancel, after which a scheduled job purges the data and writes a completion record to an erasure ledger. That ledger entry records who requested the deletion and how many records of each type were removed — not the personal data itself. Several caches expire on their own schedules, and requests we cannot serve through the product go to the address at the bottom of this page. The Privacy Policy covers what we collect and why.

Compliance posture

• SOC 2. Narrative is not SOC 2 certified and has no SOC 2 report. A SOC 2 Type 2 readiness program is underway, with the Security (Common Criteria) category in scope for the first report. No auditor has been engaged and no observation period has begun. We will update this page when either changes, and we will not describe a report before one exists.
• GDPR. We act as a processor for the customer data you put into Narrative. A data processing addendum is available on request, export and deletion paths are implemented in the product, and completed deletions are recorded in an erasure ledger.
• CCPA. We do not sell personal information and do not share it for cross-context behavioral advertising.
• PCI DSS. Out of scope for Narrative. Stripe handles payment collection and processing; no card data reaches our systems.

Contact

security@getnarrativeai.com — vulnerability reports, security questionnaires, and requests for our data processing addendum or the full subprocessor register. It is a monitored inbox, not a pager; use the timeframes above.

hello@getnarrativeai.com — everything else. See also the Privacy Policy and the Terms of Service.