Context is the current information surrounding an access request that can change an authorization decision. Identity establishes who is requesting access; context supplies conditions such as time, device trust, network risk, department, resource classification, or on-call status. A manager may view dashboards because of a role, while a call-center agent may access sensitive data only during an assigned shift. section 4.2
Context makes authorization dynamic rather than a fixed assignment of permissions. Policies evaluate the principal, action, resource, and relevant environmental conditions for each request. This avoids forcing transient facts into roles, access-control lists, or relationship graphs, where changing conditions become difficult to express and audit. section 4.6 section 5.3 section 6.1.5
Useful context commonly includes:
- Principal and organizational attributes, such as role, department, clearance, or manager. section 4.5.3
- Resource facts, such as classification, ownership, type, or region. section 4.5.3
- Environmental and operational signals, such as time, network risk, location, device posture, authentication freshness, and on-call status. section 8.1.2 section 15.5.2
Conditional deployment access
A deployment policy can require an engineer to use a company-managed device and have sufficient clearance. Outside business hours, it can additionally require on-call status. These conditions keep the policy focused on circumstances of the request rather than expanding its basic scope. section 7.2.3
Context is only trustworthy when its signals are accurate, secure, structured, and fresh enough for the risk of the action. A stale device-posture or on-call signal can produce an unreliable decision even when the policy is correct. Systems therefore balance assurance, latency, availability, and data exposure: lower-risk actions may use longer-lived token claims, while high-risk deployments need current operational data. section 6.2.3 section 12.7 section 15.5.2
Figure 4.7 Distributed authorization architecture at ACME Corp. Each service includes an authorization client, a bundled component that contains the PEP, PDP, and an entity cache. The client may be deployed as a sidecar (ACMEFinance), as a library within application code (ACMEProject), or integrated into an API gateway (ACMEHR). Policies are authored and managed by Carol via the Policy Administration Point (PAP) and then distributed to each client. Contextual data is retrieved from shared PIPs, such as identity stores, time servers, and network telemetry, and is cached inside the client.
Trace how distributed authorization clients obtain context from Policy Information Points (PIPs), cache attributes locally, and evaluate policies close to each service. section 4.5.3
Policy engines obtain context from sources such as identity providers, databases, time services, and telemetry. Caching can reduce decision latency and improve resilience, but refresh, policy synchronization, and consistent evaluation must be managed carefully. Context can be represented as attributes in XACML, supplied in a flexible input object to OPA and Rego, or evaluated through AWS IAM condition keys; relationship-only systems may require contextual checks outside the relationship engine. section 4.5.3 section 8.1.2 section 8.2.3 section 8.3.3
As services and agents act continuously, authorization must evaluate context when each consequential action occurs. A policy-aware agent sends its proposed tool action, target, and task-specific context through a Policy Enforcement Point before execution; a denial becomes feedback for revising the plan. section 18.3 section 19.9
