Workflow Provenance Engine
Every cloud operation, traced to the workflow that produced it.
A cloud role session does not say which pipeline run created it. Ordrani reconstructs that lineage — from repository and workflow, through federated token exchange, to the session and every operation it performed — and states how certain each link is.
Overview
Judge activity by the purpose of the automation behind it.
Most cloud detection evaluates an API call against the identity that made it. But a deployment role is shared by many runs, from many branches, triggered by many people and events. The question that matters is which execution produced this call — and whether that execution had any reason to make it.
The Workflow Provenance Engine connects cloud activity to its source: the repository, workflow file, branch, environment and run that federated into the cloud and created the session. With that link established, activity can be evaluated against what the workflow is meant to do, not only against what its identity has done before.
Attribution is treated as evidence with a measurable quality. Some links are proven by identifiers carried through the token exchange; others are inferred from timing and context. Ordrani records which is which, and never presents an inference as fact.
What it produces
- Lineage from repository and workflow to role session and API call
- An explicit attribution level on every link
- Purpose deviation: activity inconsistent with a workflow’s declared function
- Attribution coverage — the share of relevant events reliably linked
The provenance chain
From repository to API call, one link at a time.
Each step is joined by specific evidence, and every link carries the strength of that evidence with it.
01
Repository
org/payments-service
workflow file
02
Workflow
deploy.yml · production
run id
03
Execution
run 4182 · job deploy
OIDC claims
04
Federated token
sub · job_workflow_ref
AssumeRoleWithWebIdentity
05
Role session
prod-deploy-role
session ARN
06
Operations
API calls and resources
Confirmed attribution
The link is established by verifiable identifiers — OIDC claims bound to a role session, a session ARN recorded on each API call. Ordrani treats these as fact.
Strong correlation
The link is supported by multiple independent signals such as role, timing, source network and resource overlap, but no single identifier proves it.
Unverified hypothesis
A plausible explanation the evidence does not yet support. Shown to analysts as a question to resolve, never as a conclusion.
How attribution works
Four steps from a cloud event back to its source.
01
Capture the run
Collect workflow run metadata from source control: repository, workflow file and revision, ref, environment, trigger and timing.
02
Follow the federation
Match the OIDC token exchange — subject, audience and claims such as the workflow reference — to the role session it created in the cloud.
03
Bind the session
Associate every API call made under that session with the execution, carrying the session identity through the cloud audit trail.
04
Grade the link
Assign an attribution level — confirmed, correlated or hypothesis — according to the evidence that supports it.
What provenance makes possible
Questions that flat logs cannot answer easily.
01
Purpose deviation
02
Unexpected origin
03
Activity after completion
04
Shared-role ambiguity
05
Attribution coverage
06
Precise engineering handoff
Continue exploring
Related reading.
Trace your pipelines into the cloud.
We would welcome a conversation about how your GitHub workflows federate into AWS, and where attribution is hardest today.