Comenzar

Bastion ejecuta autorización, clasificación, auditoría, cumplimiento y fronteras de confianza como controles vivos del sistema.

Tesis

La confianza no puede vivir solo en documentos.

Cada capacidad seria debe poder nombrar su dueño, contrato, política, punto de ejecución, evidencia, verificación y frontera de confianza. Sin ese camino, la gobernanza no llega al runtime.

Flujo de confianzaPolicy/evidence gate
  1. 01Identidad
  2. 02Policy context
  3. 03Marcado
  4. 04Acceso
  5. 05Audit event

Bastion define quién puede ver, decidir, actuar, compartir y auditar bajo reglas verificables.

Frontier

Ownership y fronteras

Cada plataforma base posee una responsabilidad distinta; ninguna absorbe al resto del OS ni a los Operational Decision Systems.

Qué posee

  • identidad, acceso, política, compliance, auditoría, markings y fronteras de confianza
  • privacy, crypto/secrets, aislamiento, egress, supply chain y hardened runtime posture como diseño de trust
  • rutas de evidencia para policy decisions, excepciones y posture reviews

Qué no posee

  • modelo semántico de objetos y relaciones
  • workflows, action fabric o UX vertical
  • comportamiento de modelos y agentes
  • release/deployment control o lógica legal de misión

Depende de

  • Orbis para semántica, provenance y objeto afectado
  • Concord para workflows, acciones y handoffs
  • Axiom para boundaries de herramientas y agentes
  • Meridian para release/deployment evidence y supply chain

Policy fabric

La política debe llegar al punto donde una acción se decide.

Diseño/contrato

Bastion lleva identidad, autorización, clasificación y cumplimiento al contexto de consulta, workflow, herramienta, exportación o acción. Su frontera de confianza se presenta con evidencia y status explícito, sin convertir diseño en garantía de enforcement transversal completo.

  • Request, policy context, permit/deny/escalate y evidence event.
  • Separación entre ver, decidir, actuar, compartir, exportar y auditar.
  • Interlock con Orbis, Concord, Axiom, Meridian y Operational Decision Systems.
  • Owner y evidencia antes de elevar claims de enforcement.

Markings y fronteras

La sensibilidad acompaña objetos, vistas, herramientas y evidencia.

En validación

Bastion define cómo marcas, restricciones y límites de confianza deben viajar desde fuentes hacia objetos, workflows, herramientas de IA, exportaciones y evidencia. Secure sharing se presenta como diseño controlado hasta tener pruebas y autoridad pública.

  • Marcas de origen, sensibilidad, propósito, expiración y necesidad de conocer.
  • Restricciones sobre derivados, prompts, reportes, exportaciones y evidencia.
  • Fronteras por tenant, organización, jurisdicción, ambiente, misión y caso.
  • Minimización, retención y reviewer para intercambio controlado.

Audit evidence

La auditoría debe explicar la decisión, no acumular ruido.

Evidencia runtime requerida

Bastion organiza evidencia de actor, rol, objeto, acción, política, decisión, razón, runtime version, source refs, retención y reviewer. Los claims de retención, colaboración o compliance requieren evidencia y status explícito.

  • Actor, rol, objeto, acción y decisión de policy correlacionados.
  • Runtime version, source refs, reason, retention y reviewer.
  • Excepción, revisión y cadencia declaradas por control.
  • Interlock con Meridian para release gate y evidence bundle.

Consumo por Operational Decision Systems

Bastion sirve fronteras de confianza para EDELON OS y sus Operational Decision Systems.

Executive, Judex, Lex, Fiscalis, Urbis y Praetor dependen de Bastion para identidad, policy, markings y auditoría sin transferirle la lógica legal o misional de cada sistema.

Capacidades

Bloques funcionales de la frontera de confianza.

01

Authorization fabric

Permisos por rol, atributo, tenant, clasificación, misión, contexto y acción.

02

Classification markings

Marcas de sensibilidad, origen, restricción, propósito, expiración y uso permitido.

03

Trust boundaries

Separación por organización, ambiente, jurisdicción, misión, caso, dato y propósito.

04

Audit and compliance evidence

Controles, owners, evidencias, excepciones, revisión y postura por capacidad.

Proof/status

Proof/status ledger

La ambición pública se separa de arquitectura aceptada, diseño, validación, evidencia runtime requerida y claims no publicables.

Claim o bloqueBastion como base platform de confianza
Status públicoArquitectura aceptada
Frase permitida

Bastion está diseñado para llevar identidad, política, clasificación, auditoría y fronteras de confianza al runtime.

Evidencia requerida

Arquitectura aceptada, alcance de seguridad documentado y evidencia pública para afirmaciones de seguridad.

Claim o bloquePolicy fabric y enforcement points
Status públicoDiseño/contrato
Frase permitida

Bastion define rutas para evaluar policy context, decisión y evidencia.

Evidencia requerida

Policy tests, runtime events, owner, versions y auditoría de decisión.

Claim o bloqueMarkings y secure sharing
Status públicoEn validación
Frase permitida

Markings y secure sharing se presentan como diseño controlado con evidencia requerida.

Evidencia requerida

Marking rules, propagation tests, minimization review, sharing logs y owner legal.

Claim o bloqueCompliance posture y audit retention
Status públicoEvidencia runtime requerida
Frase permitida

Los claims de compliance posture necesitan controles, owners, evidencia, excepción y cadencia.

Evidencia requerida

Control mapping, owner, evidence event, exception flow, review cadence y release gate.

Briefing institucional

Alinear confianza, policy, auditoría y límites de claim.

Un briefing permite revisar identidad, markings, access paths, trust boundaries, audit evidence, compliance posture y evidencia necesaria antes de publicar claims de seguridad o cumplimiento.

Solicitar briefing institucionalVolver al inicio