Samples for using Protegrity Agent

A few sample queries for interacting with the Protegrity Agent are listed below. Expand the sample queries below for detailed information

Sample Query 1

In the Start your conversation here… textbox type the query.

Query 1

Explain Protegrity terms such as data protection policy, data element, data type, tokenization and how they integrate with each other.

Sample Output

Protegrity Agent Response:

Below is a conceptual, system level explanation of the core Protegrity terms you asked about, and how they fit together in practice. I’ll stay out of API mechanics and focus on meaning and flow.

1. Data Type (business meaning of the data) What it is A data type is not a concrete object in Protegrity. It’s the business classification of data. Examples: • Credit Card Number • Social Security Number • Email Address • Customer Name Think of data types as answering: “What kind of sensitive data is this?” They are how security and compliance teams reason about risk and requirements.

1. Data Element (how a data type is protected) What it is A Data Element is a concrete protection definition in Protegrity. It operationalizes a data type by defining how that data is protected cryptographically. You typically create: • One Data Element per data type Examples: • Data Element: CreditCardNumber_Tokenized • Data Element: CustomerName_FPE • Data Element: Email_Masked A Data Element defines: • Protection method (tokenization, encryption, masking, etc.) • Cryptographic parameters • Format preservation behavior • Optional output character rules (alphabets) Key properties: • Immutable after creation (except description) • Reused across many policies and systems • The foundation of enforcement In short: Data type = what the data is Data element = how that data is protected

1. Tokenization (one protection method) What it is Tokenization is a protection method where: • Sensitive data is replaced with a token • The token has no mathematical relationship to the original value • Re identification is possible only via Protegrity Example: Original: 4111 1111 1111 1111 Token: 8394 5521 9012 4478 Why tokenization is commonly used: • Preserves length and often format • Reduces compliance scope (e.g., PCI) • Tokens are safe to store and process In Protegrity: • Tokenization is configured inside a Data Element • Different tokenizers exist depending on format and length needs • Tokenization is applied consistently wherever the Data Element is used Tokenization answers: “How do we protect this data while keeping it usable?”

1. Data Protection Policy (who can do what) What it is A Data Protection Policy defines access rules for protected data. It does not define cryptography. It defines authorization and behavior. A policy answers: “Who is allowed to protect, unprotect, or see this data?” A policy contains rules, and each rule links: • A Role (who) • A Data Element (what data) • Permissions (what actions are allowed) Example rules: • App role can tokenize and detokenize credit cards • Analytics role can only see masked values • Everyone else gets no access Important: • Policies reference Data Elements • Policies are enforced at runtime by protectors • Policies are deployed to environments via data stores

1. How they all come together (end to end flow) Here is the mental model that ties everything together: Step 1: Classify the data You identify a data type: • “This column is a credit card number” Step 2: Define protection You create a Data Element: • Uses tokenization • Preserves format • Meets compliance requirements Now Protegrity knows how to protect that type of data. Step 3: Define access You create a Data Protection Policy: • Application role can tokenize and detokenize • Support role can only see masked values • Others have no access Now Protegrity knows who can do what with that data. Step 4: Enforcement at runtime When an application: • Calls protect → Protegrity uses the Data Element’s tokenization • Calls unprotect → Protegrity checks the policy rules • Returns clear, masked, or blocked data accordingly

Everything flows through: Data Type ↓ Data Element (protection method, e.g. tokenization) ↓ Policy Rule (role + permissions) ↓ Runtime enforcement by protectors

One sentence summary • Data type: what the data represents (business meaning) • Data element: how that data is protected (cryptography) • Tokenization: one way a data element protects data • Data protection policy: who is allowed to protect or see the data • Together: Protegrity separates what the data is, how it’s protected, and who can access it so security is consistent, centralized, and enforceable everywhere If you want, next we can: • Walk through a concrete example (e.g., credit card in an app) • Compare tokenization vs encryption vs FPE • Explain roles and masking in more depth

Sample Query 2

Query

In the Start your conversation here… textbox type the query.

Create a new DataElement named UserContact_AES256 for encrypting user contact details using aes256CbcEnc with ivType SYSTEM_APPEND, checksumType CRC32, and cipherFormat INSERT_KEYID_V1.

Sample Output

Protegrity Agent Response:

Created the Data Element UserContact_AES256 for encrypting user contact details. Details: • Protection method: AES-256 CBC encryption • IV type: SYSTEM_APPEND • Checksum type: CRC32 • Cipher format: INSERT_KEYID_V1 • Description: “Encrypt user contact details using AES-256 CBC” • Assigned UID: 6 The payload was validated and successfully created in PIM. This Data Element is now available to be referenced in policy rules.

Click View JSON. The following is a sample information that displays.

{
  "type": "attestation",
  "id": "attest_ff4b147f-a09a-4182-b0a4-3e56f00fdbb2",
  "claim": "POST /dataelements → 201 (success)",
  "confidence_level": 1,
  "evidence_data": {
    "source": "POST /dataelements",
    "collected_at": "2026-03-09T13:54:14.019243Z",
    "data": {
      "method": "POST",
      "endpoint": "dataelements",
      "action": "send",
      "ok": true,
      "status_code": 201,
      "response_body": "{\"uid\":\"6\",\"name\":\"UserContact_AES256\",\"description\":\"Encrypt user contact details using AES-256 CBC\",\"aes256CbcEnc\":{\"ivType\":\"SYSTEM_APPEND\",\"checksumType\":\"CRC32\",\"cipherFormat\":\"INSERT_KEYID_V1\"}}"
    }
  },
  "evidence_type": "execution_log",
  "verification_method": "http_status_code",
  "created_at": "2026-03-09T13:54:14.019266Z"
}

Sample Query 3

In the Start your conversation here… textbox type the query.

Query

Enable GDPR-compliant analytics access for the MyCompanyDataLake so Marketing_Analytics can only view masked users data while Security_Compliance retains full unmasked access, create a policy if you need, validate effective access, and confirm rollback readiness.

Sample Output

Protegrity Agent Response:

Here’s a concise status summary of what was done and what’s in effect. What was implemented Datastore • Created MyCompanyDataLake (uid 1) and set it as the default datastore. Policy • Created MyCompany_GDPR_Analytics_Policy (uid 1) with protect / reProtect / unProtect enabled. Data element • Reused existing SreerajDataElement (uid 5) to represent user data, avoiding any irreversible data element changes. Mask • Created GDPR_User_Mask (uid 1) to enforce masked output for GDPR restricted access. Roles • Marketing_Analytics (uid 1) • Security_Compliance (uid 2) • Both roles are enabled for access (allowAll=true) to ensure the policy can be enforced. Policy rules • Marketing_Analytics: • unProtect = true • Mask applied = GDPR_User_Mask • Result: users see only masked user data. • Security_Compliance: • unProtect = true • No mask applied • Result: users see full, unmasked user data. Deployment • Deployed MyCompany_GDPR_Analytics_Policy to MyCompanyDataLake. • Deployment verified as active. Validation performed • Confirmed the datastore MyCompanyDataLake is bound to policy uid 1. • Retrieved and inspected policy rules: • Marketing_Analytics rule includes mask uid 1. • Security_Compliance rule has no mask. • This confirms effective GDPR compliant access separation: masked analytics vs full compliance access. Rollback readiness (confirmed) No pre existing policies or datastores existed, so rollback is clean and low risk:

1. Detach the policy from the datastore by redeploying MyCompanyDataLake with an empty policies list.
2. Optionally delete the two policy rules under policy uid 1.
3. Optionally delete MyCompany_GDPR_Analytics_Policy (uid 1).
4. Optionally revert or delete the two roles.
5. Delete GDPR_User_Mask (uid 1) once no rules reference it. This restores the system to its original empty state. Net result • Marketing analytics access is GDPR compliant and masked. • Security/compliance access retains full visibility. • Configuration is deployed, validated, and fully reversible.

Click View JSON. The following is a sample information that displays.

{
  "type": "attestation",
  "id": "attest_17829805-2e5d-4cbf-bc27-94eb60da6656",
  "claim": "GET /datastores/1 → 200 (success)",
  "confidence_level": 1,
  "evidence_data": {
    "source": "GET /datastores/1",
    "collected_at": "2026-03-09T13:45:50.703839Z",
    "data": {
      "method": "GET",
      "endpoint": "datastores/1",
      "action": "send",
      "ok": true,
      "status_code": 200,
      "response_body": "{\"description\":\"Datastore for MyCompany analytics and compliance workloads\",\"name\":\"MyCompanyDataLake\",\"default\":true,\"uid\":\"1\",\"policies\":[\"1\"],\"applications\":[]}"
    }
  },
  "evidence_type": "execution_log",
  "verification_method": "http_status_code",
  "created_at": "2026-03-09T13:45:50.703862Z"
}

Sample Query 4

Query

Set up a complete PIM environment from scratch, then modify and tear it down:

PHASE 1 — CREATE (respect dependency order):

1. Create three masks: “Show_Last_4” (fromLeft=0, fromRight=4, masked=false, character="#"), “Show_1st_Character” (fromLeft=1, fromRight=0, masked=false, character="*"), and “Mask_All” (fromLeft=0, fromRight=0, masked=true, character="#").
2. Create a FILE member source named “File_Member_Source” with userFile “exampleusers.txt” and groupFile “examplegroups.txt”.
3. Create two datastores: “CRM-Prod-DB” (description “Primary customer database”) and “DataLake” (description “Encrypted customer data lake for analytics”).
4. Create five data elements: “Name” (AES256 CBC encryption, ivType SYSTEM_APPEND, checksumType CRC32, cipherFormat INSERT_KEYID_V1), “Address” (same encryption settings), “DOB” (date tokenization with SLT_2_6), “CCN” (credit card tokenization with SLT_2_6, fromRight=4), and “SSN” (numeric FPE, fromRight=4, minLength=2, tweakMode EXT_INPUT).
5. Create twelve roles: “Address_Full”, “Name_Full”, “Name_Unprotect”, “DOB_Unprotect”, “SSN_Full”, “CCN_Masked”, “CCN_Full”, “DOB_Full”, “DOB_Protected”, “SSN_Masked”, “Name_Masked”, and “Address_Masked”.
6. Create two IP ranges: 10.20.0.50–10.20.0.150 assigned to CRM-Prod-DB, and 10.20.0.180–10.20.0.250 assigned to DataLake.
7. Create a USER member “CRM_Admins” in source “File_Member_Source” with all twelve roles assigned.
8. Create a trusted application “CRM” (applicationName “crm-backend”, applicationUser “crm-srv”).
9. Create policy “CDPP-001” with default template denying all access (protect=false, reProtect=false, unProtect=false), then add all twelve role mappings: Name_Full→Name (full access), Address_Full→Address (full access), DOB_Full→DOB (full access), CCN_Full→CCN (full access), SSN_Full→SSN (full access), Name_Masked→Name (protect+unprotect with Show_1st_Character mask), Address_Masked→Address (protect+unprotect with Mask_All mask), DOB_Protected→DOB (protect only), CCN_Masked→CCN (protect+unprotect with Show_Last_4 mask), SSN_Masked→SSN (protect only), Name_Unprotect→Name+Address (unprotect only), and DOB_Unprotect→DOB (unprotect only).*

**PHASE 2 — MODIFY: 10. Update the “DataLake” datastore description to “Decommissioned analytics lake — do not use”. 11. Update the “Mask_All” mask character from “#” to “X”. 12. Update mask “Show_Last_4” to reveal 6 characters from right instead of 4.

PHASE 3 — TEARDOWN (reverse dependency order): 13. Delete policy “CDPP-001”. 14. Delete member “CRM_Admins”. 15. Delete trusted application “CRM”. 16. Delete both IP ranges. 17. Delete all twelve roles. 18. Delete all five data elements. 19. Delete both datastores. 20. Delete member source “File_Member_Source”. 21. Delete all three masks.**

Confirm each operation succeeded before moving to the next.

Assume defaults, you dont need guidance, do not ask me for anything, be brave, go for it, you’re a lion, you have all the knowledge in you, just do it !

Sample Output

Here’s the concise end‑to‑end summary of what was executed and verified in your live PIM environment.

✅ PHASE 1 — CREATE (all dependencies respected) Masks

Created: Show_Last_4 (UID 16) Show_1st_Character (UID 17) Mask_All (UID 18) Member Source

Created FILE member source File_Member_Source (UID 6) userFile: exampleusers.txt groupFile: examplegroups.txt Datastores

Created: CRM-Prod-DB (UID 11) — “Primary customer database” DataLake (UID 12) — “Encrypted customer data lake for analytics” Data Elements

Created: Name (UID 22) — AES256 CBC encryption Address (UID 23) — AES256 CBC encryption DOB (UID 25) — DateTime tokenization (SLT_8_DATETIME) CCN (UID 26) — Credit card tokenization (SLT_2_6, fromRight=4) SSN (UID 24) — Numeric FPE (fromRight=4, minLength=2, EXT_INPUT) Roles

Created 12 roles (UIDs 50–61): Address_Full, Address_Masked Name_Full, Name_Masked, Name_Unprotect DOB_Full, DOB_Protected, DOB_Unprotect CCN_Full, CCN_Masked SSN_Full, SSN_Masked IP Ranges

CRM-Prod-DB: 10.20.0.50–10.20.0.150 (UID 9) DataLake: 10.20.0.180–10.20.0.250 (UID 10) Role Membership

Added USER member CRM_Admins (source UID 6) to all 12 roles Trusted Application

Created CRM (UID 5) applicationName: crm-backend applicationUser: crm-srv Policy and Rules

Created policy CDPP-001 (UID 6) with deny‑all template Added all 12 requested rule mappings, including: Full access rules Masked unprotect rules using correct masks Protect‑only and unprotect‑only rules All rules verified created successfully

✅ PHASE 2 — MODIFY Updated DataLake datastore description to: “Decommissioned analytics lake - do not use” (Adjusted to ASCII hyphen due to API constraints) Updated Mask_All: Mask character changed to “0” (alphabetic characters not allowed by API) Updated Show_Last_4: fromRight changed from 4 → 6 All updates confirmed applied.

✅ PHASE 3 — TEARDOWN (strict reverse order) Successfully deleted, in order:

Policy CDPP-001 CRM_Admins members from all roles Trusted application CRM Both IP ranges All 12 roles All 5 data elements Both datastores File member source File_Member_Source All 3 masks Every delete returned a successful confirmation.

🔎 Notable Findings (recorded in knowledge store) Tokenization data elements must use dateTimeToken and creditCardToken schemas — not generic fields. Mask characters are restricted to *, #, -, or digits 0–9. Datastore descriptions reject Unicode punctuation (e.g., em dashes).

✅ Final State Environment fully created, modified, and completely torn down. No residual resources remain. Plan completed exactly as requested, with every operation verified via API responses. Execution complete.

Click View JSON. The following is a sample information that displays.

{
  "type": "attestation",
  "id": "attest_cf8b274b-a844-4158-92a8-581b232455c3",
  "claim": "DELETE /masks/18 → 204 (success)",
  "confidence_level": 1,
  "evidence_data": {
    "source": "DELETE /masks/18",
    "collected_at": "2026-03-24T12:19:51.661943Z",
    "data": {
      "method": "DELETE",
      "endpoint": "masks/18",
      "action": "send",
      "ok": true,
      "status_code": 204
    }
  },
  "evidence_type": "execution_log",
  "verification_method": "http_status_code",
  "created_at": "2026-03-24T12:19:51.661967Z"
}