ModelCop/Legal/Security
Trust by design

Security

Secure by design, and built to prove every claim. Tenant isolation at the database kernel, encryption everywhere, and disaster recovery validated end-to-end.

Effective May 2026Version 1.0ModelCop LLC · Texas

00Posture at a glance

ModelCop is built to a secure-by-design, prove-every-claim standard. Isolation boundaries, alerting, and recovery procedures are verified — not just diagrammed.

3 layers
Independent tenant-isolation controls, each sufficient on its own
< 5 min
Recovery point objective (continuous PITR backup)
~12 min
Recovery time objective — validated end-to-end
AES-256
Encryption at rest; TLS 1.2/1.3 in transit

01Tenant isolation

ModelCop is multi-tenant at the application layer but enforces tenant boundaries at the database layer, with multiple independent mechanisms so that no single application bug can cross a tenant boundary.

1

Application

Tenant context is strict and request-scoped. Any code path that reaches the database without an active tenant raises an explicit error rather than defaulting to one.

2

Database role

The app connects under a dedicated, least-privilege role that cannot bypass row-level security. The administrative role is used only for migrations — never to serve application traffic.

3

Database engine

Every tenant-scoped table enforces PostgreSQL Row-Level Security with force enabled, so the engine itself refuses rows outside the active tenant.

An automated isolation test suite runs on every deploy — verifying role attributes, RLS state on all tenant tables, and that one tenant's rows are never visible under another tenant's context. The same isolation is verified to survive a point-in-time restore.

02Defense in depth

LayerControls
NetworkVPC-isolated; application and database in private subnets with no public IPs. A single load balancer is internet-facing, behind a managed web application firewall (OWASP, known-bad-inputs, and SQLi rule sets).
TransportTLS 1.2/1.3 only; older protocols rejected. HTTP is redirected to HTTPS; plaintext is never served. Certificates auto-renew.
ApplicationOIDC single sign-on (no password storage), hardened session cookies (HttpOnly, Secure, SameSite), and secrets held in a managed, KMS-backed store — never in code.

03Data protection

  • At rest: database storage encrypted with AES-256; object storage encrypted with public access blocked at the account level.
  • In transit: HTTPS externally and encrypted, certificate-verified connections to the database.
  • Backups: continuous point-in-time recovery with 7-day retention; deletion protection enabled on the database cluster.
  • Secrets: credentials and signing keys live in a managed secret store, read at runtime via scoped IAM roles, and are rotatable.

04Monitoring, detection & response

Management-plane activity, network flow logs, database logs, and application logs are captured to dedicated, access-controlled stores. Continuous threat detection is enabled, and real-time rules route critical events — root-account use, IAM and security-group changes, threat-detection findings, and failed sign-ins — for review. Image vulnerability scanning runs on every build.

05Disaster recovery

Recovery is validated end-to-end, not merely configured. A point-in-time restore exercise — new cluster, schema and role verification, tenant-isolation check, and teardown — was completed in May 2026 with all verification criteria passing, achieving the objectives below. We re-validate on a recurring schedule and after major infrastructure changes.

RPO < 5 min
Continuous, sub-minute-granularity backup
RTO ~12 min
Measured restore-to-available in the validation run

06Vulnerability management

Container images are scanned on every push; the current image carries no critical, high, medium, or low findings. Dependencies are pinned and reviewed before merge. Infrastructure is managed as code with state reconciled against reality. A third-party penetration test is planned post-launch.

07Compliance posture

We are explicit about what is in place today versus on the roadmap.

ItemStatusDetail
Encryption & isolationLiveAES-256 at rest, TLS in transit, 3-layer tenant isolation
Audit & threat detectionLiveManagement-plane audit log, flow logs, threat detection
SOC 2 Type IIIn progressReadiness underway; target Q4 2026
ISO/IEC 42001In observationAI-management-system controls implemented
HIPAA-eligible architectureAvailable on enterpriseBAA available; architecture structured for PHI workloads
GDPR data-subject rightsLivePer-tenant export and deletion
Third-party pen-test reportPlannedScheduled post-launch
FedRAMPNot plannedOut of scope at this stage

Under the cloud shared-responsibility model, ModelCop owns everything above the hypervisor; the infrastructure provider secures the underlying platform. The full security overview and questionnaire responses are available to prospects under NDA.

08Responsible disclosure

Found something? Tell us.

We welcome reports from security researchers. Act in good faith, don't access data that isn't yours or degrade the service, and we'll treat your research as authorized. We acknowledge reports within 24 hours and update every 7 days until resolution.