​
Security Overview

Polymet employs a comprehensive security model designed to protect the confidentiality and integrity of customer-submitted data, including proprietary code and project assets. Recognizing the importance of securing all managed systems and operations, Polymet applies industry-leading controls to ensure that data is shielded from unauthorized access, tampering, or disruption.

​
Threat Model

Polymet’s threat model comprehensively addresses risks across communication channels, data storage, response mechanisms, failover strategies, and more. To protect against eavesdropping, all client interactions with the Polymet service are secured through end-to-end encryption. Data integrity is preserved through continuous integrity checks; in the event of detected tampering—whether at rest or in transit—transactions are immediately aborted and alerts are raised. Rigorous authentication and authorization procedures are enforced for every inbound request, ensuring that only verified users can access protected resources. To maintain accountability, Polymet records all project-level events, including policy changes and actions performed on sensitive information, with full audit trails capturing timestamps, user identities, IP addresses, and relevant metadata. The platform also continuously monitors for anomalous activities, such as authentication attempts from unfamiliar sources, enabling early detection and response to potential threats.

​
External threat overview

Polymet’s platform is composed of several interconnected systems, including its internal APIs, storage backend, and the frontend APIs. Every interaction between these components is secured to protect customer data at all stages.

All inbound requests to the internal APIs must originate from authenticated and authorized sessions through the frontend APIs, ensuring that only verified users can access sensitive information. The storage backend, by design, is treated as an untrusted environment. To safeguard data before it enters storage, Polymet applies AES 256 encryption either on the client side or server side, depending on the operational context. Additionally, all communication between the platform and the storage backend is secured through TLS encryption, providing an extra layer of protection against unauthorized interception or tampering during transmission.

​
Internal threat overview

Within Polymet, a critical security concern is an attacker gaining access to sensitive data that they are not permitted to, especially if they already have some degree of access to the system. There are currently two authentication methods categories used by clients where we apply robust authentication and authorization logic.

​
JWT

This token category is used by users and included in requests made from the frontend APIs or elsewhere to the internal APIs.

Each token is authenticated against the API and mapped to an existing user in Polymet. If no existing user is found for the token, the request is rejected by the API. Each token assumes the permission set of the user that it is mapped to. For example, if a user corresponding to a token is not allowed access to a certain organization or code, then the token is also not valid for any requests concerning those specific resources.

​
Infrastructure

​
High availability

Polymet leverages the globally distributed, serverless infrastructure of Vercel and the high availability capabilities of its Supabase-managed PostgreSQL backend to ensure resilience, performance, and fault tolerance.

  • Vercel: Polymet’s frontend and API endpoints are deployed across Vercel’s global edge network. Incoming requests are served from the nearest geographic region, improving latency and fault tolerance. Vercel’s serverless model automatically scales on demand and routes traffic through redundant regions in the event of outages.
  • Supabase backend: Supabase is built on top of PostgreSQL and provides enterprise-grade features such as automated daily backups, point-in-time recovery (PITR), high availability (HA) configurations with automatic failover, and database replication. These features ensure that customer data remains durable and available even in the event of underlying infrastructure failures.

Together, Vercel’s edge-distributed deployment model and Supabase’s high-reliability PostgreSQL infrastructure ensure that Polymet remains consistently available and performant under varying workloads, while minimizing the risk of data loss or downtime.

​
Platform

​
Web application

Polymet utilizes the latest HTTP security headers and enforces a strict Content-Security-Policy to mitigate risks such as Cross-Site Scripting (XSS) attacks.

User authentication is federated exclusively through WorkOS, leveraging Google Single Sign-On (SSO) via OAuth 2.0 standards. After successful authentication with Google through WorkOS, Polymet issues short-lived access tokens to the client, representing the authenticated session.

  • Access tokens are securely stored in browser memory and are appended to outbound API requests that require authentication.
  • Refresh tokens are stored in HttpOnly cookies to obtain new access tokens without requiring users to manually re-authenticate.
  • All user permissions, organizational memberships, and session validations within Polymet are managed based on the federated identity information received from Google SSO.

This setup ensures a secure, streamlined, and scalable authentication flow for users accessing Polymet services through their Google accounts.

​
Employee Data Access

Whether or not Polymet employees can access data in the Polymet instance and/or storage backend depends on how you use Polymet:

When using the Polymet managed service, oversight and operational management are delegated to Polymet under strict internal policy controls. Employees are granted access to infrastructure components based on the principle of least privilege, meaning they are only allowed access to the systems necessary to perform their duties.

With respect to user-generated projects and content, Polymet employees do not make any changes to customer projects without explicit user request or user consent.

If assistance or modifications are required within a customer’s project, Polymet employees will first coordinate directly with the user to confirm approval before proceeding.

No unsolicited modifications or interventions are made to customer projects under any circumstances.

​
Third-Party Audit Status (SOC 2)

Polymet is undergoing a SOC 2 Type I audit, with a completion date targeted for Q2 2025. The audit scope includes:

  • Encryption and access control
  • Change management
  • Monitoring and alerting systems
  • Employee onboarding/offboarding
  • Incident response planning
  • Vendor security assessments

We will share the SOC 2 Type I report with enterprise customers under NDA upon completion.

​
Incident Response Actions

Polymet maintains a formal Incident Response Plan designed to address and mitigate security incidents in a timely and transparent manner. In the event of a confirmed incident, affected customers are notified within 24 hours. Where required by applicable regulations—such as Article 33 of the GDPR—relevant supervisory authorities are informed within 72 hours. Throughout the investigation, Polymet provides ongoing updates and shares a detailed root cause analysis upon resolution.

​
Get in touch

If you have any concerns about Polymet or believe you have uncovered a vulnerability, please get in touch via the e-mail address info@polymet.ai. In the message, try to provide a description of the issue and ideally a way of reproducing it. The security team will get back to you as soon as possible.