Risk is the possibility of an unfavorable outcome when an action or condition is uncertain, especially when reliance creates vulnerability. In authorization, risk helps determine which signals, assurance levels, and freshness requirements a decision needs. section 2.6.1 section 12.3.1
Authorization decisions can respond to risk by combining context rather than applying a universal access rule:
- Use role and ownership for lower-risk actions such as viewing a document. section 12.3.1
- Require device trust, time of day, and on-call status for higher-risk actions such as production deployment. section 12.3.1
- Treat trust as exposure to another party’s behavior, while confidence grows from evidence and observation; neither is purely binary. section 2.6.1
- Bound delegated authority through explicit policies and visibility into how authority moves across teams, customers, and systems. section 19.3
Production deployment
A deployment decision carries more risk than document viewing because stale on-call, device, or change-management data could authorize a high-impact action. Real-time, trustworthy context reduces that exposure without requiring every system to invent its own access logic. section 12.3.1 section 12.7
Table 12.1 ACME’s trust signals across different contexts. Each system occupies a different point within the three-dimensional choice space—balancing accuracy, latency, and complexity—to align with its risk profile. The Customer Collaboration platform prioritizes performance with token-based context; employees use a hybrid approach combining stable and short-lived signals; and the engineering tools depend on high-assurance, real-time data to avoid stale or unauthorized deployments. The freshness times in the table are typical and may vary depending on actual needs.
| Context |
Key signals |
Delivery method |
Freshness model |
|---|---|---|---|
| Customers on the Customer Collaboration platform |
Customer ID, role, account status, fraud score |
OAuth token (ID plus role); customer authn system API query for status |
Token = 1 hour; account/fraud data refreshed every few hours |
| Employees on the Customer Collaboration platform |
Employee identity, HR status, department, Finance limit, device posture |
Internal API calls (HR, Finance); signed device-trust token from posture client |
HR/Finance cached daily; device-trust token expires in 15 minutes |
| Engineers using deployment tools |
Employee identity, on-call status, device posture, change ticket approval, CI/CD build verification |
Internal identity service; real-time PagerDuty API; signed device-posture token; CI/CD and change-management APIs |
On-call and posture data ≤ 5 minutes; others cached daily |
Compare customer, employee, and engineering authorization contexts by signal set, delivery method, freshness, and the trade-off between accuracy, latency, and complexity. section 12.7
