Decision objective
The trust algorithm in a zero trust architecture is the logic that decides whether a subject can perform an action on a resource under current conditions. The name does not imply one universal formula, machine-learning score, or amount of trust. It is a policy decision with explicit inputs, confidence, freshness, and failure behavior.
Inputs and decision
Inputs can include subject and actor identity, authenticator assurance, device identity and posture, workload identity, client and session, resource and action, network and time, threat signals, prior behavior, policy, and external records. The decision must distinguish missing, false, stale, unavailable, and conflicting input.
Normalize untrusted request data before policy. Bind identity evidence to its issuer, audience, credential, and session. Bind resource and action to trusted route or application context. Select policy by trusted configuration. Record the effective version and reason.
The result can be allow, deny, challenge, limit, or another locally defined action. The enforcement point must implement the result on the exact request and resource.
Confidence, freshness, and evidence
Confidence comes from the quality and independence of the evidence, not from the number of signals. State how each input was established, when it was observed, how long it remains useful, and what happens when its producer fails.
Decision evidence includes subject, resource, action, relevant context, policy version, result, reason, enforcement result, time, and correlation identifier. Minimize sensitive fields and protect integrity.
Failure and residual risk
More context can improve decisions and add stale data, inconsistent semantics, privacy exposure, and unavailable dependencies. A numerical risk score can hide policy and confidence assumptions. A correct decision can be enforced on the wrong resource or bypassed through another path.
Residual risk includes compromised issuers, false device posture, delayed lifecycle changes, incorrect policy, stale caches, direct endpoints, and harmful application actions after route authorization.
Pomerium boundary
Pomerium evaluates configured policy from identity, request, device, and external context available to the deployment. It can record authorization reasons and enforce a route-level result. Operators own input authority, freshness, policy intent, dependency behavior, direct-path isolation, and application object authorization.
Evaluation checklist
- Which trusted source establishes each subject, resource, action, and context input?
- What are the confidence, freshness, expiry, and failure rules for each input?
- Which policy version and reason produced one decision?
- Does the enforcement point apply that result to the exact resource and action?
- Which bypass, stale input, conflicting input, or dependency failure changes the safe result?
