Nomenclature

We have some terminology that may be entirely intuitive and some specific to the product. We have some common terms defined below.

Structure

Proxy

The most succinct definition we've found on what a proxy does is from Postman

The proxy can reside on your local machine, somewhere in your network, or at any point between your client and the destination server on the internet.

Similar to the way parents might speak to each other through a child, the child is a proxy relaying all communications between the 2 parents.

Parent 1: Ask your father if he can pick you up after school.

Timmy: Can you pick me up after school.

Parent 2: Yeah.

Timmy: Dad says yeah.

In this analogy, the child forwards the information on behalf of each parent. Besides just relaying information, proxies can do much more.

  • Record all traffic between your machine and the internet

  • Reveal the contents of all requests, responses, cookies, and headers

  • Route traffic to specified internet locations

  • Debugging

  • Security from direct attacks.

The difference between our outbound proxy and our inbound is that the inbound is static and sits between your client side and your server side, while the outbound proxy sits between your server and third parties

Organization

Shared accounts where users can collaborate across many vaults at once.

Vault

A partition for storing data within a VGS organization. An organization can have many vaults. Every vault has a unique vault ID - it’s a string value beginning with the prefix tnt, for example tntsfeqzp4a

User

An individual account that can be added to an organization, to work on a certain vault, and, forthcoming, have different defined roles.

Product Terms

Alias Formats

Alias formats define how sensitive data is transformed into secure, non-sensitive surrogates while retaining just enough structure for your application to keep working. Each format is built for a specific use case, from generic masking to payment card obfuscation and determines what parts of the original value (if any) are preserved, how the alias is structured, and whether it passes validation rules like Luhn. This guide lists all supported formats with their enum names, purposes, examples, and recommended use cases, so you can choose the right aliasing method for your data type and compliance needs.

Generic Formats

Generic – VGS Alias

  • Enum name: UUID

  • Purpose: Can be used for any piece of data; alphanumeric data is fine. Generates a surrogate value in the format tok_sandbox_xxxxxxxxxxxxxxxxxxxxxxxxx where the x's are alphanumeric characters.

  • Example: tok_sandbox_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5

Generic – Numeric Length Preserving

  • Enum name: NUM_LENGTH_PRESERVING

  • Purpose: Can be used for any number where the length must be maintained for form validation or other reasons. Does not support numbers less than 3 digits.

  • Example: 123456 → 789012

Generic – VGS Alias Last Four (T4)

  • Enum name: GENERIC_T_FOUR

  • Purpose: Can be used for any type of data. This will generate an alias with the last four characters of the original value after the alias. The length of the value could be greater or equal to 7.

  • Example: abcdef1234 → tok_sandbox_xxxxxxxxxxxxxxxxxxxxxxxxx_1234

Generic – UUID

  • Enum name: RAW_UUID

  • Purpose: Generates a UUID format alias for any type of data.

  • Example: 76b8a972-f0a7-4e87-a07f-a51c92314d56

Generic – VGS Alphanumeric Fixed Length, 29 Characters

  • Enum name: VGS_FIXED_LEN_GENERIC

  • Purpose: This format generates an alias that has a fixed length of 29 digits regardless of input. All aliases generated will have the first 3 characters as vgs. The 4th - 6th character will be the environment (ex, sbx, l01)

  • Example: vgsl0100VwAc1nxucgPiPAhUcZ3AF

Payment Card Formats

Payment Card – Format Preserving, Luhn Valid (6T4)

  • Enum name: FPE_SIX_T_FOUR

  • Purpose: For payment cards where you need to pass Luhn validation and capture both the BIN (Bank Identification Number- the first 6 digits) and last 4 digits.

  • Example: 4111111111111111 → 4111119381251111

Payment Card – Format Preserving, Luhn Valid (T4)

  • Enum name: FPE_T_FOUR

  • Purpose: For payment cards where you only need the last 4 digits and still need a Luhn-valid number, without preserving the BIN.

  • Example: 5555555555554444 → 9399630812244444

Payment Card – Prefixed, Luhn Valid, 19 Digits Fixed Length

  • Enum name: PFPT

  • Purpose: Makes it easy to distinguish surrogate values from real sensitive data.

  • Example: 4012888888881881 → 9914040119524511881. (The prefix here is 99 with 1 reserved for versioning of this format. The 4th and 5th digits represent the first two digits of the original PAN and the last four digits represent the last four from the original PAN.)

Payment Card – Format Preserving – Non Luhn Valid

  • Enum name: NON_LUHN_FPE_ALPHANUMERIC

  • Purpose: Generates a format-preserving card number that does not pass Luhn validation. Such format could be required by some processors to make sure that surrogate data is used.

  • Example: 4111111111111111 → 7858402423279985

Numeric – Include Alphanumeric, 19 Symbols Length (6T4)

  • Enum name: ALPHANUMERIC_SIX_T_FOUR

  • Purpose: Combines BIN, an alphanumeric middle section, and last 4 digits. Last character of the middle section indicates Luhn validity (V or N). Alias will be generated only if original value is numeric and length is more than 13 characters.

  • Example: 7858401234569985 → 785840aLpH4nUmVV9985. (Last character of alphanumeric part tells if original value was Luhn valid. V or N means that is was Luhn valid/not valid)

SSN Format

SSN – Format Preserving (A4)

  • Enum name: FPE_SSN_T_FOUR

  • Purpose: Preserves the last 4 digits of a Social Security Number, can be used with or without dashes.

  • Example: 567-34-5672 → 123-94-5672

Account Number Formats

Account Number – Numeric Length Preserving (A4)

  • Enum name: FPE_ACC_NUM_T_FOUR

  • Purpose: For numeric account numbers, the length of the value could range from 7 to 17, preserving the last four digits.

  • Example: 1234567890 → 9876543210

Account Number – Alphanumeric Length Preserving (A4)

  • Enum name: FPE_ALPHANUMERIC_ACC_NUM_T_FOUR

  • Purpose: For alphanumeric account numbers, the length of the value could range from 7 to 17, preserving the last four characters.

  • Example: ABC123WXYZ → XXXXXXWXYZ

Alphanumeric Formats

Alphanumeric – Length Preserving (6T4)

  • Enum name: ALPHANUMERIC_LENGTH_PRESERVING_SIX_T_FOUR

  • Purpose: Keeps the first 6 and last 4 characters intact, replacing the middle with surrogate alphanumerics.

  • Example: ABCDEF123456WXYZ → ABCDEFxxxxxxWXYZ

Alphanumeric – Length Preserving (T4)

  • Enum name: ALPHANUMERIC_LENGTH_PRESERVING_T_FOUR

  • Purpose: Preserves only the last 4 characters, replacing the rest; length unchanged.

  • Example: ABCDEFGH123456 → xxxxxxxxxxx3456

Alphanumeric – Length Preserving (1T2)

  • Enum name: ALPHANUMERIC_LENGTH_PRESERVING_ONE_T_TWO

  • Purpose: Preserves the first character and the last two characters, replacing the rest; length unchanged.-

  • Example: ABCDEFGH → AxxxxxGH

Alphanumeric – Length Preserving

  • Enum name: ALPHANUMERIC_LENGTH_PRESERVING

  • Purpose: Preserves the overall length but replaces all characters with surrogates.

  • Example: ABCDEFG1234 → XyZpLmNqRsT

WarningLength or format preserving will generate a RAW_UUID if you provide an invalid value or if you exceed the possible unique combinations of available aliases for the next formats: 1. Generic - Numeric Length Preserving 2. Payment Card - Format Preserving, Luhn Valid (T4) 3. Payment Card - Prefixed, Luhn Valid, 19 Digits Fixed Length 4. SSN - Format Preserving (A4) 5. Account Number - Numeric Length Preserving (A4) 6. Account Number - Alphanumeric Length Preserving (A4) Length or format preserving will generate a UUID if you provide an invalid value or if you exceed the possible unique combinations of available aliases for the next formats: 1. Generic - VGS Alias last 4 2. Payment Card - Format Preserving, Luhn Valid (6T4) 3. Numeric - Include Alphanumeric, 19 symbols length (6T4)

Collections

Collections are curated controls for VGS Control.

Foundation Collections are curated controls for starter-level compliance with security best practices, PCI, and SOC 2. These controls provide critical early guidance for architecting your environment for security and compliance.

Compliance Collections are comprehensive industry-standard controls for achieving compliance for regimes such as PCI and SOC 2.

Client

An entity that makes a request through the VGS platform.

Credentials

Outbound routes and all SFTP proxies are authenticated. Credentials are required to access these zones.

Filter

A set of conditions that define when data should be operated on as it passes through a Route. When the conditions are evaluated to true, then a set of operations (pipeline) is executed according to the phase.

Functions

Functions are compute operations that you code or configure to observe, process, or transform data in routes before sensitive data enters your environment or to analyze data after it is stored in your vault.

Basic Functions are pre-built operations, i.e., redact and reveal, which you configure on your content type, such as Form or JSON path.

Advanced Functions are Larky scripts that you code.

Duration applies to advanced Functions that you code in Larky and is the time your Larky function begins executing until it returns or terminates. Time is rounded up to the nearest 1 ms.

Interaction

An event of interacting with a piece of sensitive data.

  1. redact - creating an alias to remove sensitive information from the payload and replace it with a synthetic value.

  2. reveal - retrieving the alias to restore sensitive data pieces on a previously redacted payload.

  3. re-alias - adding an alias to a multi-alias entry as in different formats of representing the same value (like cc number).

  4. de-alias - removing an alias from a multi-alias entry.

  5. fingerprint - attempt to create and redact a record that already exists.

  6. delete - permanently deleting an alias.

Operation

A transformation or action on information. When a filter is matched it will apply a series of operations on the matched data.

  • OPERATIONs before the REDACT or REVEAL of the data

  • OPERATIONs after the REDACT or REVEAL of the data

Phase

Each message passed through a route has a phase.

  1. Request

  2. Response

Pipeline

A set of operations. The output of each operation in the pipeline is the input for the subsequent operation.

Record

An entry in the vault. A record has raw value, fingerprint and identifier. Identifiers present on redacted data and used to find the raw value on data revealing. Identifier can have multiple formats, currently supported record identifier formats are UUID, PDF, and FP (format preserving).

Records currently come in two varieties:

  1. Aliases - a pointer to a text-based record, often known as a token

  2. Documents - binary-based records, for example, PDFs

Redact

To remove sensitive information from the payload and replace it with a different value.

Reveal

To restore sensitive data pieces on the previously redacted payload.

Route

An endpoint exposed to a customer that allows sending data from one point to another. A Route has a source and a destination that determines the flow of traffic through the vault. Filters are then attached to the Route to determine what data is transformed and segmented as it passes through the Route.

  • Inbound route - sits in front of an upstream host and redacts, reveals, and enriches data as it passes through.

  • Outbound route - sits in the stream of traffic from a host or network and redacts, reveals, and enriches data as it passes through.

Storage

The storage value controls how aliases are stored. A persistent mode allows storing data on a permanent basis. Volatile storage has an expiration of 1 hr.

Volatile storage is used to help maintain PCI compliance by allowing you to store card security code data for only the duration of the authorization.

Target

The part of the payload passing through the proxy that will be operated on when a policy is matched (can be HEADER or BODY).

Tokenization Requests

Tokenization requests are direct invocations of VGS Tokenization APIs to create, read, delete, or update tokens in VGS Vault.

Upstream Host

The host that sits of the remote side of the route from the client who is initiating the request.

Upstream URI

Upstream host + path.

Classifiers

Data classification is broadly defined as the process of organizing data by relevant categories so that it may be used and protected more effectively.

With VGS we provide a range of methods to classify data from manually classifying when storing data via the Vault API, automatically applying classification policies via Zero Data all the way to automatically classifying using our ML based classification system.

Once data has been classified you can set policies to restrict and control access to data through our Zero Data platform.

PreviousOperationsNextAccount Updater

Last updated