Isolation des étapes non fiables

Comment l’Agent standard s’exécute dans un espace Kata isolé, quelles opérations y restent et quelles adoptions du Runtime Plane sont différées.

Le chemin produit actuel du Runtime Plane est le bloc Agent standard. Avec la politique Kata-first livrée, un bloc Agent exécute toute sa session modèle/outils bornée dans un pod Kata neuf et à usage unique. Un déploiement peut accepter explicitement le niveau hardened, plus faible, mais ce profil ne constitue pas une garantie Kata ou vraie VM.

Cette garantie est volontairement étroite. Les adoptions Runtime Plane pour Tool, Capability, Function, Condition, Connection, MCP et Marimo/Notebook sont différées. Les chemins produit hors Agent ne sont pas couverts par cette garantie d’isolation.

Ce qui s’exécute dans le pod Agent

L’Agent possède un /workdir éphémère pendant toute sa session bornée. Ses outils locaux sont :

run_shell ;
read_file ;
write_file ;
list_dir.

L’image contient notamment Git, curl, ripgrep, jq, Node.js, npm, Python, make et des utilitaires d’archive. Une séquence clone → installation → build → tests observe le même système de fichiers.

La correction de sortie structurée reste dans cette même session. Elle ne crée pas un second pod pour le même bloc Agent.

Le pod et son système de fichiers sont détruits à la fin du bloc. Ils ne sont jamais réutilisés par un autre bloc, une autre exécution ou un autre tour de conversation.

Rappels vers la plateforme

L’Agent reçoit une capacité racine de courte durée qui autorise exactement :

la complétion LLM ;
la recherche web sans credential dans le pod.

Tout autre outil de plateforme ou d’intégration sélectionné est refusé avant la construction de l’enveloppe et avant la création d’un pod. L’erreur visible est AGENT_PLATFORM_TOOL_UNSUPPORTED.

Si le rappel n’est pas configuré, l’exécution s’arrête avant soumission avec AGENT_CALLBACK_UNAVAILABLE.

Cette version ne contient aucun grant d’action par outil, aucune référence de connexion, aucun courtier d’action hôte et aucun courtier de credentials. Les clés API fournisseur et jetons OAuth n’entrent jamais dans le pod.

Sélectionner GitHub, Slack, MCP, storage, workflow ou un autre outil d’intégration ne le rend pas disponible dans l’Agent isolé. Retirez cette sélection ou utilisez un chemin produit distinct jusqu’à la livraison d’une adoption gouvernée dédiée.

Accès réseau

Git, npm, curl, Python et les autres commandes locales utilisent le réseau du pod. Cet accès reste gouverné par l’instantané immuable de politique de sortie et par l’enforcer de confiance.

Installer un client n’accorde aucun accès réseau. Chaque dépôt, registre, package ou dépendance doit être autorisé par la politique d’organisation.

Le plan de contrôle ajoute uniquement l’hôte de transport du rappel appartenant à la plateforme. Les entrées du workflow, la sortie du modèle et les commandes shell ne peuvent pas élargir cet instantané.

Isolation et cycle de vie

La plateforme — jamais l’auteur du workflow ou de l’intégration — décide de l’isolation.

Agentic résout les politiques d’isolation et de sortie de l’organisation.
Il vérifie la configuration du rappel.
Il prévalide tous les outils sélectionnés.
Il construit une enveloppe agent_turn sans credential.
Le Runtime Plane Rust authentifie l’appelant et crée un pod au niveau résolu ; la politique livrée n’admet qu’un niveau Kata qualifié.
Le runner exécute la boucle modèle/outils bornée dans un seul /workdir.
Le Runtime Plane enregistre l’état terminal puis détruit le pod.
Le grant de rappel racine est révoqué ; sa durée de vie reste la limite finale si la révocation ne peut pas être confirmée.

Aucun réglage de workflow ne peut renvoyer cet Agent vers une exécution sur l’hôte applicatif.

Frontière des credentials

Le pod Agent ne possède :

ni sidecar Dapr ni identité mesh ;
ni jeton de ServiceAccount Kubernetes ;
ni clé API fournisseur ni jeton OAuth ;
ni environnement hôte, cloud ou source-control ;
ni grant d’action par outil.

Il reçoit seulement un bearer de rappel limité à l’exécution, avec allowlist exacte, budgets de requêtes et d’octets, expiration, enregistrement et révocation. Les processus shell enfants reçoivent un environnement explicitement sans credential.

Surfaces Runtime Plane différées

Surface différée	Frontière de cette PR
Bundles Tool fournisseur	Pas une unité du runner Agent ; nécessite un producteur et un contrat de sécurité dédiés
Bundles Capability fournisseur	Pas une unité du runner Agent
Blocs Function	Le comportement produit existant reste hors de cette garantie Agent
Blocs Condition	Le comportement produit existant reste hors de cette garantie Agent
Blocs Connection HTTP, SSH et SFTP	Pas une unité du runner Agent
MCP	Ni unité du runner Agent ni route du rappel racine
Ancien chemin `agent` autonome / coding-agent	Supprimé ; l’Agent standard est l’unique produit Agent
Runtime et allocation Marimo/Notebook	Différés vers une issue et une PR séparées au-dessus du Runtime Plane Agent

Le transport opaque du Runtime Plane ne prouve pas, à lui seul, qu’une surface différée l’a adopté. Chaque future adoption nécessite son propre producteur, schéma de runner, contrat de credentials/sortie et preuve de bout en bout.

Exigences opérationnelles

Cible de déploiement	Frontière maximale	Qualification requise
AKS avec Pod Sandboxing	`microvm`	Pool Kata managé, nœud Ready correspondant et preuve du candidat exact
Kubernetes autogéré ou k3s sur Linux/KVM	`microvm`	RuntimeClass Kata/QEMU, KVM, CNI appliqué et preuve native-node
Kubernetes générique sans Kata/KVM	`hardened`	Opt-in explicite au profil plus faible, admission et preuve de non-contournement
EKS, GKE, OpenShift et autres Kubernetes managés	`hardened`	Qualification propre au fournisseur avant toute garantie plus forte
Offre Azure Marketplace officielle	Aucune	Les images Runtime Plane et la qualification AKS ne sont pas encore intégrées
Package Kubernetes air-gap officiel	`microvm`	Import des images épinglées et preuve complète du chemin Kata hors ligne
Docker Compose, Docker Desktop et macOS natif	Aucune	Déléguer l’exécution à un déploiement Kubernetes Linux qualifié

Un déploiement doit fournir un nœud Kata/KVM et la RuntimeClass kata-vm-isolation, des images runner/enforcer immuables, le chemin de contrôle authentifié Agentic → Runtime Plane, la configuration du rappel, les politiques d’organisation et l’application réseau du namespace de workload.

Si ces exigences ne sont pas satisfaites, l’Agent refuse l’exécution au lieu de déplacer la session sur l’hôte applicatif.

Consultez la documentation de déploiement pour les détails des niveaux et de la qualification.