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.

Keycard uses a default-deny model. Every authorization request needs an explicit permit for the user, the application, and the resource being accessed. A forbid rule overrides a permit, which lets teams start with safe baselines and layer more restrictive rules where needed.

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?
• Should runtime context, such as delegated access, groups, or claims, change the decision?

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.