Simulation & Why Denied
Summary
Simulation and Why Denied features allow policy authors to test authorization decisions before deployment and diagnose why access was granted or denied. These capabilities reduce policy errors and accelerate troubleshooting by providing visibility into the decision-making process.
Why It Exists
Authorization policies can have unintended consequences — granting too much access or blocking legitimate users. Without testing tools, policy authors must deploy changes to discover problems. Simulation enables safe testing, while Why Denied explains decisions in production without exposing sensitive policy logic.
Where It Fits in Keymate
Simulation is available in the Admin Console during policy authoring. Why Denied is accessible through decision trace headers returned with authorization responses and through the audit trail in the Admin Console.
Boundaries
What it covers:
- Policy simulation with test inputs
- Decision explanation for individual requests
- Policy evaluation trace showing which rules matched
- Impact analysis before policy deployment
What it does not cover:
- Policy versioning and rollback (see Policy Lifecycle)
- Production monitoring and alerting (see Observability)
How It Works
Policy Simulation
Simulation evaluates a policy against test inputs without affecting production. Authors provide:
- Subject attributes — User properties to test against
- Resource attributes — Resource properties for the request
- Action — The operation being attempted
- Context — Environmental attributes (time, location, device)
The simulation returns the decision (GRANT, DENY, or ERROR) along with which conditions matched or failed.
Decision Strategies
Policies can combine multiple conditions using different strategies:
| Strategy | Behavior | Use Case |
|---|---|---|
AFFIRMATIVE | Single match grants access (logical OR) | Flexible access with multiple valid paths |
UNANIMOUS | All conditions must match (logical AND) | Strict access requiring all criteria |
CONSENSUS | Majority decides | Balanced decision with multiple factors |
Policy Logic
The logic setting determines how the policy result is interpreted:
| Logic | Behavior |
|---|---|
POSITIVE | Policy result used as-is (match = allow) |
NEGATIVE | Policy result inverted (match = deny) — for exception policies |
Why Denied Analysis
When access is denied, the Why Denied feature shows:
- Which policies were evaluated
- Which conditions failed
- What attribute values caused the failure
- The decision strategy outcome
Diagram
Example Scenario
Scenario
A developer creates a policy requiring user.department == 'finance' for accessing financial reports. A finance team member reports they cannot access reports.
Input
- Actor: Support engineer investigating the issue
- Resource: Why Denied trace for the failed request
- Action: Analyze decision
- Context: Production environment
Expected Outcome
- Why Denied shows the user's
departmentattribute is'Finance'(capitalized) - The policy condition uses lowercase
'finance' - Resolution: Update policy to handle case variations or fix source data
Common Misunderstandings
- Simulation uses live data — Simulation can use mock data; it does not require real user accounts
- Why Denied exposes policy logic — The feature shows which conditions failed without revealing the full policy definition
Simulation results may differ from production if attribute sources return different values. Verify attribute mappings when debugging discrepancies.
Design Notes / Best Practices
- Simulate policies with edge cases before deployment
- Include negative test cases (inputs that should be denied)
- Use Why Denied traces to build regression tests
- Document expected behavior alongside policy definitions
Create a library of test scenarios for common policy patterns to accelerate validation.
Related Use Cases
- Pre-deployment validation of policy changes
- Troubleshooting user access issues
- Compliance verification for access controls
- Policy impact analysis before rollout