Policies

Policies are the rules Keycard evaluates before issuing or brokering access. They are what turn identity into controlled action: a user, application, and resource may all be known to the zone, but access is still denied unless policy permits it.

Evaluation follows Cedar’s rules: a request is permitted only when some permit rule matches it, and a forbid rule overrides any permit. When an application acts for a user, both must be permitted. What these rules mean in practice depends on which policy set is active. Out of the box a zone runs Keycard’s managed set, default-zone-policies, and its default-user-grants policy permits every authenticated user to reach every resource, so nothing a user asks for is denied until you change it. To restrict access, activate a policy set of your own that leaves default-user-grants out, or add a forbid rule, which wins even over the managed permits. See Managed Policies.

Policies answer questions like:

• Can this user access this resource?
• Can this application act on behalf of this user?
• Can this application access a resource directly, without a user?
• Does the request match the resource dependencies configured on the application?
• Does this user or application hold a role that grants access?
• Should runtime context, such as delegated access, roles, groups, or claims, change the decision?

Group membership is resolved when the request is evaluated, not from a claim on the presented credential, so adding or removing a member changes access without a policy update and without the user signing in again. Group rules also apply consistently to flows that run without a user session. Policies can still read the raw groups claim an identity provider puts on an ID token, but that claim is a snapshot of one sign-in: a membership change in the provider reaches policy only after the user signs in again. See which kind of group to use.

When policy permits access, Keycard can issue a credential for the target resource. When policy denies access, Keycard does not issue the credential.

A policy decision sits in the middle of the Keycard model:

1. A user or application requests access.
2. The request targets a resource.
3. Keycard evaluates policy inside the zone.
4. If permitted, Keycard issues or brokers a scoped credential.
5. The decision and resulting access are available for audit.

This is the core control loop for agents: they can keep acting, but every access request is checked against policy before credentials are handed out.

Keycard includes managed policies for common access patterns, including user access, delegated application access, and direct application access based on resource dependencies. Teams can also define customer policies for their own requirements.

Policies are assembled into policy sets and deployed across a zone. That makes policy operationally safe: you can version rules, activate a known-good set, and roll back when needed.

Keycard policies are written in Cedar, a declarative authorization language. Cedar is intentionally constrained: policies describe who can do what under which conditions, without loops or side effects.

For authoring details, schemas, examples, and lifecycle operations, see Access Policies.