Security and Trust Center

{{overview-content}}

Trusted Platform

Compliance

We are committed to implementing up to date and industry-leading practices in how we build at Robust Intelligence. Currently, we are SOC 2 Type II compliant and regularly perform penetration testing evaluations. You can request the latest copies of our audit certificates here.

Incident Response

Robust intelligence implements a team to respond to incidents as well as policies and procedures in place to guide personnel in reporting and responding to information technology incidents. Incident response procedures are in place to identify, and respond to incidents on the network. For incidents of applicable severity, we have a patch management process in place to ensure patches to the software are properly and securely applied.

Software Development Lifecycle (SDLC)

We leverage various tools for package vulnerability detection during development and release, employee device and access management, and intrusion detection. Overall, we follow SOC 2 Type II procedures for our SDLC.

Security Features

Data Encryption

Data at rest is server-side encrypted with AES-256.

We enforce TLS encryption in transit for client-server communications, such as between our SDK and the Control Plane, or between an externally deployed Agent and the Control Plane. TLS can also be configured internally, encrypting communication channels within a cluster itself, with each microservice carrying its own certificate. This intra-cluster security can be further enhanced with automatically rotating certificates.

Sensitive customer information, such as private keys or access credentials needed to integrate into customer data pipelines, is stored securely in a vault.

Authentication

Web client access requires authentication via user email and password, with the ability to integrate your SSO provider via OIDC. All API connections require temporary access tokens, which are controlled by administrators. You can also enable the auto logout feature based on your security preferences.

Authorization

All user actions are governed by Role-Based Access Control (RBAC), which administrators alone can modify. Teams are separated into workspaces to isolate information across organizations. Additionally, all user actions are tracked in audit logs that administrators can view.

Data Handling

We process model training and testing data in order to evaluate machine learning model performance. Data is stored in AWS encrypted volumes and backed up daily to an encrypted S3 bucket. All backups are encrypted using the KMS-managed encryption keys, with access restricted to key personnel via AWS IAM permissions.

We securely dispose of data that is no longer needed.

Architecture

Cloud Deployment Overview

The model testing agent is deployed through a single Helm chart in your Kubernetes environment. We are also happy to work with your team to design a solution.

Data Storage and Transmission

Data at rest is server-side encrypted with AES-256.

TLS encryption is enforced in transit in client-server communications, such as between our SDK and the Control Plane, or between an externally deployed Agent and the Control Plane. TLS can also be configured internally, encrypting communication channels within a cluster itself, with each microservice carrying its own certificate. This intra-cluster security can be further enhanced with automatically rotating certificates.

Data Flow

Let’s illustrate data flow with a basic example.

The process begins with providing inputs to your agent: training/testing data, prediction logs, and optionally the model itself (for query-based testing). By default, these inputs will come from  object storage in your cloud environment, but the agent can pull from a variety of sources (such as Databricks Delta Lake). Once connectivity to the input source(s) is established, data scientists can begin using the agent.

To verify if a model is safe for production, a data scientist submits Stress Testing or Continuous Testing jobs to the RI control plane (manually or programmatically). In this request, the data scientist must specify which datasets or data sources to use. The agent will execute this request, submitting status updates to the control plane for the user to view.

As testing ensues, the agent compiles the various scores and aggregate metrics into a set of test results. Upon completion, these results are sent over an encrypted TLS connection to the control plane, where the data scientist can begin analyzing them via the web client.

The data scientist can continue their observability practice by activating an automated Continuous Testing pipeline, which performs the exact same testing process against incremental data and real-time predictions. For even more scrutiny, the data scientist can elect to send failing data points to the control plane.