Zero-trust deployment, a fail-closed vault, and defense-in-depth built for an autonomous fleet.
A customer security team does not buy controls — it buys coverage against a framework it already reports on. Vosj is built so the safety-critical controls live in the engine, not in policy a template author can switch off; so the default is fail-closed; and so the autonomous fleet runs inside trust boundaries the customer's auditors already recognise. This page is the security contract, mapped to NIST CSF 2.0 and ISO/IEC 27001:2022.
The safety invariants (no-self-sign, fail-closed vault, verified-before-cutover) are enforced in the data model and gate machine — not advisory policy. They cannot be disabled by a template author or satisfied by a waiver.
🔒
Fail-closed by default
No master key → the vault refuses to operate; no verified state → no cutover. Absence of proof never resolves to "allow".
🕵️
Assume breach, verify always
Written to the zero-trust tenets of NIST SP 800-207: never trust, always verify; least privilege; assume breach. Every action is attributable to one identity.
Defense-in-depth for the autonomous fleet
The governing concern with an autonomous fleet is not that an agent does work — it is that a non-human actor could capture the chain of authority, or that a compromised station could pivot. Vosj layers controls so no single failure is catastrophic:
IDENTITY & LEAST PRIVILEGE Per-engagement, scoped, revocable grants only; just-enough/just-in-time; access withdrawn at Jump. Each station carries a SPIFFE/SPIRE-style or federated-OIDC workload identity.
NETWORK & EGRESS Default-deny egress per station namespace (allow-list: target · model · SCM · DNS) — the leg that breaks the "lethal trifecta". Private connectivity to customer data planes; micro-segmentation between fleet roles.
RUNTIME ISOLATION Hardened RuntimeClass (gVisor / Kata / Firecracker) for code-executing stations; one station = one identity = one clone.
SECRETS & KEY CUSTODY Fail-closed vault; master key in a KMS/HSM with split-knowledge custody; the HMAC ledger key custodied outside the database so a DB compromise cannot forge gate rows.
APPLICATION & DATA Capability-based RBAC (requireAuth/requireCapability on every route/mutation); per-tenant query isolation; encryption in transit and at rest; DPA / SCCs for any cross-border movement.
DETECT · RESPOND · RECOVER Immutable tool-call log; behavioural baselining vs the approved runbook; per-station kill-switch + queue freeze; verified-before-cutover with an independent rehearsed rollback.
Trust boundaries
The fleet runs in its own namespace with no standing path into the customer estate. Access is brokered, scoped and time-boxed; the data transfer runs on the source host through a sanctioned transport, not a gateway-local copy.
No standing trust: the fleet reaches the customer estate and external services only through scoped grants and an explicit egress allow-list.
Identity & credential brokering
Stations never hold long-lived shared keys. The MCP Hub mints short-TTL, audience-scoped downstream tokens per task; client tokens are never passed through (confused-deputy prevention, RFC 8707 audience validation). Cutover, decommission and credential rotation are owner/admin-gated.
The broker, not the station, decides what a downstream call may do — and for how long.
The AI / MCP / LLM threat surface
Autonomy adds attack classes a classic migration tool does not face. Vosj's threat model covers them explicitly, anchored to the OWASP LLM Top 10 (2025), the Agentic Security Initiative / MAESTRO, and MITRE ATLAS:
Prompt & tool poisoning
Source content and tool responses are treated as untrusted; external MCP servers are pinned and allow-listed; tool metadata is statically validated before model exposure; descriptor-drift raises alerts. (OWASP LLM01/LLM03/LLM05.)
Excessive agency
Agents are minted without any sign-as capability; irreversible steps escalate to a human; tool-call sequences are monitored against the approved runbook. (OWASP LLM06.)
The "lethal trifecta"
Private data + untrusted content + exfiltration channel. Default-deny egress removes the channel; the trifecta cannot complete even if a station ingests a hostile instruction.
Confused deputy
The Hub validates token audience and never passes a client token downstream, so a station cannot trick the broker into acting with someone else's authority.
Control framework mapping — NIST CSF 2.0 & ISO/IEC 27001:2022
The table maps Vosj's structural controls onto the six functions of the NIST Cybersecurity Framework 2.0 and onto the relevant ISO/IEC 27001:2022 Annex A themes — the artefact to drop into a vendor-security questionnaire or a GRC tool.
CSF 2.0
Vosj control evidence
ISO/IEC 27001:2022 Annex A
GOVERN
Safety invariants enforced in the engine; change-management + CD closure per task; documented autonomy posture (humans hold gates); DPA / sub-processor disclosure + legal sign-off before launch; per-engagement risk register.
Verified-before-cutover + independent rehearsed rollback; quorum sync PostgreSQL replication, WAL/PITR, stated ledger RPO/RTO; source kept serving until equivalence holds; post-mortem feeds the template.
A.5.29, A.5.30, A.8.13, A.8.14
For SOC 2 the same evidence supports the Trust Services Criteria: ledger + RBAC → Security; HA/DR + keepalive → Availability; multi-category reconciliation → Processing Integrity; fail-closed vault + least-privilege → Confidentiality; DPA / cross-border posture + PII handling → Privacy (and ISO/IEC 27018 for cloud PII).
Security sign-off — POC & Production gates
Deployment is gated by a runnable checklist. Each item is binary (PASS / FAIL / N/A) with evidence and a named signer; a FAIL on a fail-closed item blocks the gate. The POC gate qualifies a scoped, time-boxed pilot (no irreversible action on production data); the Production gate additionally requires the full control set before any live data or cutover. A representative selection:
POC gate (excerpt)
Scope agreed in writing; non-production / masked data only.
Access delegated, scoped, time-boxed, revocable — no shared keys.
Confused-deputy controls (RFC 8707 audience; no token pass-through).
Independent pen-test incl. AI red-team; residual risk accepted.
The full 12-item POC and 15-item Production checklists, with evidence and framework references, are in the technical white paper (Appendix H).
Residual risk & acceptance
No system is risk-free. Vosj makes residual risk explicit: a register is reviewed and formally accepted by the customer authority before the first production wave, with framework coverage (CSF / ISO / SOC 2) attested. Risk is governed, time-boxed and visible — never silent.
Déploiement zéro confiance, coffre-fort à fermeture sécurisée par défaut, et défense en profondeur conçue pour une flotte autonome.
Une équipe sécurité cliente n'achète pas des contrôles — elle achète une couverture vis-à-vis d'un référentiel qu'elle rapporte déjà. Vosj est construit de sorte que les contrôles critiques résident dans le moteur, et non dans une politique qu'un auteur de modèle peut désactiver ; que le comportement par défaut est la fermeture sécurisée ; et que la flotte autonome opère dans des périmètres de confiance que les auditeurs du client reconnaissent déjà. Cette page constitue le contrat de sécurité, mappé sur NIST CSF 2.0 et ISO/IEC 27001:2022.
Les invariants de sécurité (pas d'auto-signature, coffre-fort à fermeture sécurisée, vérification avant basculement) sont appliqués dans le modèle de données et la machine d'état — et non dans une politique consultative. Ils ne peuvent être désactivés par un auteur de modèle ni satisfaits par une dérogation.
🔒
Fermeture sécurisée par défaut
Pas de clé maître → le coffre-fort refuse de fonctionner ; pas d'état vérifié → pas de basculement. L'absence de preuve ne se résout jamais en « autoriser ».
🕵️
Présupposer la compromission, toujours vérifier
Conçu selon les principes zéro confiance du NIST SP 800-207 : ne jamais faire confiance, toujours vérifier ; moindre privilège ; présupposer la compromission. Chaque action est attribuable à une identité unique.
Défense en profondeur pour la flotte autonome
La préoccupation majeure avec une flotte autonome n'est pas qu'un agent effectue des tâches — c'est qu'un acteur non humain pourrait s'emparer de la chaîne d'autorité, ou qu'une station compromise pourrait effectuer un pivotement. Vosj superpose des contrôles de sorte qu'aucune défaillance isolée ne soit catastrophique :
IDENTITY & LEAST PRIVILEGE Droits par engagement, délimités, révocables uniquement ; juste-suffisant/juste-à-temps ; accès retiré au Jump. Chaque station porte une identité de charge de travail de style SPIFFE/SPIRE ou OIDC fédéré.
NETWORK & EGRESS Refus de sortie par défaut par espace de noms de station (liste d'autorisation : cible · modèle · SCM · DNS) — le maillon qui brise le « trio léthal ». Connectivité privée vers les plans de données client ; micro-segmentation entre les rôles de la flotte.
RUNTIME ISOLATION RuntimeClass renforcé (gVisor / Kata / Firecracker) pour les stations exécutant du code ; une station = une identité = un clone.
SECRETS & KEY CUSTODY Coffre-fort à fermeture sécurisée ; clé maître dans un KMS/HSM avec garde partagée ; la clé de registre HMAC conservée hors de la base de données, de sorte qu'une compromission de la BD ne puisse falsifier les lignes de la porte.
APPLICATION & DATA RBAC basé sur les capacités (requireAuth/requireCapability sur chaque route/mutation) ; isolation des requêtes par locataire ; chiffrement en transit et au repos ; DPA / SCCs pour tout transfert transfrontalier.
DETECT · RESPOND · RECOVER Journal d'appels d'outils immuable ; analyse comportementale par rapport au runbook approuvé ; interrupteur individuel par station + gel de la file d'attente ; vérification avant basculement avec retour arrière répété de manière indépendante.
Périmètres de confiance
La flotte s'exécute dans son propre espace de noms sans voie permanente vers l'environnement client. L'accès est courtisé, délimité et limité dans le temps ; le transfert de données s'effectue sur l'hôte source via un transport autorisé, et non par une copie locale à la passerelle.
Aucune confiance permanente : la flotte n'accède à l'environnement client et aux services externes que par des droits délimités et une liste d'autorisation de sortie explicite.
Identité & courtage de justificatifs
Les stations ne détiennent jamais de clés partagées à longue durée de vie. Le MCP Hub émet des jetons en aval à courte TTL et délimités à l'audience par tâche ; les jetons client ne sont jamais transmis (prévention du député confus, validation d'audience RFC 8707). Le basculement, la mise hors service et la rotation des justificatifs sont soumis à l'approbation du propriétaire/administrateur.
C'est le courtier, et non la station, qui décide ce qu'un appel en aval peut faire — et pour combien de temps.
Surface de menace IA / MCP / LLM
L'autonomie introduit des classes d'attaques auxquelles un outil de migration classique n'est pas confronté. Le modèle de menace de Vosj les couvre explicitement, ancré sur l'OWASP LLM Top 10 (2025), l'Agentic Security Initiative / MAESTRO, et MITRE ATLAS :
Empoisonnement des invites & des outils
Le contenu source et les réponses des outils sont traités comme non fiables ; les serveurs MCP externes sont épinglés et inscrits sur liste d'autorisation ; les métadonnées des outils sont validées statiquement avant exposition au modèle ; toute dérive des descripteurs déclenche des alertes. (OWASP LLM01/LLM03/LLM05.)
Agentivité excessive
Les agents sont créés sans aucune capacité sign-as ; les étapes irréversibles remontent à un humain ; les séquences d'appels d'outils sont surveillées par rapport au runbook approuvé. (OWASP LLM06.)
Le « trio léthal »
Données privées + contenu non fiable + canal d'exfiltration. Le refus de sortie par défaut supprime le canal ; le trio ne peut se compléter même si une station ingère une instruction hostile.
Député confus
Le Hub valide l'audience du jeton et ne transmet jamais un jeton client en aval, de sorte qu'une station ne peut pas tromper le courtier pour qu'il agisse avec l'autorité d'un tiers.
Cartographie du référentiel de contrôle — NIST CSF 2.0 & ISO/IEC 27001:2022
Le tableau mappe les contrôles structurels de Vosj sur les six fonctions du NIST Cybersecurity Framework 2.0 et sur les thèmes pertinents de l'Annexe A de l'ISO/IEC 27001:2022 — l'artefact à intégrer dans un questionnaire de sécurité fournisseur ou un outil GRC.
CSF 2.0
Preuves de contrôle Vosj
ISO/IEC 27001:2022 Annexe A
GOVERN
Invariants de sécurité appliqués dans le moteur ; gestion des changements + clôture CD par tâche ; posture d'autonomie documentée (les humains tiennent les portes) ; DPA / divulgation des sous-traitants + validation juridique avant lancement ; registre des risques par engagement.
A.5.1, A.5.2, A.5.8, A.5.19–A.5.23, A.5.31
IDENTIFY
Inventaire centré sur l'application + DAG des dépendances ; empreinte 365° du système de livraison CI/CD ; disposition 7-R + risque/effort/TCO par charge de travail ; inventaire des serveurs MCP externes avec liste d'autorisation signée ; provenance de la chaîne d'approvisionnement.
A.5.9, A.5.21, A.5.7, A.8.8
PROTECT
RBAC basé sur les capacités sur chaque route/mutation ; pas d'auto-signature ; coffre-fort à fermeture sécurisée ; courtage de secrets + jetons à courte durée de vie délimités à l'audience ; RuntimeClass renforcé + isolation par pool de nœuds ; refus de sortie par défaut ; chiffrement en transit & au repos ; DLP/séparation de contenu.
Journal d'appels d'outils immuable ; surveillance comportementale des séquences d'appels d'outils par rapport au runbook ; garde contre la dérive de référence ; alertes de dérive des descripteurs ; surveillance de contingence continue pendant le basculement.
A.8.15, A.8.16, A.8.6, A.8.7, A.5.25
RESPOND
Inversion de contingence à trois voies pendant le basculement ; fenêtre d'acceptation révocable ; maintien de la flotte + vidange progressive ; runbook d'incident avec révocation des justificatifs + mise en quarantaine de la station ; interrupteur individuel par station + gel de la file d'attente.
A.5.24, A.5.26, A.5.27, A.5.5
RECOVER
Vérification avant basculement + retour arrière répété de manière indépendante ; réplication PostgreSQL en quorum synchronisé, WAL/PITR, RPO/RTO déclarés pour le registre ; source maintenue en service jusqu'à établissement de l'équivalence ; le post-mortem alimente le modèle.
A.5.29, A.5.30, A.8.13, A.8.14
Pour SOC 2, les mêmes preuves soutiennent les Trust Services Criteria : registre + RBAC → Sécurité ; HA/DR + maintien → Disponibilité ; réconciliation multi-catégories → Intégrité du traitement ; coffre-fort à fermeture sécurisée + moindre privilège → Confidentialité ; DPA / posture transfrontalière + traitement des PII → Vie privée (et ISO/IEC 27018 pour les PII dans le cloud).
Validation de sécurité — portes POC & Production
Le déploiement est conditionné par une liste de contrôle exécutable. Chaque élément est binaire (PASS / FAIL / N/A) avec une preuve et un signataire nommé ; un FAIL sur un élément à fermeture sécurisée bloque la porte. La porte POC qualifie un pilote délimité et limité dans le temps (aucune action irréversible sur les données de production) ; la porte Production exige en outre l'ensemble complet des contrôles avant toute donnée réelle ou basculement. Une sélection représentative :
Porte POC (extrait)
Périmètre convenu par écrit ; données hors production / masquées uniquement.
Accès délégué, délimité, limité dans le temps, révocable — pas de clés partagées.
Coffre-fort à fermeture sécurisée confirmé par test négatif.
Refus de sortie par défaut ; liste d'autorisation = cible / modèle / SCM / DNS.
RuntimeClass renforcé pour les stations exécutant du code.
Contrôles du député confus (audience RFC 8707 ; pas de transmission de jeton).
Test de pénétration indépendant incluant red-team IA ; risque résiduel accepté.
Les listes de contrôle complètes de 12 éléments (POC) et 15 éléments (Production), avec preuves et références au référentiel, figurent dans le livre blanc technique (Annexe H).
Risque résiduel & acceptation
Aucun système n'est exempt de risque. Vosj rend le risque résiduel explicite : un registre est examiné et formellement accepté par l'autorité cliente avant la première vague de production, avec attestation de la couverture du référentiel (CSF / ISO / SOC 2). Le risque est gouverné, limité dans le temps et visible — jamais silencieux.
Zero-Trust-Deployment, ein bei Ausfall gesperrter Tresor und Defense-in-Depth für eine autonome Flotte.
Ein Sicherheitsteam beim Kunden kauft keine Kontrollen — es kauft Abdeckung gegenüber einem Rahmenwerk, über das es bereits berichtet. Vosj ist so gebaut, dass sicherheitskritische Kontrollen im Motor verankert sind und nicht in einer Richtlinie, die ein Template-Autor abschalten kann; dass der Standard ein gesperrter Fehlerzustand ist; und dass die autonome Flotte innerhalb von Vertrauensgrenzen operiert, die die Prüfer des Kunden bereits kennen. Diese Seite ist der Sicherheitsvertrag, abgebildet auf NIST CSF 2.0 und ISO/IEC 27001:2022.
Die Sicherheitsinvarianten (keine Selbstsignierung, bei Ausfall gesperrter Tresor, Verifikation vor Übernahme) werden im Datenmodell und in der Zustandsmaschine durchgesetzt — nicht in einer empfehlenden Richtlinie. Sie können weder von einem Template-Autor deaktiviert noch durch eine Ausnahmegenehmigung erfüllt werden.
🔒
Bei Ausfall gesperrt als Standard
Kein Master Key → der Tresor verweigert den Betrieb; kein verifizierter Zustand → keine Übernahme. Das Fehlen eines Nachweises wird niemals als „erlaubt" aufgelöst.
🕵️
Kompromittierung annehmen, stets verifizieren
Ausgerichtet an den Zero-Trust-Grundsätzen von NIST SP 800-207: niemals vertrauen, stets verifizieren; geringste Privilegien; Kompromittierung annehmen. Jede Aktion ist einer einzigen Identität zurechenbar.
Defense-in-Depth für die autonome Flotte
Die zentrale Sorge bei einer autonomen Flotte ist nicht, dass ein Agent Arbeit verrichtet — sondern dass ein nicht-menschlicher Akteur die Autoritätskette übernehmen oder eine kompromittierte Station als Sprungbrett nutzen könnte. Vosj schichtet Kontrollen so, dass kein einzelnes Versagen katastrophal ist:
IDENTITY & LEAST PRIVILEGE Nur engagement-spezifische, eingegrenzte, widerrufliche Berechtigungen; Just-enough/Just-in-time; Zugang wird bei Jump entzogen. Jede Station trägt eine SPIFFE/SPIRE-artige oder Federated-OIDC-Workload-Identität.
NETWORK & EGRESS Ausgehenden Datenverkehr standardmäßig verweigern pro Station-Namespace (Positivliste: Ziel · Modell · SCM · DNS) — das Glied, das das „letale Trias" bricht. Private Verbindung zu den Datenbereichen des Kunden; Mikrosegmentierung zwischen Flottenrollen.
RUNTIME ISOLATION Gehärtete RuntimeClass (gVisor / Kata / Firecracker) für Code-ausführende Stationen; eine Station = eine Identität = ein Klon.
SECRETS & KEY CUSTODY Bei Ausfall gesperrter Tresor; Master Key in einem KMS/HSM mit geteilter Verwahrung; der HMAC-Ledger-Schlüssel wird außerhalb der Datenbank verwahrt, sodass eine DB-Kompromittierung keine Gate-Zeilen fälschen kann.
APPLICATION & DATA Fähigkeitsbasiertes RBAC (requireAuth/requireCapability auf jeder Route/Mutation); mandantenspezifische Abfrageisolierung; Verschlüsselung bei der Übertragung und im Ruhezustand; DPA / SCCs für grenzüberschreitende Übertragungen.
DETECT · RESPOND · RECOVER Unveränderliches Tool-Call-Protokoll; verhaltensbasiertes Monitoring der Tool-Call-Sequenzen gegen das genehmigte Runbook; stationsindividueller Notausschalter + Queue-Einfrierung; Verifikation vor Übernahme mit unabhängig geprobetem Rollback.
Vertrauensgrenzen
Die Flotte läuft in einem eigenen Namespace ohne dauerhaften Zugang zur Kundenumgebung. Der Zugang wird vermittelt, eingegrenzt und zeitlich begrenzt; die Datenübertragung erfolgt auf dem Quellhost über einen genehmigten Transport, nicht über eine lokale Gateway-Kopie.
Kein dauerhaftes Vertrauen: Die Flotte erreicht die Kundenumgebung und externe Dienste ausschließlich über eingegrenzte Berechtigungen und eine explizite Egress-Positivliste.
Identität & Credential-Vermittlung
Stationen halten niemals langlebige gemeinsame Schlüssel. Der MCP Hub prägt kurzlebige, audienzgebundene Downstream-Tokens pro Aufgabe; Client-Tokens werden niemals weitergeleitet (Prävention des Confused-Deputy-Problems, RFC 8707-Audienzvalidierung). Übernahme, Außerbetriebnahme und Schlüsselrotation erfordern die Genehmigung des Eigentümers/Administrators.
Der Vermittler, nicht die Station, entscheidet, was ein Downstream-Aufruf tun darf — und wie lange.
Die KI- / MCP- / LLM-Bedrohungsfläche
Autonomie fügt Angriffsklassen hinzu, mit denen ein klassisches Migrationswerkzeug nicht konfrontiert ist. Vosjs Bedrohungsmodell deckt diese explizit ab, verankert am OWASP LLM Top 10 (2025), der Agentic Security Initiative / MAESTRO und MITRE ATLAS:
Prompt- & Tool-Vergiftung
Quellinhalte und Tool-Antworten werden als nicht vertrauenswürdig behandelt; externe MCP-Server sind angeheftet und auf der Positivliste; Tool-Metadaten werden vor der Modellexposition statisch validiert; Abweichungen bei Deskriptoren lösen Warnmeldungen aus. (OWASP LLM01/LLM03/LLM05.)
Übermäßige Handlungsvollmacht
Agenten werden ohne jegliche sign-as-Fähigkeit erstellt; irreversible Schritte werden an einen Menschen eskaliert; Tool-Call-Sequenzen werden gegen das genehmigte Runbook überwacht. (OWASP LLM06.)
Das „letale Trias"
Private Daten + nicht vertrauenswürdiger Inhalt + Exfiltrationskanal. Der standardmäßig verweigerte ausgehende Datenverkehr entfernt den Kanal; das Trias kann sich nicht vervollständigen, selbst wenn eine Station eine feindliche Anweisung aufnimmt.
Confused Deputy
Der Hub validiert die Token-Audienz und leitet niemals ein Client-Token weiter, sodass eine Station den Vermittler nicht dazu bringen kann, mit der Autorität einer anderen Person zu handeln.
Die Tabelle ordnet die strukturellen Kontrollen von Vosj den sechs Funktionen des NIST Cybersecurity Framework 2.0 und den relevanten Anhang-A-Themen von ISO/IEC 27001:2022 zu — das Artefakt für einen Anbieter-Sicherheitsfragebogen oder ein GRC-Tool.
CSF 2.0
Vosj-Kontrollnachweise
ISO/IEC 27001:2022 Anhang A
GOVERN
Sicherheitsinvarianten im Motor durchgesetzt; Change-Management + CD-Abschluss je Aufgabe; dokumentierte Autonomiehaltung (Menschen halten die Tore); DPA / Unterverarbeiter-Offenlegung + rechtliche Freigabe vor dem Launch; engagement-spezifisches Risikoregister.
A.5.1, A.5.2, A.5.8, A.5.19–A.5.23, A.5.31
IDENTIFY
Anwendungszentriertes Inventar + Abhängigkeits-DAG; 365°-Liefersystem-Fingerabdruck für CI/CD; 7-R-Disposition + Risiko/Aufwand/TCO je Workload; externes MCP-Server-Inventar mit signierter Positivliste; Lieferkettenprovenienz.
A.5.9, A.5.21, A.5.7, A.8.8
PROTECT
Fähigkeitsbasiertes RBAC auf jeder Route/Mutation; keine Selbstsignierung; bei Ausfall gesperrter Tresor; Secret-Vermittlung + kurzlebige audienzgebundene Tokens; gehärtete RuntimeClass + Node-Pool-Isolierung; standardmäßig verweigerte ausgehende Verbindungen; Verschlüsselung bei Übertragung & im Ruhezustand; DLP/Inhaltstrennung.
Unveränderliches Tool-Call-Protokoll; verhaltensbasiertes Monitoring der Tool-Call-Sequenzen gegen das Runbook; Basislinien-Abweichungswächter; Deskriptor-Drift-Warnungen; kontinuierliches Notfallmonitoring während der Übernahme.
A.8.15, A.8.16, A.8.6, A.8.7, A.5.25
RESPOND
Dreifache Notfallumkehrung während der Übernahme; widerrufliches Annahmefenster; Fleet-Keepalive + geordnetes Entleeren; Incident-Runbook mit Credential-Widerruf + Stations-Quarantäne; stationsindividueller Notausschalter + Queue-Einfrierung.
A.5.24, A.5.26, A.5.27, A.5.5
RECOVER
Verifikation vor Übernahme + unabhängig geprober Rollback; PostgreSQL-Quorum-Synchron-Replikation, WAL/PITR, angegebene Ledger-RPO/RTO; Quelle bleibt in Betrieb bis Äquivalenz hergestellt ist; das Post-Mortem speist das Template.
Das Deployment ist an eine ausführbare Checkliste gebunden. Jeder Punkt ist binär (PASS / FAIL / N/A) mit Nachweis und einem benannten Unterzeichner; ein FAIL bei einem bei Ausfall gesperrten Punkt blockiert das Gate. Das POC-Gate qualifiziert einen eingegrenzten, zeitlich begrenzten Piloten (keine irreversible Aktion auf Produktionsdaten); das Produktions-Gate erfordert zusätzlich den vollständigen Kontrollsatz vor jeglichen Live-Daten oder einer Übernahme. Eine repräsentative Auswahl:
Die vollständigen Checklisten mit 12 Punkten (POC) und 15 Punkten (Produktion), mit Nachweisen und Rahmenwerkreferenzen, befinden sich im technischen Whitepaper (Anhang H).
Restrisiko & Akzeptanz
Kein System ist risikofrei. Vosj macht das Restrisiko explizit: Ein Register wird vor der ersten Produktionswelle von der zuständigen Stelle des Kunden geprüft und formal akzeptiert, mit Nachweis der Rahmenwerksabdeckung (CSF / ISO / SOC 2). Das Risiko ist gesteuert, zeitlich begrenzt und sichtbar — niemals still.
Arquitectura de seguridad y cumplimiento normativo
Despliegue de confianza cero, un almacén con cierre de seguridad por defecto y defensa en profundidad diseñada para una flota autónoma.
Un equipo de seguridad del cliente no adquiere controles — adquiere cobertura frente a un marco que ya utiliza en sus informes. Vosj está construido de modo que los controles críticos para la seguridad residan en el motor y no en una política que un autor de plantillas pueda desactivar; de modo que el comportamiento predeterminado sea el cierre de seguridad; y de modo que la flota autónoma opere dentro de límites de confianza que los auditores del cliente ya reconocen. Esta página es el contrato de seguridad, mapeado sobre NIST CSF 2.0 e ISO/IEC 27001:2022.
Los invariantes de seguridad (no auto-firma, almacén con cierre de seguridad, verificación previa a la transición) se aplican en el modelo de datos y en la máquina de estados — no en una política consultiva. No pueden ser desactivados por un autor de plantillas ni satisfechos mediante una exención.
🔒
Cierre de seguridad por defecto
Sin clave maestra → el almacén se niega a operar; sin estado verificado → sin transición. La ausencia de prueba nunca se resuelve como «permitir».
🕵️
Asumir brecha, verificar siempre
Diseñado conforme a los principios de confianza cero de NIST SP 800-207: nunca confiar, verificar siempre; mínimo privilegio; asumir brecha. Cada acción es atribuible a una única identidad.
Defensa en profundidad para la flota autónoma
La preocupación principal con una flota autónoma no es que un agente realice trabajo — es que un actor no humano pueda capturar la cadena de autoridad, o que una estación comprometida pueda pivotar. Vosj superpone controles de modo que ningún fallo aislado sea catastrófico:
IDENTITY & LEAST PRIVILEGE Únicamente concesiones por encargo, con alcance definido y revocables; mínimo necesario/en el momento justo; acceso retirado en Jump. Cada estación lleva una identidad de carga de trabajo de estilo SPIFFE/SPIRE o OIDC federado.
NETWORK & EGRESS Denegación de salida por defecto por espacio de nombres de estación (lista de autorización: destino · modelo · SCM · DNS) — el eslabón que rompe la «tríada letal». Conectividad privada hacia los planos de datos del cliente; microsegmentación entre roles de la flota.
RUNTIME ISOLATION RuntimeClass reforzada (gVisor / Kata / Firecracker) para estaciones que ejecutan código; una estación = una identidad = un clon.
SECRETS & KEY CUSTODY Almacén con cierre de seguridad; clave maestra en un KMS/HSM con custodia de conocimiento dividido; la clave del libro de registro HMAC custodiada fuera de la base de datos para que un compromiso de la BD no pueda falsificar filas de la puerta.
APPLICATION & DATA RBAC basado en capacidades (requireAuth/requireCapability en cada ruta/mutación); aislamiento de consultas por inquilino; cifrado en tránsito y en reposo; DPA / SCCs para cualquier transferencia transfronteriza.
DETECT · RESPOND · RECOVER Registro inmutable de llamadas a herramientas; análisis de comportamiento frente al manual de operaciones aprobado; interruptor de emergencia por estación + congelación de cola; verificación previa a la transición con retroceso independiente y ensayado.
Límites de confianza
La flota opera en su propio espacio de nombres sin ninguna ruta permanente hacia el entorno del cliente. El acceso se gestiona, delimita y acota en el tiempo; la transferencia de datos se ejecuta en el host de origen a través de un transporte autorizado, no mediante una copia local en la pasarela.
Sin confianza permanente: la flota accede al entorno del cliente y a los servicios externos únicamente mediante concesiones con alcance definido y una lista de autorización de salida explícita.
Identidad y gestión de credenciales
Las estaciones nunca almacenan claves compartidas de larga duración. El MCP Hub emite tokens de corta duración y alcance de audiencia por tarea para los recursos descendentes; los tokens del cliente nunca se transmiten directamente (prevención del problema del delegado confundido, validación de audiencia RFC 8707). La transición, la baja y la rotación de credenciales requieren la aprobación del propietario o del administrador.
El intermediario, no la estación, decide qué puede hacer una llamada descendente — y durante cuánto tiempo.
La superficie de amenaza de IA / MCP / LLM
La autonomía introduce clases de ataque ante las que una herramienta de migración clásica no se enfrenta. El modelo de amenazas de Vosj las cubre explícitamente, anclado en el OWASP LLM Top 10 (2025), la Agentic Security Initiative / MAESTRO y MITRE ATLAS:
Envenenamiento de instrucciones y herramientas
El contenido fuente y las respuestas de las herramientas se tratan como no fiables; los servidores MCP externos están fijados y en lista de autorización; los metadatos de las herramientas se validan estáticamente antes de exponerlos al modelo; la deriva de descriptores genera alertas. (OWASP LLM01/LLM03/LLM05.)
Agencia excesiva
Los agentes se crean sin ninguna capacidad sign-as; los pasos irreversibles se escalan a un humano; las secuencias de llamadas a herramientas se monitorizan frente al manual de operaciones aprobado. (OWASP LLM06.)
La «tríada letal»
Datos privados + contenido no fiable + canal de exfiltración. La denegación de salida por defecto elimina el canal; la tríada no puede completarse aunque una estación ingiera una instrucción hostil.
Delegado confundido
El Hub valida la audiencia del token y nunca transmite un token del cliente aguas abajo, por lo que una estación no puede engañar al intermediario para que actúe con la autoridad de otro.
Mapeo del marco de controles — NIST CSF 2.0 e ISO/IEC 27001:2022
La tabla mapea los controles estructurales de Vosj sobre las seis funciones del NIST Cybersecurity Framework 2.0 y sobre los temas relevantes del Anexo A de ISO/IEC 27001:2022 — el artefacto que se puede incorporar a un cuestionario de seguridad de proveedores o a una herramienta GRC.
CSF 2.0
Evidencia de controles de Vosj
ISO/IEC 27001:2022 Anexo A
GOVERN
Invariantes de seguridad aplicados en el motor; gestión de cambios + cierre CD por tarea; postura de autonomía documentada (los humanos controlan las puertas); DPA / divulgación de sub-encargados + aprobación legal antes del lanzamiento; registro de riesgos por encargo.
A.5.1, A.5.2, A.5.8, A.5.19–A.5.23, A.5.31
IDENTIFY
Inventario centrado en la aplicación + DAG de dependencias; huella 365° del sistema de entrega CI/CD; disposición 7-R + riesgo/esfuerzo/TCO por carga de trabajo; inventario de servidores MCP externos con lista de autorización firmada; procedencia de la cadena de suministro.
A.5.9, A.5.21, A.5.7, A.8.8
PROTECT
RBAC basado en capacidades en cada ruta/mutación; no auto-firma; almacén con cierre de seguridad; intermediación de secretos + tokens de corta duración con alcance de audiencia; RuntimeClass reforzada + aislamiento de grupo de nodos; denegación de salida por defecto; cifrado en tránsito y en reposo; DLP/separación de contenido.
Registro inmutable de llamadas a herramientas; monitorización del comportamiento de las secuencias de llamadas a herramientas frente al manual de operaciones; guardia de deriva de línea base; alertas de deriva de descriptores; monitorización continua de contingencia durante la transición.
A.8.15, A.8.16, A.8.6, A.8.7, A.5.25
RESPOND
Reversión de contingencia en tres vías durante la transición; ventana de aceptación revocable; mantenimiento de la flota + drenaje controlado; manual de gestión de incidentes con revocación de credenciales + cuarentena de estación; interruptor de emergencia por estación + congelación de cola.
A.5.24, A.5.26, A.5.27, A.5.5
RECOVER
Verificación previa a la transición + retroceso independiente y ensayado; replicación PostgreSQL con quórum sincronizado, WAL/PITR, RPO/RTO declarados para el libro de registro; la fuente permanece activa hasta que se establece la equivalencia; el análisis post-mortem alimenta la plantilla.
A.5.29, A.5.30, A.8.13, A.8.14
Para SOC 2, las mismas evidencias sustentan los Criterios de Servicios de Confianza: libro de registro + RBAC → Seguridad; HA/DR + mantenimiento → Disponibilidad; reconciliación multicategoría → Integridad del procesamiento; almacén con cierre de seguridad + mínimo privilegio → Confidencialidad; DPA / postura transfronteriza + tratamiento de PII → Privacidad (e ISO/IEC 27018 para PII en la nube).
Aprobación de seguridad — puertas de POC y Producción
El despliegue está condicionado por una lista de verificación ejecutable. Cada elemento es binario (PASS / FAIL / N/A) con evidencia y un firmante designado; un FAIL en un elemento con cierre de seguridad bloquea la puerta. La puerta de POC cualifica un piloto acotado y limitado en el tiempo (sin acción irreversible sobre datos de producción); la puerta de Producción exige adicionalmente el conjunto completo de controles antes de que haya datos reales o una transición. Una selección representativa:
Puerta de POC (extracto)
Alcance acordado por escrito; únicamente datos no productivos o enmascarados.
Acceso delegado, con alcance definido, limitado en el tiempo, revocable — sin claves compartidas.
Almacén con cierre de seguridad confirmado mediante prueba negativa.
Denegación de salida por defecto; lista de autorización = destino / modelo / SCM / DNS.
RuntimeClass reforzada para estaciones que ejecutan código.
No auto-firma verificada (intento de auto-firma fallido registrado).
Protección contra inyección de instrucciones activa; servidores MCP fijados + en lista de autorización.
Simulacro de interruptor de emergencia + congelación de cola; proceso de desmantelamiento definido.
Puerta de Producción (extracto)
Todos los elementos de POC reverificados como PASS en el inquilino de producción.
DPA + SCCs + aprobación legal; residencia de datos fijada.
Clave del libro de registro HMAC en KMS/HSM externo; rotación documentada.
Verificación previa a la transición presente y no eliminable en cada plantilla.
Telemetría → SIEM del cliente; detecciones mapeadas sobre MITRE ATT&CK + ATLAS.
Controles de delegado confundido (audiencia RFC 8707; sin transmisión de token).
Prueba de penetración independiente incluido equipo rojo de IA; riesgo residual aceptado.
Las listas de verificación completas de 12 elementos (POC) y 15 elementos (Producción), con evidencias y referencias al marco, se encuentran en el libro blanco técnico (Apéndice H).
Riesgo residual y aceptación
Ningún sistema está libre de riesgos. Vosj hace explícito el riesgo residual: un registro es revisado y formalmente aceptado por la autoridad del cliente antes de la primera ola de producción, con cobertura del marco attestada (CSF / ISO / SOC 2). El riesgo se gobierna, se acota en el tiempo y es visible — nunca silencioso.
Implementação de confiança zero, um cofre com bloqueio de segurança por defeito e defesa em profundidade concebida para uma frota autónoma.
Uma equipa de segurança do cliente não adquire controlos — adquire cobertura face a um referencial que já utiliza nos seus relatórios. O Vosj é construído de modo a que os controlos críticos para a segurança residam no motor e não numa política que um autor de modelos possa desativar; de modo a que o comportamento por defeito seja o bloqueio de segurança; e de modo a que a frota autónoma opere dentro de limites de confiança que os auditores do cliente já reconhecem. Esta página é o contrato de segurança, mapeado sobre NIST CSF 2.0 e ISO/IEC 27001:2022.
Os invariantes de segurança (sem auto-assinatura, cofre com bloqueio de segurança, verificação prévia à transição) são aplicados no modelo de dados e na máquina de estados — não numa política consultiva. Não podem ser desativados por um autor de modelos nem satisfeitos por meio de uma isenção.
🔒
Bloqueio de segurança por defeito
Sem chave mestra → o cofre recusa-se a operar; sem estado verificado → sem transição. A ausência de prova nunca se resolve como «permitir».
🕵️
Assumir comprometimento, verificar sempre
Concebido segundo os princípios de confiança zero do NIST SP 800-207: nunca confiar, verificar sempre; mínimo privilégio; assumir comprometimento. Cada ação é atribuível a uma única identidade.
Defesa em profundidade para a frota autónoma
A principal preocupação com uma frota autónoma não é que um agente realize trabalho — é que um ator não humano possa capturar a cadeia de autoridade, ou que uma estação comprometida possa efetuar um pivô. O Vosj superpõe controlos de modo a que nenhuma falha isolada seja catastrófica:
IDENTITY & LEAST PRIVILEGE Apenas concessões por envolvimento, com âmbito definido e revogáveis; estritamente necessário/no momento certo; acesso retirado em Jump. Cada estação possui uma identidade de carga de trabalho no estilo SPIFFE/SPIRE ou OIDC federado.
NETWORK & EGRESS Negação de saída por defeito por espaço de nomes de estação (lista de autorização: destino · modelo · SCM · DNS) — o elo que quebra a «tríade letal». Conectividade privada para os planos de dados do cliente; microssegmentação entre papéis da frota.
RUNTIME ISOLATION RuntimeClass reforçada (gVisor / Kata / Firecracker) para estações que executam código; uma estação = uma identidade = um clone.
SECRETS & KEY CUSTODY Cofre com bloqueio de segurança; chave mestra num KMS/HSM com custódia de conhecimento dividido; a chave do registo HMAC custodiada fora da base de dados para que um comprometimento da BD não possa falsificar linhas da porta.
APPLICATION & DATA RBAC baseado em capacidades (requireAuth/requireCapability em cada rota/mutação); isolamento de consultas por inquilino; encriptação em trânsito e em repouso; DPA / SCCs para qualquer transferência transfronteiriça.
DETECT · RESPOND · RECOVER Registo imutável de chamadas a ferramentas; análise comportamental face ao manual de operações aprovado; interruptor de emergência por estação + congelamento de fila; verificação prévia à transição com reversão independente e ensaiada.
Limites de confiança
A frota opera no seu próprio espaço de nomes sem nenhum caminho permanente para o ambiente do cliente. O acesso é intermediado, delimitado e limitado no tempo; a transferência de dados é executada no anfitrião de origem através de um transporte autorizado, e não através de uma cópia local na gateway.
Sem confiança permanente: a frota acede ao ambiente do cliente e aos serviços externos apenas através de concessões com âmbito definido e de uma lista de autorização de saída explícita.
Identidade e intermediação de credenciais
As estações nunca armazenam chaves partilhadas de longa duração. O MCP Hub emite tokens de curta duração e âmbito de audiência por tarefa para os recursos a jusante; os tokens do cliente nunca são transmitidos diretamente (prevenção do problema do delegado confundido, validação de audiência RFC 8707). A transição, a desativação e a rotação de credenciais requerem a aprovação do proprietário ou do administrador.
O intermediário, e não a estação, decide o que uma chamada a jusante pode fazer — e durante quanto tempo.
A superfície de ameaça de IA / MCP / LLM
A autonomia introduz classes de ataque com que uma ferramenta de migração clássica não se depara. O modelo de ameaças do Vosj cobre-as explicitamente, ancorado no OWASP LLM Top 10 (2025), na Agentic Security Initiative / MAESTRO e no MITRE ATLAS:
Envenenamento de instruções e ferramentas
O conteúdo de origem e as respostas das ferramentas são tratados como não fidedignos; os servidores MCP externos estão fixados e em lista de autorização; os metadados das ferramentas são validados estaticamente antes da exposição ao modelo; a deriva de descritores gera alertas. (OWASP LLM01/LLM03/LLM05.)
Agência excessiva
Os agentes são criados sem qualquer capacidade sign-as; os passos irreversíveis são escalados para um humano; as sequências de chamadas a ferramentas são monitorizadas face ao manual de operações aprovado. (OWASP LLM06.)
A «tríade letal»
Dados privados + conteúdo não fidedigno + canal de exfiltração. A negação de saída por defeito elimina o canal; a tríade não pode completar-se mesmo que uma estação ingira uma instrução hostil.
Delegado confundido
O Hub valida a audiência do token e nunca transmite um token do cliente a jusante, pelo que uma estação não pode enganar o intermediário para que este aja com a autoridade de outrem.
Mapeamento do referencial de controlos — NIST CSF 2.0 e ISO/IEC 27001:2022
A tabela mapeia os controlos estruturais do Vosj sobre as seis funções do NIST Cybersecurity Framework 2.0 e sobre os temas relevantes do Anexo A da ISO/IEC 27001:2022 — o artefacto a inserir num questionário de segurança de fornecedores ou numa ferramenta GRC.
CSF 2.0
Evidência de controlos do Vosj
ISO/IEC 27001:2022 Anexo A
GOVERN
Invariantes de segurança aplicados no motor; gestão de alterações + encerramento de CD por tarefa; postura de autonomia documentada (os humanos controlam as portas); DPA / divulgação de sub-responsáveis + aprovação jurídica antes do lançamento; registo de riscos por envolvimento.
A.5.1, A.5.2, A.5.8, A.5.19–A.5.23, A.5.31
IDENTIFY
Inventário centrado na aplicação + DAG de dependências; impressão digital 365° do sistema de entrega CI/CD; disposição 7-R + risco/esforço/TCO por carga de trabalho; inventário de servidores MCP externos com lista de autorização assinada; proveniência da cadeia de fornecimento.
A.5.9, A.5.21, A.5.7, A.8.8
PROTECT
RBAC baseado em capacidades em cada rota/mutação; sem auto-assinatura; cofre com bloqueio de segurança; intermediação de segredos + tokens de curta duração com âmbito de audiência; RuntimeClass reforçada + isolamento de conjunto de nós; negação de saída por defeito; encriptação em trânsito e em repouso; DLP/separação de conteúdo.
Registo imutável de chamadas a ferramentas; monitorização comportamental das sequências de chamadas a ferramentas face ao manual de operações; guarda de deriva de linha de base; alertas de deriva de descritores; monitorização contínua de contingência durante a transição.
A.8.15, A.8.16, A.8.6, A.8.7, A.5.25
RESPOND
Reversão de contingência em três vias durante a transição; janela de aceitação revogável; manutenção da frota + drenagem controlada; manual de gestão de incidentes com revogação de credenciais + quarentena de estação; interruptor de emergência por estação + congelamento de fila.
A.5.24, A.5.26, A.5.27, A.5.5
RECOVER
Verificação prévia à transição + reversão independente e ensaiada; replicação PostgreSQL com quórum síncrono, WAL/PITR, RPO/RTO declarados para o registo; a origem permanece ativa até que a equivalência seja estabelecida; o pós-mortem alimenta o modelo.
A.5.29, A.5.30, A.8.13, A.8.14
Para SOC 2, as mesmas evidências suportam os Critérios de Serviços de Confiança: registo + RBAC → Segurança; HA/DR + manutenção → Disponibilidade; reconciliação multicategoria → Integridade do processamento; cofre com bloqueio de segurança + mínimo privilégio → Confidencialidade; DPA / postura transfronteiriça + tratamento de PII → Privacidade (e ISO/IEC 27018 para PII na nuvem).
Aprovação de segurança — portas de POC e Produção
A implementação está condicionada por uma lista de verificação executável. Cada elemento é binário (PASS / FAIL / N/A) com evidência e um signatário designado; um FAIL num elemento com bloqueio de segurança bloqueia a porta. A porta de POC qualifica um piloto delimitado e limitado no tempo (sem ação irreversível sobre dados de produção); a porta de Produção exige adicionalmente o conjunto completo de controlos antes de quaisquer dados reais ou transição. Uma seleção representativa:
Porta de POC (excerto)
Âmbito acordado por escrito; apenas dados não produtivos ou mascarados.
Acesso delegado, com âmbito definido, limitado no tempo, revogável — sem chaves partilhadas.
Cofre com bloqueio de segurança confirmado por teste negativo.
Negação de saída por defeito; lista de autorização = destino / modelo / SCM / DNS.
RuntimeClass reforçada para estações que executam código.
Sem auto-assinatura verificada (tentativa de auto-assinatura falhada registada).
Proteção contra injeção de instruções ativa; servidores MCP fixados + em lista de autorização.
Simulacro de interruptor de emergência + congelamento de fila; processo de desmantelamento definido.
Porta de Produção (excerto)
Todos os elementos de POC reverificados como PASS no inquilino de produção.
DPA + SCCs + aprovação jurídica; residência de dados fixada.
Chave do registo HMAC em KMS/HSM externo; rotação documentada.
PostgreSQL HA/DR demonstrado; restauro testado.
Verificação prévia à transição presente e não removível em cada modelo.
Telemetria → SIEM do cliente; deteções mapeadas sobre MITRE ATT&CK + ATLAS.
Controlos de delegado confundido (audiência RFC 8707; sem transmissão de token).
Teste de intrusão independente incluindo equipa vermelha de IA; risco residual aceite.
As listas de verificação completas de 12 elementos (POC) e 15 elementos (Produção), com evidências e referências ao referencial, encontram-se no livro branco técnico (Apêndice H).
Risco residual e aceitação
Nenhum sistema está isento de riscos. O Vosj torna o risco residual explícito: um registo é revisto e formalmente aceite pela autoridade do cliente antes da primeira vaga de produção, com cobertura do referencial atestada (CSF / ISO / SOC 2). O risco é governado, limitado no tempo e visível — nunca silencioso.