Skip to main content
The policy store is the central authorization engine for your application. It contains the schema that defines your entity types (users, documents, roles) and the Cedar policies that control access.

​
Create Empty Policy Store

1

Navigate to AWS Verified Permissions

  1. Open the AWS Console
  2. Search for “Verified Permissions” in the search bar
  3. Click on the service to open the AVP dashboard
2

Create new policy store

Click the “Create policy store” button.
3

Select empty policy store

Select “Empty policy store” — do NOT use “Guided Setup”. The guided setup uses a different schema structure.
Choose the option to start with an empty policy store.
4

Name your policy store

Enter a name for your policy store:
FinancialDocsStore
You can use a different name, but this guide uses FinancialDocsStore for consistency.
5

Create the policy store

Click “Create” to finalize the policy store creation.
6

Copy the Policy Store ID

You MUST save the Policy Store ID — you’ll need it for SAM deployment in the next step.
After creation, you’ll see a dashboard with your policy store details. The Policy Store ID looks like:
PS1a2b3c4d5e6f7g8h9i0
Copy this ID to your clipboard or a text file.

​
Configure the Schema

The schema defines the structure of your authorization model: what entity types exist, what attributes they have, and what actions can be performed.
1

Open schema editor

In your policy store dashboard:
  1. Click on the “Schema” tab
  2. Click “Edit” to open the schema editor
2

Clear existing content

Delete any default content in the schema editor (it should be mostly empty for a new policy store).
3

Paste the FinancialApp schema

Copy and paste the following JSON schema:
{
    "FinancialApp": {
        "entityTypes": {
            "User": {
                "shape": {
                    "type": "Record",
                    "attributes": {
                        "department": {
                            "type": "String",
                            "required": true
                        },
                        "clearance_level": {
                            "type": "Long",
                            "required": true
                        }
                    }
                },
                "memberOfTypes": ["Role"]
            },
            "Document": {
                "shape": {
                    "type": "Record",
                    "attributes": {
                        "classification": {
                            "type": "String",
                            "required": true
                        },
                        "department": {
                            "type": "String",
                            "required": true
                        }
                    }
                }
            },
            "Role": {
                "memberOfTypes": []
            }
        },
        "actions": {
            "Read": {
                "appliesTo": {
                    "principalTypes": ["User"],
                    "resourceTypes": ["Document"]
                }
            },
            "Edit": {
                "appliesTo": {
                    "principalTypes": ["User"],
                    "resourceTypes": ["Document"]
                }
            },
            "Delete": {
                "appliesTo": {
                    "principalTypes": ["User"],
                    "resourceTypes": ["Document"]
                }
            }
        }
    }
}
4

Save the schema

Click “Save changes” at the bottom of the schema editor.If there are any syntax errors, the console will highlight them. Ensure the JSON is valid before saving.

​
Understanding the Schema

​
Entity Types

The schema defines three entity types:

​
User

"User": {
    "shape": {
        "type": "Record",
        "attributes": {
            "department": { "type": "String", "required": true },
            "clearance_level": { "type": "Long", "required": true }
        }
    },
    "memberOfTypes": ["Role"]
}
  • Attributes:
    • department: The department the user belongs to (e.g., “Finance”, “HR”)
    • clearance_level: Numeric security clearance level (1-5)
  • Hierarchy: Users can be members of Roles
The "memberOfTypes": ["Role"] field is critical. It allows AVP to evaluate Cedar expressions like principal in Role::"Analyst". Without this, role-based policies won’t work.

​
Document

"Document": {
    "shape": {
        "type": "Record",
        "attributes": {
            "classification": { "type": "String", "required": true },
            "department": { "type": "String", "required": true }
        }
    }
}
  • Attributes:
    • classification: Security classification (e.g., “Public”, “Confidential”, “Secret”)
    • department: Department that owns the document

​
Role

"Role": {
    "memberOfTypes": []
}
Roles are simple groupings with no attributes. They exist to group users (e.g., “Analyst”, “Auditor”).

​
Actions

The schema defines three actions that Users can perform on Documents: 
"actions": {
    "Read": {
        "appliesTo": {
            "principalTypes": ["User"],
            "resourceTypes": ["Document"]
        }
    },
    "Edit": { ... },
    "Delete": { ... }
}
Each action specifies:
  • principalTypes: Who can perform the action (only Users)
  • resourceTypes: What the action can be performed on (only Documents)

​
Verify Schema Configuration

After saving, verify your schema:
  1. The schema editor should show no errors
  2. You should see the schema JSON rendered in the console
  3. The “Schema” tab should show a green checkmark or “Active” status
At this point, your policy store has a schema but no policies. This is expected — you’ll add policies interactively during the demo after deploying the application.

​
Next Steps

With your policy store created and schema configured, you’re ready to deploy the backend infrastructure:

Deploy with SAM

Build and deploy Lambda functions and API Gateway

Build docs developers (and LLMs) love

Get started for freeTalk to us