Policy Schema
The Keycard entity schema and the context attributes available in Cedar policy conditions
Keycard Policies are written in Cedar and validated against the typed schema on this page. For the Console walkthrough and the rule patterns that use these entities, see Access Policies.
Keycard schema
Section titled “Keycard schema”| Entity type | Maps to |
|---|---|
| Keycard::User | The people who authenticate into a Zone |
| Keycard::Application | Registered Applications and OAuth clients, acting for a User or on their own |
| Keycard::Resource | Third-party API Resources configured in the Zone (for example, Google Calendar, GitHub) |
| Keycard::Role | Platform-defined Roles held by Users and Applications through Role assignments |
| Keycard::CustomRole | Customer-defined Roles. A separate entity type so identifiers can’t collide with platform Roles |
| Keycard::Group | Groups of Users, managed in the Zone |
| Keycard::RegistrationMethod | Enum entity for Application registration methods |
| Keycard::CredentialType | Enum entity for Application credential types |
Entity properties
Section titled “Entity properties”Keycard::Application
Section titled “Keycard::Application”| Property | Type | Description |
|---|---|---|
| identifier | String | The Application’s unique identifier |
| name | String | The Application’s display name |
| registration_method | RegistrationMethod | How the Application was registered. See Keycard::RegistrationMethod |
| credential_type | CredentialType? | The credential type used for authentication. Absent when not yet determined. See Keycard::CredentialType |
| traits | Set<String> | Behavioral traits: "gateway" (acts as an API gateway), "mcp-provider" (provides MCP tools) |
| dependencies | Set<Resource> | Resources the Application is configured to access directly (service-to-service) |
Applications can hold Roles.
Keycard::User
Section titled “Keycard::User”| Property | Type | Description |
|---|---|---|
| identifier | String | The User’s unique identifier |
| String | The User’s email address from their identity provider |
Users can hold Roles and belong to Groups.
Keycard::Resource
Section titled “Keycard::Resource”| Property | Type | Description |
|---|---|---|
| identifier | String | The Resource’s unique identifier |
| name | String | Human-readable Resource name |
| scopes | Set<String> | OAuth scopes associated with the Resource |
Keycard::Role
Section titled “Keycard::Role”Roles have no attributes. They are membership targets: a rule matches when the principal holds the Role, tested with Cedar’s in operator. The Role’s owner selects the entity type:
principal in Keycard::Role::"admin" // platform-definedprincipal in Keycard::CustomRole::"deployer" // customer-defined (creating custom Roles is coming soon)Only Users and Applications can hold Roles. See Role-based Policies for worked examples.
Keycard::Group
Section titled “Keycard::Group”Groups have no attributes and, like Roles, are membership targets. The entity ID is the Group’s identifier, which is unique within the Zone:
principal in Keycard::Group::"data-analysts"Only Users can be Group members. See Group-based Policies for worked examples.
Keycard::RegistrationMethod
Section titled “Keycard::RegistrationMethod”| Value | Description |
|---|---|
| Keycard::RegistrationMethod::“managed” | Created through the management API |
| Keycard::RegistrationMethod::“dcr” | Registered through OAuth 2.0 Dynamic Client Registration |
Keycard::CredentialType
Section titled “Keycard::CredentialType”| Value | Description |
|---|---|
| Keycard::CredentialType::“token” | Workload identity (short-lived tokens) |
| Keycard::CredentialType::“password” | Client ID and secret |
| Keycard::CredentialType::“public-key” | Key-based assertion |
| Keycard::CredentialType::“url” | URL-based identity |
| Keycard::CredentialType::“public” | Public client (no secret) |
Claims
Section titled “Claims”The Claims record type carries JWT claims for claim-based conditions.
| Property | Type | Description |
|---|---|---|
| String? | Email claim from the JWT, if present | |
| groups | Set<String>? | The groups claim as asserted by the upstream IdP (for example, Okta or Entra ID groups). This is a snapshot from one sign-in, not Keycard Group membership; for directory-backed membership use Keycard::Group |
Context
Section titled “Context”Every request carries a context record with its runtime state:
| Attribute | Type | Description |
|---|---|---|
| on_behalf | Bool | Whether this is a delegated request (an Application acting for a User) |
| impersonate | Bool | Whether this is an impersonation request (an Application acting as the subject rather than on its behalf) |
| subject | User? | The User an Application acts for. Absent for direct Application access |
| resource | Resource? | The request’s target Resource, mirrored into context so conditions can reference it (for example, context.resource.identifier) |
| scopes | Set<String>? | OAuth scopes in the current request. Absent when none are requested |
| actor_claims | Claims? | JWT claims for the actor making the request |
| subject_claims | Claims? | JWT claims for the subject an Application acts on behalf of. Absent when there is no subject |
Schema versions
Section titled “Schema versions”Schema versions use a date format (for example, 2026-06-18). A Policy written against a version keeps working: Keycard only makes additive changes to a published version, such as new entity types or attributes.