Security at Nora

How Nora protects connected financial information, what access it has, and where its safeguards still have limits.

Last updated 26 August 2026

Placeholder page. This page describes controls present in the reviewed codebase. It does not establish the currently deployed revision, operational practices, or an independent security certification.

Your bank credentials never reach Nora

Nora connects supported institutions through Plaid. Authentication happens in Plaid or your institution's own authorization flow, so your bank username and password are not entered into, transmitted to, or stored by Nora. Plaid instead gives Nora an access token for the information you approved. That token is not your bank password.

Nora cannot move your money

Nora's current financial-account access is read-only. It can retrieve and analyze supported balances and transactions, but it cannot make payments, initiate transfers, withdraw money, or trade securities. The finance tools used by Nora Chat and Boards are read-only too.

Connection tokens and secrets stay server-side

Plaid access tokens are encrypted before storage. Provider credentials, encryption keys, database credentials, and AI-provider credentials remain on server-side infrastructure and are not exposed to the browser. Provider connection records are kept separate from the normalized accounts and transactions used by product features.

Access follows your signed-in account

Protected requests are checked against the authenticated session. Nora's backend determines who you are from that session instead of trusting a user ID supplied by the browser. These ownership checks cover accounts, transactions, related merchant and category activity, provider connections, Nora Chat threads, and Boards.

AI operates behind the same boundaries

Nora currently uses Google Gemini for Nora Chat, requested explanations, Board creation and editing, and merchant enrichment. The model does not have unrestricted database access. Nora's authenticated finance tools select permitted data and perform calculations before relevant results are sent to the model.

Depending on the feature, the limited context sent to Gemini can include messages, relevant finance-tool results, verified explanation facts, Board instructions and content, or merchant names and transaction descriptions. Bank passwords, Plaid access tokens, and encryption keys are not included in that financial context.

AI output is constrained, not infallible

AI-generated Boards must pass Nora's component, tool, operation, and financial-scope rules before they can be stored or rendered. Requested explanations use server-controlled finance operations. These safeguards reduce risk, but AI-generated explanations and classifications can still be incomplete or wrong.

Operational records minimize financial content

Nora records limited information needed to understand reliability, AI usage, and performance, such as model or feature names, token counts, timing, finance-tool names, status, and errors. Dedicated AI-usage and chat-performance records are designed not to contain prompts, responses, tool arguments or results, transaction descriptions, provider credentials, or account identifiers. Saved Nora Chat conversations are separate product content.

The server-side Better Auth Infrastructure Dash plugin separately sends authentication lifecycle and audit events that can include user, email, session, login-method, user-agent, IP, and approximate location information. Nora does not enable Sentinel browser fingerprinting, proof-of-work, or request blocking.

Optional PostHog analytics and session replay require separate affirmative choices and use a rotating anonymous browser identifier. Events exclude financial values, prompts, content, and account or provider identifiers. Replay masks text and inputs and blocks financial pages, Chat, Boards, settings, authentication, Plaid, search, and exports. Network bodies and headers, console logs, clipboard contents, canvas, and provider frames are excluded. Nora can disable browser PostHog initialization in production.

Email-and-password accounts must verify their address before financial features are available. Verification and recovery links expire after one hour, recovery links are single-use, successful password resets revoke existing sessions, and authentication endpoints are throttled. Resend webhook signatures are verified; Nora stores hashed-recipient delivery metadata for 90 days and suppresses addresses after bounce or complaint events.

Disconnecting and deleting are different

Disconnecting an institution stops Nora's normal synchronization path and asks Plaid to remove the connection. If Plaid removal is pending, Nora may temporarily retain the encrypted token so removal can be retried. After provider removal completes, Nora offers a separate action that soft-deletes data imported through that connection from normal product use.

Soft deletion does not guarantee immediate physical erasure from every storage system or backup. Nora's account-wide deletion flow, permanent purge schedule, and backup-retention periods are not yet implemented in the reviewed codebase.

Administrative and third-party access

Nora is currently operated by Benjamin Ollomo. The application does not yet include a dedicated Nora support role or Nora-owned administrative console. Better Auth Infrastructure provides provider-hosted authentication audit and user or session administration capabilities; its deployed roles, access reviews, and retention settings require separate verification. Nora also relies on Plaid, Google, MongoDB, Vercel, and Brandfetch to provide specific parts of the service. A provider's certification does not mean Nora holds that certification.

No system is completely secure

No internet-connected service can guarantee absolute security. Nora does not currently claim SOC 2, ISO 27001, ISO 27701, an independent penetration test, or a similar assurance it has not completed. Security controls and operating procedures will continue to evolve with the product.

Reporting a vulnerability

Nora has not yet published a dedicated security-reporting address. Until one is confirmed, use the contact route on the support page. Include enough detail to understand and reproduce the issue, do not access or retain another person's information, and allow a reasonable opportunity to investigate before public disclosure.