story: MCP backend with isolated terminals

[dweidenfeld]

User Story

As a Platform Mesh user,
I want AI agents to execute Kubernetes commands in isolated terminal sessions limited to my existing permissions,
so that they can inspect Platform Mesh resources securely without receiving broader access.

Acceptance Criteria

• Given an agent session, when it starts, then an isolated short-lived terminal environment is created and owned by the Agentic UI MSP.
• Given an isolated terminal, when a command is executed, then the backend captures its exit code, standard output, and standard error.
• Given the terminal runtime image, then kubectl, jq, and yq are available.
• Given multiple kubeconfig contexts, when a command is executed, then the target context must be selected explicitly.
• Given a user-scoped kubeconfig, when the terminal is running, then the kubeconfig exists only in temporary memory-backed storage.
• Given the user KCP permissions, when commands are executed, then the terminal cannot access resources outside those permissions.
• Given an agent terminal, then it runs as non-root with a read-only root filesystem and dropped Linux capabilities.
• Given network access from the terminal, then egress is restricted to the required KCP endpoints.
• Given command execution, then configurable timeouts and output limits are enforced.
• Given command execution, then an audit record is produced without exposing credentials.
• Given a closed or expired session, then its terminal, credentials, and temporary files are removed.
• Given existing human terminal functionality, then the agent runtime remains independent from terminal-controller-manager and human ttyd sessions.
• Given the Platform Mesh local setup, then automated integration tests prove allowed reads, permission isolation, timeout handling, output limits, and cleanup.
• Given the complete implementation, then an end-to-end test demonstrates an agent inspecting Platform Mesh resources through the isolated terminal.

Definition of Done

• All acceptance criteria are met.
• Automated tests run in CI.
• The code has been peer reviewed.
• Security controls and operational configuration are documented.
• The implementation is deployed to an agreed Platform Mesh development environment.
• A short end-to-end demo has been presented.

Parent Epic

#159

Additional Context

Architecture:

https://github.tools.sap/ApeiroRA/architecture/pull/63

Relevant foundations:

platform-mesh/architecture#8

platform-mesh/architecture#29

This story covers the terminal execution backend only. The MCP API endpoint, authentication integration, UI, and skills are handled by separate stories.

The terminal backend must never receive admin, provider, MSP-cluster, default, or long-lived kubeconfigs.

The credential contract may be mocked or manually supplied for local testing. Final credential integration belongs to the authentication story.

Related existing work, potentially overlapping but intentionally tracked independently:

#283

[ifdotpy]

Scope aligned: the terminal backend is owned by the Agentic UI MSP. Sandbox MCP creates isolated, short-lived sandbox sessions; Platform Mesh core does not expose, manage, or need to know about terminals. terminal-controller-manager and existing human ttyd terminals are independent and out of scope.

The accepted backend boundary is explicit-context, user-scoped kubectl execution with ephemeral credentials, bounded read-only commands, isolation, and deterministic cleanup. The public MCP contract is tracked in #343; OIDC, context discovery, credential exchange, and refresh remain in #345.

The implementation is available in ApeiroRA/showroom-msp-agentic-ui and its ApeiroRA board mirror is ready for acceptance.

[ifdotpy]

Ready for acceptance: the scoped isolated-terminal boundary is complete and deployed to the agreed cc-d2 environment through GitOps. The acceptance suite and release verification cover permitted and forbidden reads, bounded execution, audit correlation, deterministic cleanup, and independence from the human terminal stack.

Implementation: PR #58. Deployment: release 0.1.32 via GitOps PR #544. Authentication and token refresh remain scoped to #345.

[dweidenfeld]

Correction: the previous result came from testing the wrong account endpoint. I repeated the test with the correct demo account endpoint (83ud348g32q492vu) and OAuth session. The MCP resolved to the intended demo workspace, not my personal workspace. Account scoping and permission isolation therefore worked as expected. I removed the MCP configuration after the successful test. The permission-isolation acceptance criterion can be accepted.