Demo data

Setting DEMO_DATA=true on the backend registers everything three approval-gated, mutating examples need — "launch an EC2 instance", "restart a GKE pod", and "rotate an Azure Key Vault secret" — in the seeded Default tenant, so there is something to run without registering every piece by hand. The workflow itself is deliberately not seeded — these records are the ingredients you generate one from, and the Walkthrough is the tour that does it.

Enabling it

Add the flag to backend/.env and restart the backend. With Docker Compose it is already on: compose.yml sets DEMO_DATA: ${DEMO_DATA:-true}.

DEMO_DATA=true
DEMO_PASSWORD=change-me-now-123
DEMO_AWS_ACCESS_KEY_ID=AKIA...
DEMO_AWS_SECRET_ACCESS_KEY=...
DEMO_AWS_REGION=us-east-1
DEMO_GCP_CREDENTIALS_JSON='{"type":"service_account",...}'
DEMO_AZURE_TENANT_ID=...
DEMO_AZURE_CLIENT_ID=...
DEMO_AZURE_CLIENT_SECRET=...

• DEMO_PASSWORD is shared by all eleven demo users and has the same generate-and-log-once fallback as ROOT_PASSWORD / ADMIN_PASSWORD. It is only consulted while one of the accounts is missing.
• The AWS credentials, the Google Cloud credential, and the Azure credentials are optional. Left unset, a REPLACE_ME placeholder is stored instead, so the demo is complete in shape and you fill the real values in from the Secrets page.
• DEMO_AWS_REGION is the region the demo AWS MCP server's tools act on. It defaults to us-east-1.
• DEMO_GCP_CREDENTIALS_JSON is a Google Cloud credential JSON on a single line — a service account key, or the authorized-user JSON gcloud writes after a one-time sign-in with an OAuth client ID and secret. The GKE MCP server mints its access token from it; Google's MCP servers do not accept API keys. See Google Cloud MCP servers for how to obtain either.
• DEMO_AZURE_TENANT_ID, DEMO_AZURE_CLIENT_ID, and DEMO_AZURE_CLIENT_SECRET are an Azure service principal — the tenant, the app's client id, and one of its client secrets, as az ad sp create-for-rbac prints them. On the vault the demo should rotate secrets in, grant it a custom role with only the Microsoft.KeyVault/vaults/secrets/readMetadata/action and Microsoft.KeyVault/vaults/secrets/setSecret/action data actions — or, on a vault that uses access policies, only the List and Set secret permissions. The built-in Key Vault Secrets Officer role also works, but it can read every secret's value as well.

⚠️ The AWS, GKE, and Azure MCP servers can run mutating operations, not just reads. The AWS MCP server's credentials can create and delete real AWS resources, the GKE MCP server's identity can roll out a restart of a workload, or delete a pod, on a real cluster, and the Azure MCP server's service principal can write Key Vault secrets — use throwaway accounts or tightly scoped credentials for all three. To try any of them without touching a real provider at all, see Trying it out below.

What gets registered

• Agent skill Demo AWS EC2 Launch — gathers the instance configuration, gets a manager's explicit approval of it, then launches the instance through an MCP tool. Its repository is cloned in the background after startup, so the skill shows as pending for a moment before it can be used.
• Agent skill Demo GKE Pod Restart — agrees the exact target (project, cluster, namespace, and either a Deployment/StatefulSet name or a single pod name) with the user, gets a manager's explicit approval of that exact target, then, by default, rolling-restarts the workload through the GKE MCP Server — or, when the user wants just one pod gone, deletes that pod so its owning controller recreates it — and reports the outcome. Its repository is cloned the same way, so it also shows as pending at first.
• Agent skill Demo Azure Key Vault Secret Rotation — agrees the Key Vault and an existing secret in it with the user, gets a manager's explicit approval of that exact secret, then writes a freshly generated random value as the secret's new version through the Azure MCP Server and reports when the new version was created. It never shows the value in the chat. Its repository is cloned the same way, so it also shows as pending at first.
• MCP server AWS MCP Server — a stdio server reaching AWS's managed AWS MCP Server, which is where the EC2 tools come from.
• MCP server GKE MCP Server — a streamable_http server reaching Google Cloud's managed GKE (Google Kubernetes Engine) MCP server, the full endpoint. Its Authorization header is Bearer ${gcp-token:demo-gcp-credentials/GOOGLE_CREDENTIALS_JSON}, so every connection sends a fresh access token minted from the demo-gcp-credentials secret, and its tools can manage clusters and their Kubernetes resources, including rolling-restarting a workload or deleting a pod.
• MCP server Azure MCP Server — a stdio server running Microsoft's Azure MCP Server, limited to its Key Vault tools. It signs in with the service principal in the demo-azure-credentials secret, and its tools can list and write Key Vault secrets, keys, and certificates. Before every operation on a secret it asks for consent, and that question goes to the run's requester as a confirmation in the chat — on top of the manager's approval of the rotation. The demo skill tells the design agent to mark its tools as asking, so each task that uses one waits for the requester to resume it. The new secret value passes through the agent's conversation on its way to Key Vault, so treat a run's chat as you would the secret.
• MCP server EC2 Cost Estimator — a Python script server whose tools estimate the monthly On-Demand cost of an EC2 instance type (estimate_monthly_cost) and rank several by cost (compare_instance_types), using prices it fetches live from the AWS Price List for the region you ask about. It installs boto3 under Packages and reads the same demo-aws-credentials secret, so trying it in Test Run needs credentials allowed to read the AWS Price List (pricing:GetProducts). It only reads.
• MCP server Kubernetes Manifest Toolkit — a JavaScript script server whose tools check a Kubernetes manifest for missing required fields (validate_manifest) and build the patch that rolling-restarts a Deployment, StatefulSet, or DaemonSet (build_restart_patch). It installs js-yaml under Packages, needs no credentials, and never reaches a cluster, so it works in Test Run straight away.
• MCP server Secret Value Generator — a JavaScript script server whose one tool generates a cryptographically random secret value (generate_secret_value). It installs no packages, needs no credentials, and never reaches Azure, so it works in Test Run straight away.
• Knowledge base AWS EC2 Pricing — holds one source, ec2-on-demand-pricing.pdf: a price sheet with the hourly and monthly On-Demand cost, vCPU, and memory of the ten instance types the Walkthrough offers, in us-east-1, us-east-2, and us-west-2, plus storage and public IP charges. The figures are reference values for the demo. The source is registered as Not read, so the knowledge base has no pages until someone clicks Read on it; the Walkthrough has the AWS developer do that. Linked to an EC2-launch workflow, it lets the agent answer what the requested instance will cost.
• Secret demo-aws-credentials — the AWS access key id and secret access key the AWS MCP Server reads.
• Secret demo-gcp-credentials — the Google Cloud credential JSON the GKE MCP Server mints its access token from.
• Secret demo-azure-credentials — the Azure service principal's tenant id, client id, and client secret the Azure MCP Server signs in with.
• Tool mocks — stubs for the demo run's side-effecting tools: aws___call_aws and aws___run_script on the AWS MCP Server, each returning a successful launch, patch_k8s_resource and delete_k8s_resource on the GKE MCP Server, returning a successful rolling restart and a successful pod deletion respectively, keyvault_secret_get and keyvault_secret_create on the Azure MCP Server, returning a list of the vault's secrets and a new secret version respectively, and the built-in request_approval, returning approved. Selecting them in a draft run's Run dialog lets any of the three workflows finish without touching AWS, a real GKE cluster, a real Key Vault, or waiting on a manager.
• Tags AWS, GCP, and Azure — each an access-control tag, so only Demo AWS Group / Demo GCP Group / Demo Azure Group members (and admin, or a super admin) can see that provider's tagged records above. EC2 Cost Estimator and the AWS EC2 Pricing knowledge base carry AWS, Kubernetes Manifest Toolkit carries GCP, and Secret Value Generator carries Azure, alongside the provider records they help with. Approval Required is a plain tag on all three agent skills and restricts nothing.
• Demo users and groups:

User	Role	Access-control group	What they do
demo-aws-developer	developer	Demo AWS Group	Generates the EC2-launch workflow
demo-aws-reviewer	reviewer	Demo AWS Group	Publishes the EC2-launch workflow
demo-aws-requester	requester	Demo AWS Group	Runs the EC2-launch workflow
demo-gcp-developer	developer	Demo GCP Group	Generates the GKE-pod-restart workflow
demo-gcp-reviewer	reviewer	Demo GCP Group	Publishes the GKE-pod-restart workflow
demo-gcp-requester	requester	Demo GCP Group	Runs the GKE-pod-restart workflow
demo-azure-developer	developer	Demo Azure Group	Generates the secret-rotation workflow
demo-azure-reviewer	reviewer	Demo Azure Group	Publishes the secret-rotation workflow
demo-azure-requester	requester	Demo Azure Group	Runs the secret-rotation workflow
demo-approver-1, demo-approver-2	approver	Demo Approvers (all three tags)	Approve the launch, the pod restart, or the rotation

None of them holds its role directly: each inherits it from a user group — Demo Developers, Demo Reviewers, Demo Requesters, and Demo Approvers. The AWS, GCP, and Azure trios each also belong to a second group, Demo AWS Group, Demo GCP Group, or Demo Azure Group, that grants no role of its own — its only purpose is holding the matching access-control tag, so that trio can see that provider's tagged records and everyone else cannot, except admin (or a super admin), who bypasses access-control tags entirely and needs no group membership for it. Demo Approvers itself carries the AWS, GCP, and Azure access-control tags directly, since an approver is not scoped to one provider — this is also what makes either demo approver an eligible destination for a request addressed to them, whichever of the three demo workflows it comes from.

Trying it out

The Walkthrough plays any of the examples through end to end — generate, publish, run, approve, confirm — from a single root sign-in, impersonating each demo account in turn. Signing in as each account with DEMO_PASSWORD works just as well; the table above says who does what.

Demo AWS Group, Demo GCP Group, and Demo Azure Group each see only their own provider's records, so demo-aws-developer cannot open Demo GKE Pod Restart, and demo-gcp-developer cannot open Demo Azure Key Vault Secret Rotation. Either approver account works for every example, since Demo Approvers carries all three access-control tags directly. A real GKE run needs DEMO_GCP_CREDENTIALS_JSON set to a credential whose identity may reach a real GKE cluster, and a real rotation needs the DEMO_AZURE_* service principal to hold write access to secrets in a real vault.

No AWS account, GKE cluster, or Key Vault? Do not publish: run the workflow while it is still draft — as a developer, the provider's developer account (demo-aws-developer, demo-gcp-developer, or demo-azure-developer) may do that, and only a draft run's dialog offers the tenant's tool mocks. Under Mock tools, check the seeded stubs it lists (aws___call_aws or aws___run_script for the launch, patch_k8s_resource or delete_k8s_resource for the pod restart, keyvault_secret_get and keyvault_secret_create for the rotation, and request_approval); the whole workflow then plays through without reaching a real provider or waiting on a human. With the rotation's mocks checked, the vault's secret list is made up too: pick db-password from it.

Removing it

Setting DEMO_DATA=false (or removing the line) removes those records again on the next startup — the flag is declarative in both directions.

Two things survive by design: a demo record something else has come to depend on — a workflow built on the demo skill, for instance — is kept and logged rather than deleted, and a demo user who has created records is soft-deleted so their name still resolves on those records.