Policy Overview

VeraID uses Policy-Based Access Control (PBAC) to govern how non-human identities interact with resources across your infrastructure. Unlike traditional RBAC, PBAC evaluates dynamic conditions at runtime — time of day, IP address, rate limits, and more — giving you fine-grained, context-aware control over every credential and identity.

How PBAC Works

Policies are declarative rules that define who can do what, on which resources, and under what conditions. When an identity attempts an action, VeraID evaluates all applicable policies in real time and returns an allow or deny decision.

Each policy is evaluated independently, and the results are combined using a deterministic resolution strategy where DENY always takes precedence over ALLOW.

Policy Structure

Every policy in VeraID consists of the following fields:

Field	Type	Required	Description
name	string	Yes	Unique, human-readable identifier for the policy.
description	string	No	Explanation of the policy’s purpose and scope.
priority	integer	No	Evaluation priority. Higher values are evaluated first. Default: 100.
subjects	string[]	Yes	Identities or identity groups this policy applies to.
resources	string[]	Yes	Resources or resource patterns the policy governs.
actions	string[]	Yes	Actions permitted or denied (e.g., read:*, write:secrets).
conditions	object[]	No	Runtime conditions that must be satisfied. See Policy Conditions.
effect	ALLOW | DENY	Yes	Whether the policy grants or blocks access.
isActive	boolean	No	Whether the policy is currently enforced. Default: true.

Policy Effects

Policies have one of two effects:

ALLOW

Grants access to the specified resources and actions when all conditions are met. At least one ALLOW policy must match for access to be granted.

DENY

Blocks access to the specified resources and actions. DENY always wins — if any active DENY policy matches, access is denied regardless of how many ALLOW policies also match.

Caution

A DENY policy with no conditions will unconditionally block access for matching subjects, resources, and actions. Always scope DENY policies carefully to avoid locking out legitimate workloads.

Example Policy

The following policy grants read-only access to all production resources with no additional conditions:

{
  "name": "production-read-only",
  "description": "Allow read-only access to all production resources",
  "priority": 100,
  "subjects": ["group:engineering-bots"],
  "resources": ["prod:*"],
  "actions": ["read:*"],
  "conditions": [],
  "effect": "ALLOW",
  "isActive": true
}

This policy:

• Applies to all identities in the engineering-bots group.
• Matches any resource with the prod: prefix.
• Permits any read action (read:* is a wildcard).
• Has no runtime conditions, so it is always in effect when active.
• Uses the default priority of 100.

Wildcard Patterns

Actions and resources support glob-style wildcard matching:

Pattern	Matches
read:*	Any read action (read:secrets, read:config, etc.)
*:secrets	Any action on secrets (read:secrets, write:secrets, etc.)
prod:*	Any resource prefixed with prod:
*	Everything (use with extreme caution)

Tip

Use the most specific patterns possible. A policy with actions: ["*"] and resources: ["*"] is effectively a superuser grant. Prefer narrow scopes like read:config over broad wildcards.

Policy Lifecycle

Policies follow a standard lifecycle:

1. Draft — Create and configure the policy with subjects, resources, actions, and conditions.
2. Active — Set isActive: true to begin enforcement. The policy is evaluated in real time.
3. Inactive — Set isActive: false to suspend enforcement without deleting the policy. Useful for maintenance windows or incident response.
4. Archived — Remove the policy when it is no longer needed. Archived policies are retained in the audit log for compliance.

Note

Deactivating a policy does not retroactively revoke access that was already granted. It only affects future evaluation requests.

Subjects and Groups

The subjects field accepts individual identity IDs or group references:

{
  "subjects": [
    "identity:svc-account-abc123",
    "group:ci-cd-runners",
    "group:ai-agents-tier1"
  ]
}

When a subject belongs to multiple groups, all policies for all matching groups are evaluated. This allows you to build layered access models — for example, a base read-only policy for all bots plus elevated write access for a specific deployment group.

Managing Policies via API

Policies are managed through the VeraID REST API:

# List all policies
curl -H "Authorization: Bearer $API_KEY" \
  https://app.veraid.io/api/v1/policies

# Create a new policy
curl -X POST \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "staging-full-access",
    "effect": "ALLOW",
    "subjects": ["group:staging-deployers"],
    "resources": ["staging:*"],
    "actions": ["*"],
    "conditions": []
  }' \
  https://app.veraid.io/api/v1/policies

# Deactivate a policy
curl -X PATCH \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"isActive": false}' \
  https://app.veraid.io/api/v1/policies/{policyId}

Next Steps

• Policy Conditions — Add time windows, IP restrictions, rate limits, and geo-fencing to your policies.
• Policy Evaluation — Understand how VeraID resolves multiple policies and test evaluation via the API.