The Security Model

MARCUS uses a standard web security model adapted for a multi-tenant institutional product. The details matter because MARCUS stores scoped evidence libraries, 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?"

Current data boundary: These controls do not create a PHI lane or prove a compliance certification. MARCUS is an institutional non-PHI workspace. Do not enter patient identifiers, patient-specific clinical facts, PHI, credentials, secrets, or other prohibited data.

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, where applicable, project access. Retrieval and source routes check the authenticated organization and project context.

The exact project-membership policy is deployment-dependent. Some workspaces permit broad same-organization project access, while others enforce explicit assignments. Do not assume that a project is private because it has a member list.

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
• conversations
• 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

The current answer share is a public, read-only snapshot. Anyone with the valid link may be able to see the shared question, answer, and citation labels. It does not grant project-document access.

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 it also carries the expected matching 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 use the same application platform, and the application is designed to keep their data separated.

The system needs to preserve separation across:

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

Organization isolation is the primary user-visible boundary. Project scope adds a narrower work context according to the active deployment policy.

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
• project-membership enforcement and feature availability

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 scoping enforced server-side, and which project-membership policy is active?
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 membership, project access, and the deployment's project-membership policy 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 library is not only a quality problem. It may be a security-scoping problem.

One Practical Summary

MARCUS security is built around authenticated users, CSRF-protected actions, organization separation, and project-aware access checks. These controls support scoped evidence review, but they do not authorize PHI use or establish a compliance certification.

Continue

• Clinician handbook: Workspace and Access
• Safety: Safe Use and Limitations