Authorization context is the set of trust signals used alongside a request to decide whether access is allowed. It can describe the principal, resource, device, session, environment, risk, or relevant relationships. The key question is not merely which signals matter, but also how they arrive and how current they must be when policy is evaluated. section 12.0 section 12.3
External context is authorization-relevant information that the decision-making system does not create or authoritatively maintain itself. Examples include professional licenses, clinical affiliations, supplier relationships, project delegations, and claims from employers or customers. Such facts can be supplied as verifiable credentials: portable, cryptographically verifiable statements issued by organizations that possess the relevant facts. section 16.1
Design authorization context across three connected choices:
- Select signals appropriate to the decision, such as employment status, account suspension, multifactor authentication (MFA), device posture, location, risk score, account balance, or resource state. section 12.0
- Choose delivery paths: embed claims in tokens, fetch data through APIs, consume event streams, use local agents, or evaluate externally issued credentials. section 12.0 section 16.1
- Set freshness deliberately. Low-risk collaboration can tolerate token context lasting an hour, while production deployment may require live operational data and short-lived device-posture signals. section 12.0 section 12.4.4
Context quality is an authorization architecture and governance concern, not a policy-language detail. A policy is only as useful as its inputs are trustworthy, available, and sufficiently current. Cached context may combine signals with very different lifetimes, so systems need to track each signal’s source, time to live (TTL), and validation method while balancing speed, reliability, and assurance. section 12.0 section 12.4.4
Delegated reimbursement
An agent may be permitted to pay a contractor reimbursement only when context shows a matching delegated capability, an amount and currency within delegation limits, a receipt, and an unexpired authorization. Here, context carries both the authority and the constraints that narrow how it may be used. section 18.7
permit (
principal,
action == Action::"reimbursement.pay",
resource
)
when {
context.delegation.capability == "contractor.reimbursement.pay"
&& context.payment.amount <= context.delegation.constraints.max_amount
&& context.payment.currency == context.delegation.constraints.currency
&& context.payment.receipt_present == true
&& context.currentTime < context.delegation.constraints.expires
};
The policy listing shows context fields enforcing a delegated payment capability, amount and currency limits, receipt requirement, and expiration time. section 18.7
In agentic systems, context can expand as work is planned and delegated. It may include initiating intent, delegation scope, consent constraints, organizational policy, data sensitivity, tool capabilities, provenance, guardrails, and risk signals. Some signals steer behavior at each hop; others must remain intact until enforcement reaches the resource. section 18.7
