Simulate Access

Test "what if" scenarios without touching production policies. Add temporary roles or permissions to a subject and see what changes — without actually granting anything.

The problem

You're about to change a role's permissions. You think you know what will happen, but role inheritance, scope chains, and deny rules interact in unexpected ways. Pushing the change to production and then checking access is backward — the damage is already done.

You could manually trace every policy, but at scale that's impossible. You need a sandbox where you can ask "if Bob had the Editor role, could he write to billing?" and get an answer in milliseconds.

How it works

Send a subject, a set of access checks, and temporary roles or permissions. The evaluator runs the same logic as a live access check — including role inheritance, scope chains, and deny-override — but nothing is persisted. No policies change. No audit events are generated.

Simulating temporary role grants

The most common use case: preview what happens if you give a subject a role they don't currently have.

cURL

curl -X POST https://api.wardenauthz.com/v1/access/simulate \
  -H "x-api-key: YOUR_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "subjectId": "subject-bob",
    "scopeId": "workspace-eng",
    "checks": [
      { "resource": "billing", "action": "read" },
      { "resource": "billing", "action": "write" }
    ],
    "roles": ["viewer"]
  }'

{
  "subjectId": "subject-bob",
  "scopeId": "workspace-eng",
  "results": [
    {
      "resource": "billing",
      "action": "read",
      "allowed": true,
      "reasoning": {
        "matchedBy": [{ "roleId": "viewer", "roleName": "Viewer", "permissionId": "billing:read" }],
        "deniedBy": [],
        "scopeChain": ["workspace-eng", "org-acme"]
      }
    },
    {
      "resource": "billing",
      "action": "write",
      "allowed": false,
      "reasoning": {
        "matchedBy": [],
        "deniedBy": [],
        "scopeChain": ["workspace-eng", "org-acme"]
      }
    }
  ]
}

Bob got temporary viewer access — he could read billing but not write. His actual access policy was never modified.

Simulating temporary permissions

You can also inject permissions directly, bypassing roles:

curl -X POST https://api.wardenauthz.com/v1/access/simulate \
  -H "x-api-key: YOUR_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "subjectId": "subject-alice",
    "scopeId": "workspace-eng",
    "checks": [
      { "resource": "documents", "action": "delete" }
    ],
    "permissions": [{
      "id": "temp-delete-docs",
      "resource": "documents",
      "action": "delete",
      "effect": "allow"
    }]
  }'

When to use

• Debugging: "Why is Alice getting denied?" — simulate to see which policies match and which don't.
• Previewing: "What happens if I give Bob the Editor role?" — simulate before committing a role assignment.
• Testing deny rules: "Does this new deny rule actually block what I think it blocks?" — inject the deny rule, simulate, verify.
• Policy auditing: "What can this role actually do across all resources?" — simulate a subject with just that role against a list of checks.

Requirements

• access-check:evaluate permission on the management key.
• Each simulation call consumes 1 access check from your quota.
• Temporary roles and permissions are evaluated in-memory only. Nothing is written to the database.

Dashboard

No dedicated simulate page exists in the dashboard. Use the Access Check page for single lookups with reasoning, or call the API directly for multi-check simulations with temporary roles.

Full API reference