Skip to main content

Policy Testing

This collection of commands helps you test and validate your authorization policies.

permit test run audit​

This command reads your recent authorization decision logs from the Permit API and runs the same checks against a PDP instance to verify consistency between environments.

The command is particularly useful for validating that policy changes don't break existing authorization behavior and for testing a new PDP instance against production decisions.

Arguments (Optional)

  • --api-key <string> - API Key to be used for test generation.
  • --pdp-url <string> - URL of the PDP to verify against (default: http://localhost:7766)
  • --time-frame <number> - Number of hours to fetch audit logs for (Between 6 and 72, default: 24)
  • --source-pdp <string> - ID of the PDP to filter audit logs from
  • --users <string[]> - Filter logs by specific users (can provide multiple)
  • --resources <string[]> - Filter logs by specific resources (can provide multiple)
  • --tenant <string> - Filter logs by specific tenant
  • --action <string> - Filter logs by specific action
  • --decision <allow | deny> - Filter logs by decision outcome
  • --max-logs <number> - Maximum number of logs to process (useful for limiting large audit operations)

Examples:

Basic test against local PDP using the last 24 hours of audit logs:

$ permit test run audit --pdp-url <http://localhost:7766>

Testing against custom PDP URL with filters:

$ permit test run audit --pdpUrl <http://my-pdp.example.com:7766> --timeFrame 48 --action read --decision allow

Testing with multiple users and resources:

$ permit test run audit --users john@example.com alice@example.com --resources document:123 folder:456

Testing with a limit on the number of logs processed:

$ permit test run audit --max-logs 500

Execute E2E tests​

Simulate real-world user interactions and business flows to see how policies affect overall application behavior.

permit test generate e2e​

Generate end‑to‑end test configurations (and optionally test data) for your policy.

Arguments (Optional):

  • --api-key <string> - API Key to be used for test generation.
  • --dry-run <boolean> - If set, generates test cases and mock data without making any changes in Permit.
  • --models <string_array> - List of model names to generate tests for. default: RBAC.
  • --path <string> - Filesystem path where the generated JSON config should be saved (recommended).

Note: All flags are optional. If you omit --models, only the default RBAC model will be processed. If you omit --dry-run, real data and users will be created in Permit.

Examples:

Generate tests for the default RBAC model, and save the config to disk. Creates end‑to‑end tests for the RBAC model and writes the generated JSON config to logb.json

  $ permit test generate e2e --models=RBAC --path=logb.json

Generate tests for RBAC, save the config, but don't apply changes (dry run). This is the same as above, but in dry‑run mode, so no changes are made in Permit.

  $ permit test generate e2e --models=RBAC --path=logb.json --dry-run

Generate tests for the RBAC model without saving the config (dry run). This function generates test cases and mock data for RBAC, does not save a config file or apply changes, and prints to the terminal.

  $ permit test generate e2e --models=RBAC --dry-run

Generate and apply tests for the RBAC model with default settings. Runs end‑to‑end test generation for RBAC using real data (no dry run) and without writing a config file, and prints to the terminal.

  $ permit test generate e2e --models=RBAC

Contents