Product Overview

Antimatter lets you control data, wherever it lies, by encapsulating that data into an encrypted capsule and configuring what classification happens when the data is written and what transformation or access control happens when the data is read.

In other words, using Antimatter consists of four steps:

1. Create or log into a domain.
2. Encapsulate your data using the Antimatter library (see Libraries), specifying a write-context that configures which classification to perform on the data. See Write Contexts.
3. Store the capsule wherever you want: file, S3 bucket, SQL database, vector DB etc.
4. Load the capsule using the Antimatter library, specifying a read-context that configures what filtering and redaction to do on the data. See Read Contexts.

Sometimes, you just need to classify and immediately transform the data (without storing it anywhere). In that case, just skip step 3. Antimatter supports streaming classification and redaction, so you don't actually need to materialize a capsule on disk or in memory in order to use the data transformation features.

Domains

A domain is the main "account" primitive in Antimatter. Most API calls occur within a domain, and require authentication with the identity providers configured within a domain. A domain is a logical grouping of data – a capsule is always associated with a domain and the read and write contexts used to interact with capsules are also configured within a domain.

Similarly, the capsule manifest (list of all capsules) and audit logs are also per domain.

Note that there is a peering mechanism (see Peering) that lets you share most resources with other domains, but nevertheless, everything always exists in one domain and is only imported by others.

Antimatter Web App

The Antimatter web UI can be a convenient way of interacting with your domains. When you first navigate to the web app, you will be asked to pick an email address to log in with. This email does not need to be the same identity you will use for logging in to your domains, this is your "global" identity that is merely used to store your list of "favorite domains" which appears on the left hand side of the screen. Whenever you interact with one of those domains, you may be prompted to log in with an identity that is correct for that domain - you can use different emails with different domains.

Domains created through the language libraries or API are not automatically added to your favorite domains, but you can easily add them by clicking "Import Domain" (or the + icon in the favorites list). Note that whether you have permission to access a domain or not is completely independent of your favorite domain list. You can add any domain to your favorites, regardless of if you have access to it or not. Similarly, someone could add you as a principal to a domain, giving you access, but that does not make it automatically show up in the favorite domains list.

Write contexts

A write context defines which classification (if any) should run on a capsule when it is encapsulated. When creating a capsule, a write context must always be given.

There are two write-contexts that exist by default in a newly created domain:

• default: does not execute any hooks on the data
• sensitive: classifies the data with the data-structure-classifier and the fast-pii classifier.

If you would like to use one of the other classifiers (such as the regex-classifier or the accurate-pii classifier), see the Write Context documentation for how to create and edit write contexts.

Read contexts

A read context defines a set of access control and data transformation rules that apply when a capsule is read. When loading a capsule, a read context must always be given.

There is one read context that exists by default in a newly created domain:

• default: performs no transformation on the read data

Capsules and Tags

A capsule is an encrypted object that you create using the Antimatter encapsulate calls available in the different language libraries and plugins. The capsule contains both the data that was encapsulated and any tags that were added manually or by classifiers.

A Tag is used to capture what data is, so it can later be controlled by "data-defined policy" that is expressed more in terms of what data is, rather than where it is. This helps policy remain agnostic to the location or system that data happens to be stored in.

A tag consists of a name e.g. tag.antimatter.io/pii/email_address and optionally a value. The value is not the data bearing the tag, but rather is used for custom tags that need an additional value to have meaning. For example mycompany.com/ad-group=staff where "ad-group" doesn't mean anything by itself, but "ad-group=staff" is useful in defining policy. The value can also be a date, which is useful when defining policy that enforced data expiration. See your language reference for more information about the structure of tags.

Note that a tag name is usually specified as "some.domain.com/some/uri" where the domain is a domain you control. This is done to avoid accidental name collisions where two parties apply a tag with the same name but different meanings. Antimatter classifiers (other than the regex classifier which permits custom tags) will always emit tags starting with tag.antimatter.io.

Tags can be applied to entire capsules, in which case they are called capsule tags, or they can be applied to columns, rows or phrases within the encapsulated data, where they are called span tags. Capsule tags are always stored on the server so that you can see all the capsule tags in the capsule manifest. In contrast, only a summary of the span tags is stored in the manifest - the full set of span tags is only available in the capsule when opening it. Both capsule and span tags can be referenced by read-context policy rules.

See the Capsules section for more information.