Skip to content

Platform-Native Authentication for Engineering Runtimes

Introduction

Every engineering platform already provides an authentication mechanism.

Examples include:

  • GitHub Personal Access Tokens
  • Google Application Default Credentials (ADC)
  • OpenShift Login
  • Kubernetes kubeconfig
  • AWS IAM
  • Azure CLI
  • OIDC for CI/CD pipelines

Yet many engineering automation tools introduce another authentication layer.

This often results in duplicated credentials, inconsistent security models, and increased operational complexity.

An Engineering Runtime should take a different approach.

Do not replace platform authentication. Reuse it.

The Problem

Consider an engineering environment.

GitHub

↓

Token

Google Cloud

↓

ADC

OpenShift

↓

oc login

Kubernetes

↓

kubeconfig

Every platform already solves authentication.

Now imagine an AI tool introduces:

AI Runtime

↓

Own Token Store

↓

Own Authentication

↓

Own Session Management

Now engineers must manage authentication twice.

This creates unnecessary complexity.

The Engineering Principle

An Engineering Runtime should never replace authentication systems provided by engineering platforms.

Instead, it should integrate with them.

Engineering Platform

↓

Native Authentication

↓

Engineering Runtime

↓

Governed Execution

The runtime becomes a consumer of trusted authentication rather than a replacement.

Examples

GitHub

GitHub already supports:

  • Personal Access Tokens
  • GitHub Apps
  • GitHub Actions OIDC

The runtime simply validates the existing authentication.

No additional login is required.

Google Cloud

Google Cloud already provides:

Application Default Credentials (ADC)

gcloud auth application-default login

Local development:

Browser login.

CI/CD:

OIDC.

The runtime should detect and validate ADC instead of creating another authentication model.

OpenShift

OpenShift already supports:

oc login

or

oc login --token

The runtime should reuse the authenticated OpenShift session.

Kubernetes

Kubernetes stores contexts in:

~/.kube/config

The runtime simply switches context when required.

No custom authentication is necessary.

Why This Matters

Less Complexity

Engineers already understand platform authentication.

The runtime should not introduce another learning curve.

Better Security

Authentication remains owned by the platform.

Credential rotation.

Access control.

Identity management.

All remain unchanged.

Better Compatibility

When platforms improve authentication, the runtime automatically benefits.

Examples include:

  • MFA
  • OIDC
  • Workload Identity
  • Short-lived credentials

No runtime changes are required.

Enterprise Adoption

Large organizations already trust their authentication systems.

Engineering runtimes become much easier to adopt when they integrate instead of replacing them.

Local Development

Engineer

↓

Browser Login

↓

Platform Authentication

↓

Engineering Runtime

The runtime validates existing credentials.

CI/CD

Pipeline

↓

OIDC

↓

Platform Authentication

↓

Engineering Runtime

Again, the runtime performs validation rather than authentication.

AI

AI

↓

Engineering Runtime

↓

Platform Authentication

↓

Platform

The AI never owns credentials.

It requests operations.

The runtime performs authenticated execution.

Authentication vs Authorization

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

An Engineering Runtime should rely on platform authentication while enforcing its own execution policies.

Examples include:

  • Allowed commands
  • Approved binaries
  • Execution context
  • Governance rules

Authentication remains platform-native.

Execution remains runtime-governed.

Design Principle

Authenticate using the platform. Govern using the runtime.

This simple principle eliminates duplicated authentication while preserving enterprise governance.

Benefits

Platform-native authentication provides:

  • Reduced complexity
  • Better security
  • Enterprise compatibility
  • Lower operational overhead
  • Future-proof integrations

Looking Ahead

Authentication alone is not enough.

Once authenticated, engineering operations must execute within the correct engineering context.

Projects.

Clusters.

Namespaces.

Organizations.

The next article explores why engineering context is essential for deterministic execution.

Conclusion

Engineering platforms have spent years building secure authentication systems.

An Engineering Runtime should not replace those investments.

Instead, it should build upon them.

By separating authentication from execution governance, organizations gain a secure, deterministic, and enterprise-friendly foundation for humans, CI/CD pipelines, and AI agents.

Design Principle

Authenticate using the platform. Govern using the runtime.

Next Article

Context-Aware Engineering Execution