Resolve identity once; let every engine consume it¶
October 4, 2026 · Kishore Babu Gutta
Authentication often becomes fragmented when each execution transport implements its own login story.
REST obtains a bearer token.
A CLI reads a native credential store.
A Kubernetes workload uses workload identity.
CI exchanges OIDC claims.
If each engine independently decides identity, the product eventually has several subtly different security models.
Engineering Runtime uses a different direction.
Resolve before transport¶
Execution surface
↓
Identity + context resolution
↓
Admitted runtime session
↓
REST / GraphQL / Command / File
The Runtime resolves who the caller is and which target context is active.
Execution engines then consume that admitted identity in the form appropriate to their transport.
For example:
- an API engine may consume an access token,
- a command engine may rely on the corresponding native authenticated session,
- a workload may rely on cloud-native identity,
- a local developer may use an existing provider login.
The underlying identity decision remains shared.
Why this is useful¶
It gives the Runtime one place to reason about:
- identity precedence,
- context,
- interactive versus non-interactive surfaces,
- short-lived credentials,
- fallback behaviour,
- evidence.
The transport can change without silently changing the security model.
Authenticate using the platform. Govern using the Runtime.
I think of this as Transport-Independent Authentication: resolve identity and context once, then let execution engines consume the result.