IMMANENT LABS
CUSTOMER WALKTHROUGH / GOVERNED FLOW

From blocked
to governed.

A guided upgrade story that shows what an AI agent can discover, what it must ask permission to change, and how every mutation gets closed with evidence.

Run the live lab Read the guided flow
01 Read-only assessment
02 Approval-gated mutation
03 Restored + auditable
THE CUSTOMER STORY

Show the guardrails
while the work happens.

This is not a narrated checklist. Move through the same state changes a platform team would see in production, and make the boundary between observation, approval, and execution explicit.

The core promise

The agent starts with read-only access. After approval, a short-lived credential is exchanged with narrowly scoped Kubernetes RBAC. The original disruption guarantee is restored and recorded with evidence.

01
Assess

Start with evidence, not execution

What you see

Let us see whether this sandbox target is actually ready to move.

How it works

The agent reads the target Kubernetes API with a read-only identity and returns assessment findings.

try.immanentlabs.ai / sandbox
BLOCKED
Illustrative product view/Not a live screenshot
Upgrade readiness
sandbox target / governed upgrade
sandbox targettarget version check
PDB blocker

Example PDB allows 0 disruptions

Deprecated APIs

Owner migration required before upgrade

02
Explain

Turn blockers into ownership

What you see

The platform is telling us what needs an owner, not hiding the work behind a green button.

How it works

Example deprecated API findings are grouped into owner work items. They remain hard blockers and are never auto-edited.

try.immanentlabs.ai / sandbox
ACTION REQUIRED
Illustrative product view/Not a live screenshot
Owner migration queue
sandbox target / governed upgrade
platform-engineeringexample findings
FLOWCONTROL.APISERVER.K8S.IO
FlowSchema / PriorityLevelConfiguration
v1beta2 -> v1
Proposal generated for owner review
THE CONTROL PLANE VIEW

A mutation is a
four-party conversation.

The governed workflow does not ask the target Kubernetes API to trust the model. The agent, AIP, reviewer, and target Kubernetes API each have a narrow job.

01READ

Agent

Discovers state and proposes the next safe action.

02DECIDE

AIP

Checks governed resource, policy, OpsLock, and approval.

03AUTHORIZE

Reviewer

Approves the intent as a separate identity.

04EXECUTE

Target Kubernetes API

Applies the approved PDB change and returns target state.

A connector is future architecture for downstream services; it does not participate in this hosted demo.

LAB BOUNDARY

What is real in this lab

The walkthrough separates the governed Kubernetes workflow from provider operations that are represented for the customer story.

Real
  • Read-only assessment
  • AIP AgentRequest, policy evaluation, reviewer approval, and OpsLock
  • OIDC token exchange
  • Kubernetes PDB relaxation and restoration with evidence
Simulated
  • AKS/Azure provider control-plane calls
  • AKS/Azure nodepool upgrade calls
GUIDED FLOW

Eight steps.
One governed run.

Follow the flow with the customer. The page stays focused on the decision boundary instead of requiring tool names or JSON payloads.

Open the hosted lab
03
Request

Ask for the smallest safe exception

We need a temporary PDB change for this maintenance window. Nothing has changed yet.

How it works

A governed AgentRequest is created. The baseline agent still has no write capability.

04
Approve

Separate intent from authority

A reviewer approves the request. The agent cannot approve its own work.

How it works

AIP evaluates policy, records the reviewer decision, acquires the OpsLock, and makes the request eligible for token exchange.

05
Execute

Use temporary authority

After approval, the agent uses a short-lived credential restricted by narrowly scoped Kubernetes RBAC.

How it works

AIP exchanges a short-lived credential after approval. The agent uses it through a token-only Kubernetes client to relax the PDB.

06
Observe

Keep the operation visible

The console shows the observed target state instead of asking us to trust a log line.

How it works

The platform correlates the intent, governance decision, execution result, target state, and audit events.

07
Restore

Close the temporary window

The exception is temporary. We restore the original disruption guarantee when the work is complete.

How it works

Cleanup uses the same governed token path and is idempotent. A failed restore stays visible and retryable.

08
Prove

Finish with an evidence bundle

Here is exactly what was approved, what changed, and what was restored.

How it works

The final record distinguishes control-plane facts from agent-reported execution facts and includes correlation IDs.

PLANNED NEXT

Coming next: governed source remediation

Planned behavior: generate a review-ready migration proposal, validate it against the target Kubernetes version, and open a draft GitHub PR for the owning team. It will never auto-merge or deploy application changes. The current demo produces a proposal artifact only.

READY FOR A SUPERVISED PILOT

Let the customer
touch the boundary.

A disposable sandbox. A real approval path. A visible token exchange. No ambient write access.

Launch the governed lab Back to Immanent Labs