Data Policy

For Overmind Platform

Your data is important to us

As a service provider, we understand the importance of providing clear information about our security practices, tools, resources, and responsibilities within Overmind so that our customers can feel confident in choosing us as a trusted service provider.
Dylan Ratcliffe
Dylan Ratcliffe
CEO, Founder, Overmind
Header image

Access we need

AWS: Overmind requires read only access to your AWS accounts. This is achieved using an IAM role that uses the “AWS Account” trusted entity type along with an external ID to allow Overmind to read from the required AWS APIs.

The required permissions are documented here:

Kubernetes: Overmind needs “Get”, “List” and “Watch” permissions for all resources in a cluster. This is configured automatically using a ClusterRole. These permissions are then applied via ServiceAccount to the Overmind agent which runs anywhere in the cluster.

If required Overmind can be configured with fewer permissions on an account-by-account or cluster-by-cluster basis, but this will limit functionality.


What we gather:

AWS: The output of the “Get” or “Describe” API action for each supported type e.g. 

Kubernetes: The details of all kubernetes objects. This is the same data that would be returned from “kubectl get {object}”

What we do with it

Overmind is purely graph based. We don’t need to scan your infrastructure and store it in a database. Our data gathering is done on-demand.

The obvious things we store are:

Snapshots of your infrastructure that you create (items and their attributes) so that we can show you what changed.

The definitions of apps that you create:

  • User details, configuration etc.
  • We do however store one thing other than the obvious: A cache of the last-discovered topology of your infrastructure. It includes the names and relationships of all items, but not the actual attributes.

How long we hold them:

  • Topology cache: 1 week
  • Snapshots of changes: Until you delete them

All other data: While you’re a customer (or design partner)


We’re ops people at heart, we care about things being architected and run properly. To that end Overmind employs a partial isolation model to protect against attacks. Some infrastructure is shared, but each “source” (the part of Overmind that can access your AWS) is run in an isolated environment (a container) with per-customer partitioning at the AWS, application and messaging layer.

Need further information?

If you require any further information regarding out data policies please feel free to get in touch.

Join our Discord!