Security Overview

1. Security Philosophy

RepliaOS is built around layered safeguards, tenant separation, role-based access, and clear accountability records.

The platform is intended to reduce reliance on scattered spreadsheets, inboxes, unsecured folders, and informal tracking systems by centralizing organizational work inside a permissioned environment.

2. Tenant Separation

RepliaOS is designed as a multi-tenant platform. Organization data is logically separated so users access information according to their authorized organization, unit, role, and permission scope.

Application features use tenant-aware queries, policies, and authorization checks intended to prevent one organization’s ordinary users from browsing another organization’s workspace.

Tenant isolation is also covered by automated tests for core visibility behavior, including checks that one organization’s users cannot see another organization’s matters or documents through normal application access.

3. Platform and System Administrator Access

RepliaOS includes a platform/system administrator role used to operate, support, maintain, secure, and troubleshoot the service.

A limited set of authorized platform operators may have cross-tenant access to production systems, administrative tooling, logs, support information, or customer data when reasonably necessary for purposes such as:

• Providing support
• Investigating technical issues
• Maintaining platform security
• Preventing abuse
• Performing backups, migrations, or operational maintenance
• Complying with legal obligations

Platform/system administrator access should be limited to authorized personnel and used only for legitimate operational, security, support, or legal purposes.

For more information about how information is collected, processed, retained, and disclosed, review the Privacy Policy. If RepliaOS later adds a Data Processing Agreement, that document should also describe applicable data processing commitments.

4. Role-Based Access Controls

RepliaOS uses role-based access controls to limit access based on user responsibility and organization configuration.

The platform includes role patterns such as system administrator, organization administrator, organization staff, unit administrator, unit staff, and read-only access. Access checks are applied through application policies and tenant-aware visibility services.

For write operations, tenant guardrails are used in key workflows to reject organization identifiers outside the user’s authorized scope. This helps reduce accidental or malicious cross-tenant mutations.

Organization administrators are responsible for assigning roles carefully, reviewing access regularly, and removing users who no longer need access.

Permissions should be treated as part of each customer’s internal security process, especially where sensitive labor, grievance, disciplinary, representation, or personnel-related records are stored.

5. Authentication and Sessions

User access is protected through account authentication and session management.

Where supported by the active application configuration, RepliaOS uses Laravel and Filament authentication/session middleware to manage logged-in access, session state, and protected application areas. The Filament panel uses authenticated session middleware, and the login flow is designed to regenerate the session after authentication.

RepliaOS uses server-side sessions by default through Laravel’s database session driver. Session cookies are HTTP-only by default, SameSite defaults to Lax, and secure-cookie behavior is configurable for HTTPS production deployments.

Login attempts are rate-limited by the authentication framework, and passwords are stored using Laravel’s normal password hashing rather than plaintext storage.

Users are responsible for maintaining strong passwords, protecting credentials, avoiding credential sharing, and logging out on shared or public devices.

Sessions may expire or require re-authentication based on application configuration, browser behavior, or security controls.

6. Application Security Controls

RepliaOS uses application-level protections intended to reduce common web security risks.

Current platform controls include:

• Production deployments use HTTPS/TLS
• CSRF protection for state-changing web requests, with a narrow exception for controlled load-testing endpoints
• Encrypted cookies through Laravel’s cookie middleware
• Session middleware and authentication checks for protected areas
• Role and permission checks for restricted features
• Tenant-aware authorization patterns
• Guardrails for cross-tenant writes in key workflows
• Server-side validation of submitted data
• Restricted document view and download routes requiring authentication and authorization
• File upload controls for allowed file types and maximum file size
• Parameterized database queries through Laravel’s Eloquent and Query Builder patterns for normal application use
• Generic production error pages with correlated error codes when debug mode is disabled, while details are written to application logs

Some controls depend on deployment configuration, infrastructure configuration, and ongoing application maintenance.

7. Document Storage and Upload Restrictions

Uploaded documents are intended to be served only after authentication and authorization checks.

Document viewing goes through application routes protected by authentication and document policy checks before a file is streamed. RepliaOS does not rely on handing out public object URLs for normal case-file access.

The current document system uses application-routed document access and supports a private document storage disk configuration. Legacy records may be readable from older public storage during migration periods, but new sensitive uploads are intended to use the configured document storage disk.

The platform restricts uploads by file type and size.

Default maximum upload size:

• 10 MB per file
• Config value: max_document_file_size_kb = 10240
• Environment override: DOCUMENTS_MAX_FILE_SIZE_KB, expressed in kilobytes

8. Change History and Accountability Records

RepliaOS maintains activity and change-history records intended to support accountability, troubleshooting, and incident review.

Activity records capture actor, action, record type, record identifier, and before/after field values for many core entities. Matter workflow history also records stage and process changes.

These records may include information such as:

• Who created or updated a record
• What type of record changed
• When a change occurred
• Relevant status, stage, assignment, document, note, or workflow changes

These accountability records are distinct from general operational logs and are intended to help organizations understand activity within their workspace.

9. Operational Logs and Monitoring

RepliaOS may use operational logs and monitoring to support reliability, debugging, abuse detection, and security review.

Operational logs may include technical metadata such as timestamps, IP addresses, request information, errors, and system events.

Operational logs are not intended to replace formal customer records or organization-managed audit processes.

10. Connected Gmail Integrations

Where RepliaOS supports an optional Gmail integration, access is limited to authorized email-related workflows and controlled through tenant-scoped permissions.

• Google OAuth credentials, access tokens, and refresh tokens are treated as sensitive credentials and encrypted at rest where stored.
• Access tokens are used only to carry out authorized Gmail communication workflows requested by the relevant user or organization.
• Refresh tokens are handled as high-sensitivity credentials and protected against unauthorized access.
• Integration access is tenant-scoped and permission-controlled so connected accounts are used only within the authorized organizational context.
• Administrative access to Gmail-related data is restricted to authorized personnel and is logged where applicable for support, security, and incident review.
• Connected integration traffic uses HTTPS/TLS for transmission.
• Users or administrators can revoke a connected Gmail integration through Google account permissions and, where available, through RepliaOS controls.
• Least-privilege principles are applied where practical so integration access aligns with the specific email functionality being provided.

11. Backups and Recovery

RepliaOS may use backup and recovery processes to support continuity of service.

Backups are not a substitute for each organization’s own legal, contractual, or internal recordkeeping obligations.

12. Third-Party Infrastructure

RepliaOS may rely on third-party providers for hosting, object storage, email delivery, monitoring, payments, and related services.

Where enabled, Gmail integrations also depend on Google APIs, Google OAuth, and Gmail service availability.

Security of the platform depends in part on proper configuration and operation of these third-party services.

For privacy-related details, review the Privacy Policy.

13. Customer Responsibilities

Security is a shared responsibility.

Organizations using RepliaOS are responsible for:

• Managing user access
• Assigning appropriate permissions
• Removing users who no longer require access
• Training users on confidentiality expectations
• Choosing appropriate information to store
• Maintaining required external or offline records
• Complying with applicable laws, contracts, and internal policies
• Reporting suspected security issues promptly
• Ensuring users protect passwords and devices

14. No Absolute Guarantee

No software system can guarantee complete security.

RepliaOS is designed to use reasonable safeguards, but risks such as misconfiguration, compromised credentials, software vulnerabilities, third-party outages, infrastructure failures, and user error may still occur.

15. Reporting Security Concerns

Security concerns should be reported through the official contact channel provided on the RepliaOS website.

Contact RepliaOS or return to the Legal & Policy Center.