The PARC model frames an authorization decision as a question: can a principal perform an action on a resource under particular conditions? It separates authentication, which establishes identity, from the decision about what that identity may do now. This makes access rules easier to discuss, test, manage, and audit. section 4.3.1 section 4.0
PARC names the four inputs that define an access request:
- Principal: the requesting entity, such as a person, service account, IoT device, delegated role, or integration. Policies can use attributes including role, group, department, clearance, or tenant. section 4.3.1 section 7.3
- Action: the requested operation, such as read, write, update, delete, view, edit, or deploy. For APIs, it commonly maps to an endpoint verb or application-specific operation. section 4.3.1 section 7.3
- Resource: the target object or collection, such as a document, account, invoice, database row, folder, system, or workspace. Resource attributes such as owner, classification, and status can affect policy. section 4.3.1 section 7.3
- Conditions (often called context at request time): relevant circumstances such as time, location, device trust, risk score, workload identity, token scopes, or tenant. section 4.3.1 section 11.2.4
A policy mirrors PARC. Its scope identifies the principal, action, and resource to which it applies; its conditions further restrict that scope. At evaluation time, the request is matched against the policy scope, then conditions are evaluated with principal and resource attributes plus request context. Multiple applicable policies can then be resolved by the policy engine. section 7.3 section 7.3.1
Turning an API call into PARC
An API gateway can validate an OAuth access token, extract its subject as the principal, infer an action from the API method, derive a workspace or document from the path or body, and add scopes or attribution as context. Cedar evaluates the resulting request; the gateway allows the call on permit or blocks it on deny. Tokens establish the API boundary, while policy decides detailed access to a particular resource. section 11.2.4 section 11.4
{
"principal": "Employee::\"bob\"",
"action": "Action::\"edit\"",
"resource": "Document::\"doc456\"",
"context": {
"device": {
"is_managed": true
},
"time": "2025-07-08T10:30:00Z"
}
}
This structured Cedar request shows Bob as the principal, edit as the action, a document as the resource, and managed-device and time values as context. section 7.3.1
PARC is a common reference point rather than a complete policy language. Cedar expects every request in this shape, while OPA/Rego leaves the input structure to policy authors. The same model also helps compare XACML, OpenFGA, and other authorization approaches without confusing a policy language’s syntax with the access decision it must express. section 7.3.4 section 8.2.3
The model supports consistent enforcement across architectures. Gateways, service meshes, proxies, and layered policy enforcement points can normalize requests into PARC before policy decision points evaluate them. For AI agents, each proposed tool call can be expressed as PARC, checked before execution, and returned to the agent for replanning if denied. section 11.3 section 18.3
