Isolation des charges de travail exécutables

Scrydon utilise une fabrique d'exécution unique pour les charges de travail exécutables. Chaque charge est liée à un seul niveau avant son démarrage :

Il n'existe aucun repli vers une exécution en cours de processus dans Agentic, API Platform ou Analytics. Une exécution ne change jamais de niveau après son démarrage.

Qui contrôle le niveau

Les opérateurs du déploiement choisissent les backends présents en déployant le Runtime Plane et/ou l'hôte d'acteur géré. Scrydon privilégie toujours microvm. Un administrateur d'organisation contrôle Exiger l'exécution isolée dans Paramètres → Plateforme → Compute :

• Option activée ou non définie : seul microvm est admissible. S'il est indisponible, la charge est refusée.
• Option désactivée : microvm reste prioritaire ; Scrydon peut se replier sur managed_process lorsque son profil d'acteur est prêt.

Une intégration ou une capacité peut exiger microvm malgré l'assouplissement de l'organisation. Les paramètres d'organisation ne peuvent pas rendre disponible un backend non déployé ou non prêt.

Où chaque charge s'exécute

Les deux niveaux réutilisent les mêmes runners détenus par la plateforme :

• Les tours Agent utilisent le runner de bundle Agent borné.
• Les blocs Fonction utilisent le profil QuickJS du runner de bundle fournisseur.
• Les implémentations d'intégrations fournisseur utilisent le runner de bundle fournisseur et le courtier de sortie de confiance.
• Les jobs de notebook utilisent le runtime de job Marimo et le courtier de stockage.

Le niveau d'exécution modifie le placement et le propriétaire du cycle de vie ; il ne crée pas une seconde implémentation du protocole Agent, Fonction, intégration ou notebook.

Espace de travail et outils Agent

Un tour Agent possède un /workdir éphémère pendant toute sa session bornée. Les outils locaux au runner incluent l'exécution shell et les opérations de lecture, écriture et listage de fichiers. L'image du runner fournit notamment Git, curl, ripgrep, jq, Node.js, npm, Python, make et des utilitaires d'archive.

L'espace de travail est détruit à la fin du tour. Il ne persiste pas dans un autre bloc, une autre exécution de workflow ou un autre tour de conversation.

Outils que cet Agent ne peut pas exécuter

Toutes les intégrations ne peuvent pas s'exécuter dans un tour d'Agent isolé. Lorsqu'un outil sélectionné n'y est pas disponible, le tour est refusé avant l'appel au modèle.

Le refus nomme les outils concernés uniquement avec leur libellé lisible ; il n'inclut jamais d'identifiant d'outil interne avec portée ni d'UUID d'organisation. Retirez chaque sélection non prise en charge du bloc Agent, puis relancez le workflow. Une intégration activée dans les Paramètres n'est pas automatiquement disponible dans cet Agent isolé.

Identifiants et appels à la plateforme

Les charges exécutables ne reçoivent aucun identifiant réutilisable de fournisseur, OAuth, base de données, Dapr ou Kubernetes.

• Les appels Agent utilisent des autorisations racine et par action à courte durée de vie.
• Le code source d'une Fonction ne reçoit aucune autorisation d'identifiant ou de sortie réseau.
• Le code du runner fournisseur reçoit des autorisations d'invocation et un socket privé vers le courtier ; seul le courtier de confiance reçoit l'autorisation opaque d'accéder aux identifiants.
• Le code d'un notebook reçoit des capacités de stockage limitées à l'exécution via son courtier.

Chaque autorisation est liée à l'organisation, l'espace de travail, l'exécution, le plan, l'opération, les budgets et l'expiration. La plateforme la révoque pendant le nettoyage terminal ; sa durée de vie reste la borne finale si la révocation ne peut pas être confirmée.

Accès réseau

Installer un client réseau n'accorde aucun accès réseau. Les charges microVM utilisent le mur de sortie du Runtime Plane. Les implémentations fournisseur en processus géré passent par le même contrat de courtier fournisseur de confiance. L'instantané de sortie de l'organisation et les réseaux bloqués par le déploiement restent la référence.

Comportement en cas d'échec

Avant l'envoi, la sélection vérifie les backends déployés, l'exigence de l'organisation, le minimum de la capacité, l'authentification du backend et l'état de préparation du profil de charge. L'ordre produit est microVM d'abord, puis processus géré uniquement si l'organisation l'autorise.

• Si l'organisation exige l'isolation et que la microVM n'est pas prête, l'exécution est refusée.
• Si l'assouplissement est autorisé mais que le profil d'acteur géré est indisponible, l'exécution est refusée.
• Si le runner sélectionné échoue, la tentative échoue sur ce niveau. Scrydon ne la relance pas sur un backend plus faible.
• Si l'hôte d'acteur redémarre pendant l'exécution d'un enfant, le résultat est signalé comme incertain après récupération ; le code arbitraire n'est pas rejoué silencieusement.

Prise en charge des déploiements

Pour le développement local :

• bun run dev:all démarre l'hôte d'acteur en processus géré et ne requiert ni KVM, ni Runtime Plane Rust, ni invité Apple Container.
• bun run dev:all --mode=isolated utilise uniquement les microVM et démarre le chemin Runtime Plane.

Pour les valeurs Helm et la qualification de production, consultez la documentation de déploiement.