Security

MERGEguard interacts directly with client contact data inside Clio. The system is designed to minimize risk by limiting when data is written, isolating tenant data, and requiring explicit user intent before any destructive action.

This page outlines the controls in place across application logic, authentication, storage, and infrastructure.

Read-only by default

All scan operations are read-only.

MERGEguard retrieves contact data from Clio, analyzes it for duplication patterns, and stores results for review. No writes occur during scanning.

The first write to Clio only occurs when a user explicitly selects records and confirms Process merges.

Controlled write model

MERGEguard does not perform automatic merges or background data modification.

Each merge requires:

• •Selection of a keeper record
• •Explicit selection of merge candidates
• •Final confirmation before execution

No scheduled jobs or background processes modify Clio data.

Pre-merge snapshot system

Before any merge is executed, MERGEguard captures a full snapshot of the record being merged.

Snapshot scope includes:

• •Contact fields
• •Notes
• •Communications
• •Documents
• •Custom fields
• •Relationships

Snapshots are stored separately from active records and retained for 90 days.

If a merge outcome needs to be reversed, the snapshot can be used to reconstruct the original record state.

Audit logging

MERGEguard maintains an audit trail for merge activity.

Each merge records:

• •Acting user
• •Timestamp
• •Keeper record
• •Merged records
• •Outcome status (success or failure)

Audit data is retained independently from application logs and is designed to support review and reconstruction of actions taken.

Authentication and session security

• •Passkeys (WebAuthn) are the default authentication method
• •Optional MFA methods: TOTP, SMS, or email OTP
• •Passwords are hashed with bcrypt (cost factor 12)

Session controls:

• •httpOnly cookies
• •Secure flag in production
• •SameSite=Lax
• •Session rotation after MFA verification

Protection mechanisms:

• •Login attempts are rate-limited per account and per IP
• •Repeated failures trigger a Cloudflare Turnstile challenge

Merge authorization

Merge execution requires recent second-factor verification.

A valid session alone is not sufficient to perform destructive actions.

Clio OAuth token handling

Clio access and refresh tokens are stored in Supabase Vault.

• •Encrypted at rest using pgsodium-backed key management
• •Encryption keys are not stored alongside application data
• •Tokens are never exposed to the client or stored in plaintext

Vault access is restricted to server-side service-role execution.

When Clio is disconnected, associated vault entries are permanently deleted.

Data isolation and access control

MERGEguard is a multi-tenant system with strict per-firm isolation.

• •Every record is scoped by firm_id
• •All queries enforce firm-level filtering
• •Row-level security (RLS) is enabled on all tables
• •Client-side access uses a restricted anonymous key
• •Server-side operations use a service-role key not exposed to the client

Sensitive database functions are not callable from client contexts.

Infrastructure and hosting

• •Application hosted on Vercel (US region)
• •Database hosted on Supabase Postgres (US region)
• •All traffic encrypted via HTTPS (TLS 1.2+)

Operational controls:

• •Daily automated backups with 7-day retention
• •Environment variables used for secret management
• •No secrets stored in source code or client bundles

Logging and observability

MERGEguard records operational events for debugging and system health.

To reduce exposure:

• •IP addresses and email addresses are hashed using salted SHA-256
• •Logs are structured to avoid storing raw identifiers

User-facing errors do not expose internal system details. Detailed diagnostics are retained internally.

Failure handling and data safety

MERGEguard is designed to fail safely.

• •If a snapshot cannot be created, the merge does not run
• •If any step of a merge fails, the operation stops before partial data loss
• •No destructive action proceeds without required preconditions

This prevents incomplete merges and reduces the risk of inconsistent data states.

Webhook security

Incoming webhooks are verified before processing.

• •Stripe events are validated using signature verification
• •Requests that fail verification are rejected before any logic runs

Rate limiting and abuse protection

• •Login attempts are rate-limited per account and per IP
• •OTP requests are throttled per user and per IP
• •Scan execution is limited to one active job per firm

Additional limits may be introduced as usage scales.

Data usage and privacy

MERGEguard does not use customer data for:

• •Advertising
• •Marketing analytics
• •Model training
• •Resale or third-party sharing

Data is used strictly to operate the service.

What MERGEguard does not do

• •No automatic merges
• •No background data modification
• •No access outside your firm’s data scope
• •No silent changes to Clio records

All data changes are explicit and user-initiated.

Compliance and certifications

MERGEguard does not currently maintain SOC 2 or ISO 27001 certification.

Security practices are implemented directly in the system architecture.

Security philosophy

No system is perfectly secure.

MERGEguard is designed to:

• •Minimize write operations
• •Require explicit user intent
• •Isolate tenant data
• •Limit exposure of sensitive data
• •Fail safely when conditions are not met
• •Maintain auditability of actions

Reporting a vulnerability

Security issues can be reported to:

security@tlbcloud.net

Reports are acknowledged within one business day.

Please do not disclose vulnerabilities publicly.