Skip to content
Arbitex Docs

Entity Type Split & Policy Packs

Entity Type Split & Policy Packs

Section titled “Entity Type Split & Policy Packs”

Arbitex DLP originally classified all detected credentials under a single shared entity type api_key. This made it impossible to write fine-grained policies per credential kind. The entity type split introduces 39 individual entity types organized into 7 sub-groups, enabling precise policy control per secret pattern.

Why the Split

Section titled “Why the Split”

The legacy model treated every detected secret as api_key, which meant you could not differentiate AWS access keys from GitHub tokens from Slack webhooks. All secrets shared the same policy action, the same accuracy metrics, and the same false positive rate.

The entity type split addresses this directly:

  • Per-entity policies: Apply BLOCK to payment keys, PROMPT for monitoring tokens, AUDIT for communication webhooks — all independently configured.
  • Per-entity accuracy metrics: Precision and recall are tracked separately per type, allowing you to see which detectors are performing well and which need tuning.
  • Per-entity FP rate tracking: High false positive rates on one type no longer pollute aggregate accuracy numbers for unrelated types.
  • Compliance mapping: Specific credential types map to specific regulatory requirements — PCI-DSS cares about payment keys, HIPAA cares about health system credentials — making framework coverage explicit.
  • Backward compatibility: The legacy api_key type is still accepted in API calls and auto-maps to the appropriate individual type during scan resolution.

Entity Types

Section titled “Entity Types”

The 39 Individual Types

Section titled “The 39 Individual Types”
Entity Type Display Name Sub-Group
aws_access_key AWS Access Key Cloud Provider Keys
aws_secret_key AWS Secret Key Cloud Provider Keys
gcp_service_account GCP Service Account Key Cloud Provider Keys
gcp_api_key GCP API Key Cloud Provider Keys
azure_client_secret Azure Client Secret Cloud Provider Keys
azure_storage_key Azure Storage Account Key Cloud Provider Keys
digitalocean_token DigitalOcean Personal Access Token Cloud Provider Keys
github_pat GitHub Personal Access Token Source Control & CI/CD
github_oauth GitHub OAuth Token Source Control & CI/CD
gitlab_pat GitLab Personal Access Token Source Control & CI/CD
gitlab_pipeline_token GitLab Pipeline Trigger Token Source Control & CI/CD
bitbucket_app_password Bitbucket App Password Source Control & CI/CD
jenkins_api_token Jenkins API Token Source Control & CI/CD
circleci_token CircleCI API Token Source Control & CI/CD
slack_bot_token Slack Bot Token Communication
slack_webhook_url Slack Incoming Webhook URL Communication
slack_user_token Slack User Token Communication
discord_bot_token Discord Bot Token Communication
teams_webhook_url Microsoft Teams Webhook URL Communication
postgres_connection_string PostgreSQL Connection String Database & Storage
mysql_connection_string MySQL Connection String Database & Storage
mongodb_connection_string MongoDB Connection String Database & Storage
redis_url Redis Connection URL Database & Storage
s3_presigned_url AWS S3 Pre-signed URL Database & Storage
stripe_secret_key Stripe Secret Key Payment & Financial
stripe_publishable_key Stripe Publishable Key Payment & Financial
square_access_token Square Access Token Payment & Financial
paypal_client_secret PayPal Client Secret Payment & Financial
datadog_api_key Datadog API Key Infrastructure & Monitoring
newrelic_license_key New Relic License Key Infrastructure & Monitoring
pagerduty_api_key PagerDuty API Key Infrastructure & Monitoring
sendgrid_api_key SendGrid API Key Infrastructure & Monitoring
twilio_auth_token Twilio Auth Token Infrastructure & Monitoring
mailgun_api_key Mailgun API Key Infrastructure & Monitoring
okta_api_token Okta API Token Identity & Auth
auth0_client_secret Auth0 Client Secret Identity & Auth
jwt_signing_key JWT Signing Key (HMAC) Identity & Auth
private_key_rsa RSA Private Key Identity & Auth
private_key_ec EC Private Key Identity & Auth

The 7 Sub-Groups

Section titled “The 7 Sub-Groups”
Sub-Group Count Example Types
Cloud Provider Keys 7 aws_access_key, gcp_api_key, azure_client_secret
Source Control & CI/CD 7 github_pat, gitlab_pat, jenkins_api_token
Communication 5 slack_bot_token, discord_bot_token, teams_webhook_url
Database & Storage 5 postgres_connection_string, redis_url, s3_presigned_url
Payment & Financial 4 stripe_secret_key, square_access_token, paypal_client_secret
Infrastructure & Monitoring 6 datadog_api_key, twilio_auth_token, sendgrid_api_key
Identity & Auth 5 okta_api_token, jwt_signing_key, private_key_rsa

Policy Packs

Section titled “Policy Packs”

A policy pack is a named collection of entity-level rules that can be applied to an organization. Rather than configuring each of the 39 entity types individually from scratch, a policy pack gives you a baseline you can apply in one step and then customize.

Naming conventions are enforced to keep the pack catalog readable:

  • Regulatory packs: named after the framework they target — e.g., PCI-DSS, HIPAA, SOX, GDPR, SOC 2.
  • Non-regulatory packs: follow the pattern Arbitex {Domain} - {Label} — e.g., Arbitex Cloud - Strict, Arbitex Communication - Audit Only, Arbitex Financial - Block All.

Arbitex Credential Policy Pack

Section titled “Arbitex Credential Policy Pack”

The Arbitex Credential pack is the default policy pack shipped with every new organization. It covers all 39 entity types with sensible defaults organized by sub-group risk level.

Sub-Group Default Action Rationale
Cloud Provider Keys BLOCK Highest blast radius — leaked cloud keys enable full infrastructure compromise
Source Control & CI/CD BLOCK Source code access enables supply chain attacks
Communication PROMPT Lower immediate risk but can expose internal communications
Database & Storage BLOCK Direct data access — connection strings expose databases
Payment & Financial BLOCK Financial liability and PCI-DSS compliance requirement
Infrastructure & Monitoring PROMPT Monitoring tokens have read-heavy access; lower write risk
Identity & Auth BLOCK Private keys and auth secrets enable impersonation

Creating Custom Policy Packs

Section titled “Creating Custom Policy Packs”

To create a new policy pack from the admin UI:

  1. Navigate to Settings → Policy Packs.
  2. Click Create Pack or Clone an existing pack to start from a known baseline.
  3. Name the pack following the naming convention appropriate for your use case.
  4. Set per-entity-type actions for each of the 39 types: BLOCK, PROMPT, ALLOW_WITH_OVERRIDE, ALLOW, or AUDIT.
  5. Assign the pack to one or more organizations.

Admin UI Management

Section titled “Admin UI Management”

Viewing Entity Types

Section titled “Viewing Entity Types”

Navigate to Settings → Entity Types to see all 39 types grouped by sub-group. Each row in the list shows:

  • Code name (e.g., aws_access_key)
  • Display name (e.g., AWS Access Key)
  • Sub-group
  • Current policy action from the applied pack
  • Detection count over the last 30 days

Editing Policy Actions Per Entity

Section titled “Editing Policy Actions Per Entity”

Click any entity type to open its detail view. From there you can:

  • Change the policy action (BLOCK / PROMPT / ALLOW_WITH_OVERRIDE / ALLOW / AUDIT)
  • View historical detection counts and false positive rates
  • See which policy packs reference this entity type

Changes apply to scans going forward. Existing audit records are not retroactively modified.

Bulk Operations

Section titled “Bulk Operations”

The entity type list supports multi-select:

  • Select multiple entity types using the checkboxes on each row.
  • Use the Apply Action control that appears in the toolbar to set a single action across all selected types.
  • This is the fastest way to apply a sub-group-wide policy change without editing each type individually.

Migration from Legacy api_key

Section titled “Migration from Legacy api_key”

How Legacy Mapping Works

Section titled “How Legacy Mapping Works”

The system preserves backward compatibility through a resolution chain:

  • API calls using entity_type: "api_key" are accepted without error.
  • The system auto-resolves to the specific entity type during scan processing based on the matched pattern.
  • Legacy policy rules targeting api_key apply as a fallback when no specific entity rule exists for the resolved type.
  • Priority order: specific entity type rule > legacy api_key fallback > org default action.

This means existing enforcement does not break on upgrade, but you lose the precision benefits of the split until you migrate.

Migration Steps

Section titled “Migration Steps”
  1. Audit current policies: Review all rules in Settings → Policy Rules that reference the api_key entity type.
  2. Apply a policy pack: Assign the Arbitex Credential pack (or a clone of it) to your organization. This creates specific rules for all 39 entity types.
  3. Test with AUDIT mode: Set new entity-specific rules to AUDIT first to observe detections without affecting user traffic. Confirm that the right types are firing.
  4. Promote to enforcement: Once you are confident in the classification accuracy, switch entity rules from AUDIT to BLOCK or PROMPT as appropriate for each type.
  5. Remove legacy rules: Delete the old api_key rules once all 39 types have explicit rules in place. The fallback path is no longer needed.
  6. Verify in scan results: Check recent scan results in Audit Logs to confirm that detections are attributed to individual entity types rather than the legacy api_key.
Section titled “Related Resources”