Blueprints

Blueprints are AI-generated policy outlines that help you design authorization strategies for your organization. Instead of starting from scratch, describe your access control needs in natural language and let Denied generate structured blueprints you can refine into working policies.

Overview

Blueprints bridge the gap between business requirements and technical policy implementation:

1. Describe your authorization needs in plain language
2. Generate structured policy blueprints with AI
3. Review the generated recommendations
4. Refine into working Rego policies
5. Save blueprints for future reference

Generating Blueprints

Navigate to Blueprints

1. Go to Governance → Blueprints
2. Click Generate Blueprint or use the generation form

Provide Context

The AI generates better blueprints when you provide context about your organization:

Describe Your Requirements

In the description field, explain your authorization requirements in natural language:

Sales representatives should be able to view customer records in their
assigned territory. Managers can view all customer records in their
region. Only compliance officers can export customer data.

Generate the Blueprint

Click Generate to create your blueprint. The AI will analyze your requirements and produce:

• A structured policy outline
• Recommended access control patterns
• Suggested entity properties
• Implementation considerations

Understanding Blueprint Output

A generated blueprint typically includes:

Policy Recommendations

High-level descriptions of policies you should create:

1. Territory-Based Customer Access
   - Allow sales reps to view customers in their territory
   - Requires: user.territory, customer.territory properties

2. Regional Manager Override
   - Allow managers to view all customers in their region
   - Requires: user.role, user.region, customer.region properties

3. Compliance Export Permission
   - Allow only compliance officers to export data
   - Requires: user.role == "compliance", action == "export"

Entity Requirements

What properties your subjects and resources need:

Subject Properties:
- role: user's role (sales_rep, manager, compliance)
- territory: assigned sales territory
- region: geographic region

Resource Properties:
- territory: customer's territory
- region: customer's region
- sensitivity: data classification level

Pattern Suggestions

Which authorization patterns apply to your use case:

• Role-Based Access Control (RBAC)
• Attribute-Based Access Control (ABAC)
• Geographic/Territory restrictions
• Data sensitivity controls

Saving Blueprints

After generating a blueprint you want to keep:

1. Review the generated content
2. Click Save Blueprint
3. Enter a name for the blueprint
4. Add optional tags or categories
5. Click Save

Saved blueprints appear in your blueprint library for future reference.

Managing Blueprints

Viewing Saved Blueprints

Go to Governance → Blueprints to see your saved blueprints. Each blueprint shows:

• Name — The blueprint identifier
• Description — Summary of what the blueprint covers
• Created — When the blueprint was generated
• Tags — Categories or labels you've assigned

Using a Blueprint

To create policies from a saved blueprint:

1. Go to Governance → Blueprints
2. Select the blueprint
3. Review the recommendations
4. Click Create Policy for each recommended policy
5. Customize the generated Rego code
6. Save your policies

Deleting Blueprints

To delete a blueprint you no longer need:

1. Go to Governance → Blueprints
2. Find the blueprint in the list
3. Click Delete
4. Confirm the deletion

Blueprint Workflow

Starting a New Project

When setting up authorization for a new application:

1. Generate blueprints for each major access control area
2. Save the blueprints for reference
3. Create policies based on blueprint recommendations
4. Test policies in the Playground
5. Iterate as requirements evolve

Onboarding Team Members

Use saved blueprints to help new team members understand your authorization strategy:

• Blueprints document the "why" behind your policies
• They capture business requirements alongside technical implementation
• New members can trace policies back to original requirements

Auditing and Compliance

Blueprints serve as documentation for compliance:

• Show auditors the business requirements that drove policy decisions
• Demonstrate that access controls are intentional and well-designed
• Track how requirements evolved over time

Best Practices

Be Specific in Descriptions

More detail produces better blueprints:

Less effective:

Control access to customer data.

More effective:

Sales reps should only see customers in their assigned territory.
Territory is determined by the customer's postal code matching the
rep's territory definition. Managers can see all customers in
territories that report to them. Export functionality should be
restricted to compliance team members only.

Include Edge Cases

Mention special scenarios in your description:

Normal access: Users can view their own profile.
Exception: HR can view all profiles for administrative purposes.
Restriction: No one can view salary information except HR and
the employee themselves.

Use Organizational Language

Describe requirements in terms your organization uses:

• Use actual role names (Sales Rep, Account Manager, not generic "user")
• Reference real resource types (Customer Record, Deal, not generic "data")
• Include domain terminology

Review and Validate

Always review generated blueprints:

• Check that recommendations match your intent
• Look for missing scenarios
• Verify suggested patterns are appropriate
• Consider security implications

Iterate on Blueprints

Blueprints can be regenerated:

• Add more context if recommendations aren't quite right
• Break complex requirements into smaller blueprints
• Generate new blueprints as requirements change

From Blueprint to Policy

Example Workflow

Starting with this requirement:

Team leads can approve time-off requests for members of their team.
Only HR can approve requests for more than 2 weeks.

Generated Blueprint:

Policy 1: Team Lead Time-Off Approval
- Allow team leads to approve time-off requests
- Condition: requester is in approver's team
- Condition: request duration <= 14 days

Policy 2: HR Extended Time-Off Approval
- Allow HR to approve any time-off request
- No duration restriction

Required Properties:
- Subject: role, team_id
- Resource: requester_team_id, duration_days

Resulting Policies:

Policy 1: Team Lead Time-Off Approval

input.action.name == "approve_timeoff"
input.subject.properties.role == "team_lead"
input.resource.properties.requester_team_id == input.subject.properties.team_id
input.resource.properties.duration_days <= 14

Policy 2: HR Extended Time-Off Approval

input.action.name == "approve_timeoff"
input.subject.properties.role == "hr"

Troubleshooting

Blueprint not matching requirements?

• Add more detail to your description
• Break complex requirements into separate blueprints
• Specify the context fields more precisely

Generated patterns seem wrong?

• Review the data sensitivity and user type settings
• Check that department context is accurate
• Regenerate with adjusted context

Missing edge cases?

• Explicitly mention exceptions in your description
• Generate separate blueprints for special cases
• Add specific scenarios you want covered

Related

• Policies — Create and manage policies
• Common Patterns — Authorization pattern examples
• Rego Basics — Learn the policy language