Skip to main content

Authority Paths - Primer

We must model authority paths as execution-determined, not configuration-determined.

We have to separate three things explicitly.

  1. The potential. Agent or workflow + identity + all possible permissions and roles that could execute.
  2. Actual execution. What did execute? For example, APIs called, tokens used, actual scopes and roles invoked, and resources touched.
  3. The standing authority or risk posture: the delta between one and two

Our core differentiation lives in (2), in its provenance and execution lineage.

How do we need to think about authority paths?

If we look at a single execution, it is one execution lineage, but it can include multiple exercised authorities. In this case, one execution may involve multiple roles and touch multiple data domains.

The default rule of what we show when we refer to the authority path is only show what was exercised:

  • If a service principle has two roles but the run only used one role and touched only one data domain, the path detail show only that exercised branch.
  • Separately, we need to show latent authority as a “could also do”
  • This results in two abstracts: the observed authority path versus potential authority path.

In practical terms, the path detail page must show the observed authority path. The potential authority path detail will be added over time.