Security

Last updated 5 August 2026

Nsesa holds the documents an organisation depends on — contracts, policies, board papers, HR files. This page describes the controls that protect them.

Tenant isolation

Every table carries row-level security tied to the company that owns the row, enforced by the database itself rather than by application code. A query that forgot to filter by company would still return nothing. No component of the application uses a privileged key that bypasses these rules: every request runs as the signed-in user, under the same policies. We maintain automated test suites that attempt cross-tenant reads and must fail.

Access control inside a workspace

Each organisation defines its own roles, with thirteen independent permissions. On top of that, any document or meeting can be restricted by category, department, seniority level, specific roles, or shared with named individuals. The same rules govern the AI: chat and search can only retrieve what that person is permitted to see, so the assistant cannot be used to summarise a document the asker has no access to.

Authentication

• Sign in with Google, Microsoft, or email and password.
• Two-factor authentication (TOTP) is available to every member. Administrators can require it for the whole workspace, and can reset a member's authenticator if they lose their device — an action that is recorded in the audit log.
• Administrators can also disable password sign-in entirely, requiring single sign-on.
• The two-factor requirement is enforced on every request to the application, not only at the login screen.

Encryption and secrets

Data is encrypted in transit and at rest. Uploaded files are held in private storage that is not publicly reachable. Credentials for connected services such as Google Drive or SharePoint are encrypted in a dedicated secrets store and are never readable through the application interface — not even by other members of the same workspace.

Application hardening

• Strict security headers across the site, with a content security policy on the authenticated application that blocks injected scripts.
• Uploads are validated server-side by both declared type and actual file signature before any parser processes them, with size limits enforced by the storage layer.
• Rate limiting on every endpoint that writes data.
• Cross-site request forgery protection on the third-party connection flows.
• Production dependencies are audited and kept free of known high-severity vulnerabilities.

Logging and retention

Administrative changes are recorded in an audit log visible to permitted roles. Errors are captured for troubleshooting. These records are purged automatically: errors after 90 days, search and chat queries after 180 days, and the audit log after 365 days.

Data residency and self-hosting

Organisations that cannot use a shared cloud can run Nsesa against a database they own, or entirely on their own premises with AI models running on their hardware. In that mode no content leaves the network, and the application fails with an error rather than silently sending data to an external provider.

Meeting recordings

The meeting assistant joins calls under a name that states it is recording, so it is visible in the participant list. The person scheduling it must confirm that participants will be informed, and we record who gave that confirmation. Customers remain responsible for meeting the notice and consent requirements that apply to them.

Reporting a vulnerability

We welcome reports from security researchers. Email security@nsesa.space with enough detail to reproduce the issue. Please give us a reasonable opportunity to fix it before disclosing publicly, and avoid accessing or modifying data that is not yours while testing. We will acknowledge your report and keep you updated on the fix.

Questions from your IT team

We can provide a full database schema and deployment guide, our subprocessor list, and a completed security questionnaire. Contact security@nsesa.space.