Trust Centre

Security & Data Flow

A practical view of what stays in your browser, what reaches NaraOps services, and what an IT or security reviewer can verify today.

Current beta posture · 21 September 2026

Core design: CSV and Excel operational files are designed to be processed in your browser. Raw spreadsheet rows are not intentionally uploaded to NaraOps servers. A PDF, image or document reaches the extraction provider only when the user explicitly requests extraction, and proposed values remain behind a review-and-approval gate. Ask NaraOps receives compact analytical evidence rather than the source workbook.

1. Data flow

In your browser

Operational files are parsed and analysed locally. Your browser may retain the saved workspace, actions, structural mapping memory, proof-of-value information and local audit history so you can continue later.

When you extract a document

The selected PDF, image, Word file or text document is sent through the authenticated NaraOps endpoint to OpenAI for a single structured-extraction request. The request disables model-response storage, treats document text as untrusted data, enforces file type and size limits, and does not write the original bytes to the NaraOps account database. NaraOps recalculates field confidence from readability, source evidence, data-type checks, completeness and available cross-field checks. A user must approve the proposed table before it can enter analysis.

Connected local-folder handles, imported-file fingerprints, extracted rows and user corrections are stored in that browser. The website cannot scan a computer folder while it is closed; it rechecks folders only while open and only while the browser permission remains valid.

To NaraOps services

Account email, session and access information, feedback, limited billing references and ordinary security/request metadata are processed server-side to operate the service. If you use an Organisation, NaraOps also stores organisation membership, roles, pending invitations, structural organisation memory, SSO configuration and organisation audit events.

When you use Ask NaraOps

NaraOps builds compact analytical context from verified metrics and evidence. Raw operational rows are not intentionally included. Sensitive-field controls and a server-side context boundary are applied before the AI request proceeds. Ask NaraOps and document extraction also use durable per-account burst and hourly request controls to limit runaway loops, automated abuse and unexpected AI cost spikes without imposing a normal-use daily quota.

2. Account security

Standard sign-in uses one-time email codes. Session tokens are random, stored server-side only as hashes, and the browser session cookie is HttpOnly, Secure and SameSite=Lax. Sign-in codes expire and repeated incorrect attempts are limited.

Organisations can additionally configure OpenID Connect single sign-on. The SSO flow uses Authorization Code with PKCE, validates state and nonce, verifies the signed ID token against the provider JWKS, and checks issuer, audience and expiry before issuing a NaraOps session. Where an organisation requires SSO, the server blocks the normal email-code endpoints for eligible organisation users.

3. Organisation boundaries and roles

An Organisation creates a server-side company boundary. Every organisation-scoped API request verifies that the signed-in user is a member of the requested organisation before any shared resource is read or changed.

Owner: manages the organisation, Admin roles, members, shared structural memory and SSO settings. Admin: manages Members/Viewers, invitations, shared structural memory and SSO settings but cannot manage the Owner or other Admins. Member: can use and contribute shared structural memory. Viewer: can read shared organisation memory but cannot change shared company resources.

These roles protect server-side organisation resources. Source workbooks and saved operational workspaces remain browser-local, so organisation roles do not claim to provide remote control over a file already present on a user's own device.

4. Application security

NaraOps separates uploaded row data from the server-side account/organisation layer. Sensitive-field controls exclude protected fields from broad analysis by default, and the Ask NaraOps server boundary strips raw/control-shaped payloads before model requests. Analytical response guards are designed to withhold unsupported or role-swapped claims rather than silently present them as verified.

The local-first model reduces central storage exposure but does not remove endpoint risk: browser extensions, compromised devices, screenshots, exported workspaces and authorised local users remain outside NaraOps' server-side control. Customers should apply their own endpoint and device-management policies where required.

5. Shared organisational memory and audit

Organisation memory is limited to structural metadata such as confirmed roles/concepts, inclusion choices, labels, aggregation/direction settings, sensitive-field opt-ins and manually confirmed relationship endpoints. The server applies an allowlist before saving company memory; arbitrary source rows, field examples and unrelated properties are discarded.

Organisation audit history is server-side and records organisation/member changes and shared-memory updates. SSO configuration, domain verification and successful/failed SSO events have a separate organisation-scoped identity audit. These logs are intentionally not copies of operational row data.

6. Service providers and payments

Cloudflare provides application hosting, database infrastructure and edge/security services.

OpenAI provides responses for Ask NaraOps using the compact analytical context described above and processes documents when a user explicitly requests extraction.

Resend delivers sign-in, invitation and service email.

Lemon Squeezy acts as merchant of record for subscriptions and payments. NaraOps receives limited identifiers and payment/subscription state needed for entitlement; NaraOps does not receive or store full card numbers.

7. Scale, performance and availability

Most operational analysis is executed in the user's browser, distributing analytical CPU/memory work across customer devices rather than one shared NaraOps analysis server. Shared authentication, organisation, billing-entitlement and AI services still depend on provider capacity and NaraOps request controls. The current beta does not claim a certified concurrent-user capacity or availability SLA until dedicated load testing and operational monitoring support that commitment.

8. Incident response

Security or privacy concerns can be reported to privacy@naraops.com. NaraOps can use available application, organisation and provider logs to investigate reported events, restrict access where appropriate and coordinate with affected service providers. The beta does not currently claim a 24/7 security operations centre, contractual incident-response SLA or certification that has not been completed.

9. Your controls

Inside Workspace, users can review and correct every extracted value, withhold unapproved data from analysis, disconnect a folder, export locally held NaraOps data and clear the entire local workspace. Clearing the workspace also removes NaraOps' locally remembered folder handles, import ledger, document-extraction acknowledgement and accumulated document dataset. An export can contain operational data from the saved workspace, so it should be protected like the source files themselves.

NaraOps also keeps a local structural audit history when semantic mapping settings are saved. Organisation Owners/Admins can additionally review the central organisation audit history.

10. Procurement evidence

Organisations can review the Security Pack, this data-flow page, the Privacy Notice, Terms, provider list and current controls. Supplier-security questionnaires or a technical review can be requested. Source code is not publicly distributed as part of the standard product, and NaraOps should not represent source review, penetration testing, ISO 27001, SOC 2 or another assurance as available unless it has actually been completed or separately agreed.

11. Current beta limits

NaraOps is still in production hardening. During the review beta, do not upload highly confidential information, special-category personal data, regulated personal data, credentials, secrets or data requiring controls beyond the current beta security posture.

SAML, enterprise directory synchronisation, organisation ownership transfer and device-management controls are not yet production features. OIDC providers that require a confidential-client secret are also not yet supported because NaraOps does not store organisation client secrets in this release.

12. Related documents

See the Trust Centre, Security Pack, Privacy Notice and Terms.