The Security Model

MARCUS uses a standard web security model adapted for a multi-tenant clinical product. The details matter because this is not just an application that stores notes. It is an application that stores scoped evidence corpora, user conversations, and organization-specific knowledge.

The main security question is not only "who is logged in?" It is also "what data are they allowed to see, retrieve, and act on?"

Core Controls

Cookie-Based Authentication

MARCUS uses session cookies rather than bearer tokens in normal browser use. The key cookie names are:

• marcus_session_token
• marcus_refresh_token
• marcus_csrf_token

This means the browser carries session state automatically once the user has authenticated.

CSRF Protection

Mutating requests require a CSRF token. The frontend boots this token from the auth CSRF endpoint and sends it back in the X-CSRF-Token header.

This protects against cross-site request forgery, where a malicious site tries to trick a user's browser into performing an action inside MARCUS without proper intent.

Organization And Project Scoping

Data access is constrained by organization membership and then by project scope. Retrieval, source access, conversations, and project views are all expected to preserve that scope end to end.

This matters because in MARCUS, the retrieval boundary is also a security boundary.

Why Retrieval Scope Is A Security Concern

In some products, a relevance mistake is mostly an inconvenience. In MARCUS, a retrieval bug can become a data-isolation problem.

If scope widens incorrectly:

• one organization's content could appear in another organization's answers
• a user could see sources outside the intended project
• a shared answer could reveal more than intended

That is why tenant isolation and project scoping are treated as first-class security requirements, not just product organization features.

Public Versus Protected Surfaces

Public pages such as the landing page, pricing, developers page, and documentation do not require authentication.

Protected pages such as:

• projects
• chat
• library
• settings
• admin dashboards

do require the right authenticated context and, where applicable, the right organization or project membership.

Shared Content Is A Separate Security Path

Shared-answer links are intentionally distinct from ordinary app access.

That means:

• a share link is not the same thing as project membership
• the shared route should expose only the intended shared payload
• users should treat sharing as a deliberate publication action, even when the audience is small

From a security perspective, this is important because sharing loosens the normal project boundary in a controlled way.

Why CSRF Still Matters In A Modern App

Because MARCUS uses cookies in the browser, the browser will naturally send those cookies with requests. That convenience is good for normal use, but it creates a classic browser risk: a malicious page might try to trigger a state-changing request from the user's browser.

The CSRF token prevents that request from succeeding unless the request also carries the expected secret token.

Why The Frontend Proxy Matters

The frontend normally talks to the backend through a same-origin proxy. This helps keep:

• cookie behavior predictable
• CSRF handling consistent
• environment-specific routing under control

If you bypass the proxy in ad hoc integration work, you may encounter failures that are actually security or origin mismatches rather than application logic bugs.

Multi-Tenancy In Plain Language

MARCUS is a multi-tenant system. In plain language, that means multiple organizations can use the same application platform without their data mixing together.

The system needs to preserve separation across:

• organizations
• projects
• sources
• conversations
• analytics and admin views

Tenant isolation is the broader wall. Organization and project scope are the interior walls.

Security And Configuration

Several security-relevant behaviors are configuration-driven:

• cookie settings
• CSRF handling
• OAuth and SSO credentials
• environment URLs and callback behavior
• integration settings such as storage and billing

This is why centralized configuration is important. Security behavior should not be created piecemeal through scattered environment reads.

What A Security Reviewer Should Care About

If you are reviewing MARCUS at a technical or governance level, the major questions are:

1. Are sessions protected with appropriate cookie and CSRF controls?
2. Is organization and project scoping enforced server-side?
3. Are public and shared routes clearly separated from protected routes?
4. Do retrieval and answer-generation flows respect the same scope as page access?
5. Are environment and integration credentials managed centrally?

These are the questions that connect ordinary web security to MARCUS's evidence and retrieval model.

Practical Security Habits For Operators

• Use the frontend proxy for normal browser requests.
• Treat shared-answer links carefully and intentionally.
• Review organization and project membership when a user reports unexpected access.
• Verify environment configuration before assuming a strange auth or scope bug is an application defect.
• Remember that an answer showing the wrong corpus is not only a quality problem. It may be a security-scoping problem.

One Practical Summary

MARCUS security is built around three linked ideas: authenticated users, CSRF-protected actions, and strict organization and project boundaries. In this product, protecting the retrieval boundary is part of protecting the data.