·  /  What Kawésqar is

Six parts, one project.

Kawésqar is a systems-engineering laboratory in northern Patagonia that publishes its own operating system. The Agent Fabric is the architecture. Kawésqar Server is its first realization, the system the fabric runs on. Kawésqar Workstation inherits the Server and adds a desktop for the people who build and audit it. Research holds ideas we have not tested yet. The last two tabs say why we work from here and whose name we carry.

·  /  Why it exists

We watched agents escape. Nobody was watching them.

Before designing anything, we spent months following AI agent escapes case by case: an agent with a bounded task ends up touching credentials, repositories or services it should never have seen, sometimes far from where it started. A security practitioner acts the moment they can see the problem. Here there was nothing to see: the activity ran inside a sandbox that reported on itself, and the only records left were the ones the compromised system chose to write. Four findings came out of that analysis, each one about what was missing around the agent rather than inside it.

Each finding is now a decision in the Agent Fabric: a witness outside the cell, machines that carry only what the step needs, authority that expires and never amplifies, and a successor allowed to exist only against signed evidence. The full case shows how each one is tested, and where the tests still fall short.

·  /  Go deeper

Read the full case.

This page is the summary. The full case keeps every figure next to its file, its date and the plane where it ran, including the results that failed and the gaps still open.

·  /  Get in touch

Sponsors, collaborators, and the alpha.

·  /  Qué es Kawésqar

Seis partes, un proyecto.

Kawésqar es un laboratorio de ingeniería de sistemas en la Patagonia norte que publica su propio sistema operativo. El Agent Fabric es la arquitectura. Kawésqar Server es su primera realización, el sistema sobre el que corre el fabric. Kawésqar Workstation hereda del Server y suma un escritorio para quienes lo construyen y lo auditan. Investigación reúne ideas que aún no probamos. Las dos últimas pestañas cuentan por qué trabajamos desde aquí y qué nombre llevamos.

·  /  Por qué existe

Vimos escaparse a los agentes. Nadie los estaba mirando.

Antes de diseñar nada, seguimos durante meses, caso por caso, los escapes de agentes de IA: un agente con una tarea acotada termina tocando credenciales, repositorios o servicios que nunca debió ver, a veces muy lejos de donde empezó. Un profesional de seguridad reacciona en cuanto puede ver el problema. Aquí no había nada que ver: la actividad corría dentro de un sandbox que informaba sobre sí mismo, y los únicos registros eran los que el sistema comprometido decidió escribir. De ese análisis salieron cuatro constataciones, todas sobre lo que faltaba alrededor del agente y no dentro de él.

Cada constatación es hoy una decisión del Agent Fabric: un testigo fuera de la celda, máquinas que llevan solo lo que el paso necesita, autoridad que expira y nunca se amplifica, y un sucesor que solo puede existir contra evidencia firmada. El caso completo muestra cómo se prueba cada una y dónde las pruebas aún se quedan cortas.

·  /  Para profundizar

Lee el caso completo.

Esta portada es el resumen. El caso completo deja cada cifra junto a su archivo, su fecha y el plano donde corrió, incluidos los resultados que fallaron y las brechas que siguen abiertas.

·  /  Contacto

Patrocinadores, colaboradores y el alfa.

·  /  Agent Fabric · the full case

The architecture, the evidence, and what is still open.

The long version: the design, every result with its plane, the known gaps and what compute would close. About 20 minutes. Tags: tested · logic code run on a host, formal the TLA+ model, VM · nested · n=1 real Xen domains nested in KVM, tested · bare metal · n=1 the same experiments re-run on one physical Xen dom0, pending not run yet.

• 01 · The idea
• 02 · A different axis
• 03 · One invariant, four properties
• 04 · Four planes of evidence
• 05 · Adversarial evidence and lab log
• 06 · What is missing
• 07 · Why now
• 08 · The compute ask
• 09 · Transparency and IP

01  /  The idea · target design

01A minimal machine per step. The next only against evidence.

Picture today's AI agent as an astronaut inside a fully equipped spacecraft. Networking, storage and credentials are all on board, each one switched off or fenced in. A clever enough astronaut eventually finds a way around a fence, which is a large part of why agent “escapes” keep reaching the news.

We think restriction on its own is not enough: a door can be opened precisely because it exists. So the design builds each cell without the doors its step does not need.

Most AI-agent containment today starts from a full operating system wrapped in a sandbox that restricts it. It is a mature, valuable model, and it answers one question well: what can the guest touch? Ours is a different way to contain risk, though not a unique one. A Kawésqar cell is meant to be built from the kernel up, closer to a tailor-made execution cell than to a general-purpose OS restricted after the fact, and it asks two more questions:

• Can the guest grow its own power? Each job runs with an authority budget delegated up front. The design goal is that even a fully compromised job cannot mint authority it was never given. In logic, 31 adversarial vectors produced no amplification, and the real broker and Gate deny the three escalation attempts such a job would make (§05).
• Is the next machine even allowed to exist? A successor is created only when the Gate accepts evidence about the predecessor's run, countersigned by an observer outside the cell. No valid evidence, no next runner, whatever the guest says about itself.

When the job ends, the machine is gone. No permanent, all-powerful operating system sits in the middle for every job to trust.

A concrete example

Say a job needs to download a file. The first cell does one thing: reach the URL and confirm the download is there. Only once that produces evidence is a second cell created, a new machine whose kernel was built without networking: not disabled, absent. It holds the file and can write it, a capability the first cell never had.

02  /  A different axis: not a “better sandbox”

02Orthogonal, and composable with what you already run.

It would be a category error to pitch Kawésqar as beating containers, gVisor, Firecracker microVMs or Qubes. Those are excellent at containment: reducing what a persistent guest can reach. Kawésqar works on a second axis, authority and existence over time, on top of hardware isolation (a hypervisor, an IOMMU). That is a choice of axis, and it says nothing against theirs.

An autonomous agent is a stream of jobs that spawn follow-on jobs. The question is whether a compromised step 7 can quietly grant itself the authority to launch step 8 against your production data. Kawésqar is designed to prevent that. It is tested in logic, with disclosed gaps (§06).

A witness outside the cell

In a typical sandbox, the account of what happened comes from inside, and a compromised guest can shape or suppress it. In Kawésqar, an observer outside the cell attests facts of liveness and the I/O window as measured by the control domain. It attests liveness and the I/O window; a separate witness attests the commit itself over the real bytes on disk, so a compromised broker cannot forge a COMMITTED. The guest is never a trusted source of evidence about itself. Current limits: in the VM runs the observer used a symmetric key the verifier also holds, and it still depends on the event stream the control domain relays to it. On bare metal the verification moved out of the control domain: the observer, the Gate and the notary ran in a separate domain with asymmetric keys, and the control domain only relays bytes and launches, with no private key. The order that authorizes a successor is written by the verifier over its own channel, and an order fabricated by the control domain dies by signature tested · bare metal · n=1. The control domain still creates the domains, provisions the public keys and can inspect the memory of a live cell, so what left it is the verification, not the whole trust base.

03  /  What we are testing

03One invariant, four properties.

The claim, stated so it can be falsified: for every reachable state, even after total compromise of the guest, its effective authority stays inside what its parent delegated.

These are design properties: designed to prevent; tested in logic, with disclosed gaps. What is distinctive is a conjunction rather than any single property: the existence of a Xen domain governed by evidence of the predecessor's observed transitions, countersigned from outside the cell, under a ceiling that does not amplify. Every piece has prior art: TCU (arXiv 2504.15717), the closest, where a successor verifies proofs from its predecessor, then Hyperlaunch and DomB in Xen, seL4, KeyKOS and Nexus. The mechanism itself is held under NDA (§09).

04  /  Evidence · four planes

04Four planes of evidence.

A security claim is worth the evidence under it. We validate on four planes and keep each from borrowing another's credibility. This block holds all of it: planes and figures (§04), the adversarial sweep and lab log (§05), the gaps (§06).

The headline figures, each with its plane

05  /  Evidence · adversarial sweep and lab log

05What Xen stops, and what we stop.

We swept 31 attack vectors against the protocol in logic. Separately, Xen contained a raw hostile guest on a VM, while the adversary against the protocol itself ran in logic on the host. Separating what the hypervisor contains from what our logic contains keeps the result from being waved away as “Xen already does that.”

The lab log

Each row points to a dated results file. The VM labs run Xen 4.20 nested under KVM and say nothing about performance or hard isolation. The bare-metal rows run on one physical dom0 and cover the architecture, not yet the fine physics. Summary: tested in logic, modeled formally, Xen isolation shown on a VM, the core and an extension round re-run on bare metal, now under strict IOMMU with the cryptographic path running inside real cells, verification outside the control domain and a Gate that demands the signature itself; DMA confinement between domains is now measured on bare metal and the SMT side channel is measured and suppressed by placement (lab52).

The strongest results

The consolidated sign-off is prepared and not signed. Only the lab12 chain is backed by the internal reviews.

06  /  Evidence · what is missing today

06The gap list.

None of these are hidden assumptions. Each has a defined experiment (§08).

• The cryptographic path inside cells. It has since run end to end inside real cells on bare metal, bounded, and composes across depth and fan-out. Verification has also left the control domain (lab47) tested · bare metal · n=1, with asymmetric keys the control side does not hold, and the Gate itself now demands the in-cell signature (lab48) tested · bare metal · n=1. The lying broker is contained too: a separate witness attests the commit over the real bytes on disk, so a forged COMMITTED creates no successor tested · bare metal · n=1.
• Concurrent succession. Two Gate decisions before either commits can yield two successors from one piece of evidence. It needs an atomic check-and-activate. The reservation race was closed on metal, bounded: the ledger held Σ(children) ≤ the parent under 48 racing threads with no double reservation, while a persistent check-and-activate in the production control path stays a declared gap. The sequential case is closed.
• Evidence semantics and expiry. Both are now closed in the real Gate: evidence that is not deterministic external evidence is denied (NO_EXTERNAL_EVIDENCE), and expiry is fail-closed, so a missing or non-numeric monotonic time denies as EXPIRED instead of passing. The unit suites stay green (gate 42/42). tested · logic
• The control domain as trust base. Rewinding its state, deleting the journal, or feeding the observer a forged stream (F9). It still creates the domains and the lifecycle facts, provisions the public keys the verifier uses (a malicious control domain at boot could hand over a false one) and can inspect the memory of a live cell, so the in-cell signature does not protect against it without encrypted-memory hardware, declared as future. What lab47 closed is the verification leaving it, not these.
• Scale & physics. Scale, depth n>1, the Gate's adversarial arm under load, a reservation race, the resource fan-out cost and the observed cell boundary have run on a physical dom0, now under strict IOMMU, which denies an unmapped transfer even to host memory (§05). DMA confinement between domains with an assigned device has since been measured on bare metal (lab50). The SMT side channel is now measured too (lab52): a co-located sibling-thread cell steals ~5 to 6x throughput, and placement on a separate core brings it back to ~1.1x; the cross-core cache residual stays declared. Scaling cells across machines is the broker's job, not the hypervisor's: independent Xen dom0s, one per node, each its own local root of trust that signs its own receipts, with the Gate placing cells and no live-state migration. Proxmox and KVM were evaluated for this and set aside, since they would break the PVH cells, memory introspection and the boot artifacts and reset the metal evidence without delivering the scaling; this is a decision, not yet a test.

The architecture now operates under strict IOMMU on a physical dom0, with the cryptographic path running inside real cells, the verification outside the control domain and the Gate demanding the signature itself, all bounded. The sign-off is still pending; DMA confinement between domains is now measured on bare metal (lab50), and the main remaining ask is independent external review, with a persistent check-and-activate in production, mTLS (run on the physical control domain, with the split into separate principals and Xen domains still open) and n of at least 2 still open (the lab47+48 composition has since run on metal, 5/5, lab55); the SMT side channel is now measured and suppressed by placement (lab52).

07  /  Why this is attractive, and why now

07Agents made the job the unit of risk.

Autonomous AI agents turned every platform into a generator of untrusted, self-spawning work. We do not claim to be the best, or that existing containment is wrong. The claim is narrower: this approach could, if the tests hold, offer stronger protection for agentic work. It reduces the attack surface to what each step requires, and it stacks independent controls: a minimal cell, delegated authority, evidence-gated succession and a witness outside the cell. No single layer carries the whole burden.

We lean on mature, underused controls more than on anything exotic. Mutually authenticated channels (mTLS) on every link are an example: decades old, rarely the default, and in Kawésqar now built and tested, mutual in both directions, and run on the physical control domain; what has not is separate OS principals and separate Xen domains, the next tier. When a solid technology goes unused out of unfamiliarity rather than real difficulty, we adopt it.

What “it works better” would mean, measurably

08  /  The compute ask

08What we would prove with compute, and what we return.

Each item maps to one experiment, a machine budget, a falsification criterion and a deliverable. Most of them have since run on metal, bounded and n=1, so the request now concentrates in three concrete things: hardware with SEV-SNP or TDX to close memory secrecy from the control domain (lab54); a CPU with Intel CAT to partition the shared L3 and close the cross-core cache residual (lab53); and a second, distinct host to reach n of at least 2, plus the independent external review. The table below keeps each hypothesis with its cost and deliverable.

Bare metal is the one thing a VM cannot stand in for, and the cheapest high-signal spend: a single IOMMU-capable host turns the architecture result into a physics result.

09  /  Transparency, IP, and reproducibility

09Public results, held mechanism.

One policy: results and counts are public; vectors, formats and raw logs are under NDA.

Every figure comes from a script with a reproducible verdict. FAILs exit non-zero on purpose (lab14 and lab15 do), and TLC logs are not bit-reproducible, so formal results are checked by verdict. The internal reviews were adversarial and changed this page: they removed an “empirically and formally confirmed” overclaim and forced the plane tags.

Risks we are not hiding

• Dependency on Xen. The guarantee is “modulo a correct hypervisor.” A smaller, more diverse trust base remains research.
• Bare-metal results are bounded, n=1. What ran on metal ran on one machine, once, under strict IOMMU; strict mode denies an unmapped transfer even to host memory, and DMA confinement between domains with an assigned device is measured (lab50). Two physical limits stay declared, in plain sight, and are now measured: the control domain can still read the memory of a live cell, shown directly when it recovered a secret from a live cell's RAM (lab54), which needs encrypted-memory hardware (SEV-SNP or TDX, future); and a cache channel across different cores, now measured and small (~1.1x throughput interference, lab53), a residual placement cannot remove since every core shares the L3. The SMT side channel is measured and suppressed by placement: a co-located sibling-thread cell steals ~5 to 6x throughput, and a separate core brings it back to ~1.1x (lab52 on metal).
• Novelty is defensible, not shown unique. The final judgment belongs to external peer review, a funded deliverable.

The full architecture paper (v1.3) and the reproduction package are available under NDA: rodrigo@kawesqar.org.

·  /  Agent Fabric · el caso completo

La arquitectura, la evidencia y lo que sigue abierto.

La versión larga: el diseño, cada resultado con su plano, las brechas conocidas y lo que el cómputo permitiría cerrar. Unos 20 minutos. Etiquetas: probado en lógica código ejecutado en un anfitrión, formal el modelo TLA+, VM · anidado · n=1 dominios Xen reales anidados en KVM, probado · bare metal · n=1 los mismos experimentos repetidos en un dom0 Xen físico, pendiente aún sin ejecutar.

• 01 · La idea
• 02 · Un eje distinto
• 03 · Un invariante, cuatro propiedades
• 04 · Cuatro planos de evidencia
• 05 · Evidencia adversarial y bitácora
• 06 · Lo que falta
• 07 · Por qué ahora
• 08 · La solicitud de cómputo
• 09 · Transparencia y propiedad intelectual

01  /  La idea · diseño objetivo

01Una máquina mínima por paso. La siguiente, solo con evidencia.

Imagina al agente de IA de hoy como un astronauta en una nave completamente equipada: red, almacenamiento y credenciales a bordo, cada uno apagado o cercado. Un astronauta lo bastante astuto termina sorteando una cerca, y en buena parte por eso las “fugas” de agentes siguen llegando a las noticias.

Creemos que restringir, por sí solo, no basta: una puerta puede abrirse precisamente porque existe. Por eso el diseño construye cada celda sin las puertas que su paso no necesita.

Hoy, la mayoría de la contención de agentes de IA parte de un sistema operativo completo envuelto en un sandbox que lo restringe. Es un modelo maduro y valioso, y responde bien una pregunta: ¿qué puede tocar el invitado? La nuestra es otra forma de contener el riesgo, aunque no la única. Una celda Kawésqar está pensada para construirse desde el kernel hacia arriba, más cerca de una celda de ejecución hecha a medida que de un SO de propósito general restringido a posteriori, y plantea dos preguntas más:

• ¿Puede el invitado aumentar su propio poder? Cada trabajo corre con un presupuesto de autoridad delegado de antemano. El objetivo del diseño es que ni un trabajo comprometido por completo pueda acuñar autoridad que nunca recibió. En lógica, 31 vectores adversariales no produjeron ninguna amplificación, y el broker y la compuerta reales deniegan los tres intentos de escalada que haría un trabajo así (§05).
• ¿Está siquiera permitido que exista la máquina siguiente? Un sucesor se crea solo cuando la compuerta acepta evidencia sobre la ejecución del predecesor, contrafirmada por un observador fuera de la celda. Sin evidencia válida, no hay siguiente ejecutor, diga lo que diga el invitado de sí mismo.

Cuando el trabajo termina, la máquina desaparece. No hay un sistema operativo permanente y todopoderoso en el medio en el que cada trabajo deba confiar.

Un ejemplo concreto

Supón que un trabajo necesita descargar un archivo. La primera celda hace una sola cosa: llegar a la URL y confirmar que la descarga existe. Solo cuando eso produce evidencia se crea una segunda celda, una máquina nueva cuyo kernel se construyó sin red: la red no está deshabilitada, está ausente. Contiene el archivo y puede escribirlo, una capacidad que la primera celda nunca tuvo.

02  /  Un eje distinto · no un “mejor sandbox”

02Ortogonal, y componible con lo que ya ejecutas.

Presentar a Kawésqar como algo que supera a los contenedores, gVisor, las microVM Firecracker o Qubes sería un error de categoría. Todos son excelentes en contención: reducir qué puede alcanzar un invitado persistente. Kawésqar trabaja sobre un segundo eje, la autoridad y la existencia a lo largo del tiempo, encima del aislamiento por hardware (un hipervisor, una IOMMU). Es una elección de eje, y no dice nada en contra de los demás.

Un agente autónomo es un flujo de trabajos que generan otros trabajos. La pregunta es si un paso 7 comprometido puede otorgarse en silencio la autoridad para lanzar el paso 8 contra tus datos de producción. Kawésqar está diseñado para impedirlo. Está probado en lógica, con brechas declaradas (§06).

Un testigo fuera de la celda

En un sandbox típico, el relato de lo ocurrido viene del interior, y un invitado comprometido puede moldearlo o suprimirlo. En Kawésqar, un observador fuera de la celda atestigua hechos de vida y la ventana de E/S tal como los mide el dominio de control. Atestigua hechos de vida y la ventana de E/S; un testigo separado atestigua el commit mismo sobre los bytes reales en disco, así que un broker comprometido no puede falsificar un COMMITTED. El invitado nunca es fuente confiable de evidencia sobre sí mismo. Límites actuales: en las corridas en VM el observador usó una clave simétrica que también tiene el verificador, y sigue dependiendo del flujo de eventos que le relaya el dominio de control. En bare metal la verificación salió del dominio de control: el observador, la compuerta y la notaría corrieron en un dominio separado con claves asimétricas, y el dominio de control solo relaya bytes y lanza, sin ninguna clave privada. La orden que autoriza a un sucesor la escribe el verificador por su propio canal, y una orden fabricada por el dominio de control muere por firma probado · bare metal · n=1. El dominio de control sigue creando los dominios, aporta las claves públicas y puede inspeccionar la memoria de una celda viva, así que lo que salió de ahí es la verificación, no toda la base de confianza.

03  /  Lo que estamos probando

03Un invariante, cuatro propiedades.

La afirmación, enunciada de modo que pueda falsarse: para todo estado alcanzable, incluso tras el compromiso total del invitado, su autoridad efectiva permanece dentro de lo que su padre delegó.

Son propiedades de diseño: diseñadas para impedir; probadas en lógica, con brechas declaradas. Lo distintivo es una conjunción más que una propiedad suelta: la existencia de un dominio Xen gobernada por evidencia de las transiciones observadas del predecesor, contrafirmada desde fuera de la celda, bajo un techo que no se amplifica. Cada pieza tiene antecedentes: TCU (arXiv 2504.15717), el más cercano, donde un sucesor verifica pruebas de su predecesor, y luego Hyperlaunch y DomB en Xen, seL4, KeyKOS y Nexus. El mecanismo mismo se reserva bajo NDA (§09).

04  /  Evidencia · cuatro planos

04Cuatro planos de evidencia.

Una afirmación de seguridad vale lo que vale la evidencia que la sostiene. Validamos en cuatro planos y cuidamos que ninguno tome prestada la credibilidad de otro. Este bloque lo reúne todo: planos y cifras (§04), el barrido adversarial y la bitácora (§05), las brechas (§06).

Las cifras principales, cada una con su plano

05  /  Evidencia · barrido adversarial y bitácora

05Lo que detiene Xen, y lo que detenemos nosotros.

Barrimos 31 vectores de ataque contra el protocolo en lógica. Por separado, Xen contuvo en una VM a un invitado hostil en bruto, mientras el adversario contra el protocolo mismo corrió en lógica, en el anfitrión. Separar lo que contiene el hipervisor de lo que contiene nuestra lógica impide descartar el resultado con un “eso ya lo hace Xen”.

La bitácora

Cada fila apunta a un archivo de resultados con fecha. Los laboratorios en VM corren Xen 4.20 anidado bajo KVM y no dicen nada sobre rendimiento ni aislamiento duro. Las filas de bare metal corren en un dom0 físico y cubren la arquitectura, todavía no la física fina. Resumen: probado en lógica, modelado formalmente, aislamiento de Xen mostrado en una VM, el núcleo y una ronda de extensión repetidos en bare metal, ahora bajo IOMMU estricto con la ruta criptográfica corriendo dentro de celdas reales, la verificación fuera del dominio de control y una compuerta que exige la firma por sí misma; el confinamiento DMA entre dominios ya está medido en bare metal y el canal lateral SMT está medido y suprimido por el placement (lab52).

Lo más fuerte

El sign-off consolidado está preparado y no firmado. Solo la cadena de lab12 tiene aval de las revisiones internas.

06  /  Evidencia · lo que falta hoy

06La lista de brechas.

Ninguna es un supuesto oculto. Cada una tiene un experimento definido (§08).

• La ruta criptográfica dentro de celdas. Ya corrió de extremo a extremo dentro de celdas reales en bare metal, acotada, y compone en profundidad y en abanico. La verificación también salió del dominio de control (lab47) probado · bare metal · n=1, con claves asimétricas que el lado del control no tiene, y la compuerta misma ahora exige la firma dentro de la celda (lab48) probado · bare metal · n=1. El broker mentiroso también queda contenido: un testigo separado atestigua el commit sobre los bytes reales en disco, así que un COMMITTED falso no crea sucesor probado · bare metal · n=1.
• Sucesión concurrente. Dos decisiones de la compuerta antes de que cualquiera confirme pueden dar dos sucesores desde una misma evidencia. Requiere una verificación y activación atómica. La carrera de reserva se cerró en metal, acotada: el libro de reservas mantuvo Σ(hijos) ≤ el padre bajo 48 hilos en carrera sin una sola doble reserva, mientras que una verificación y activación atómica persistente en la ruta de control de producción queda como brecha declarada. El caso secuencial está cerrado.
• Semántica y expiración de la evidencia. Ambas están ahora cerradas en la compuerta real: una evidencia que no es evidencia externa determinista se deniega (NO_EXTERNAL_EVIDENCE), y la expiración es fail-closed, así que un tiempo monotónico ausente o no numérico se deniega como EXPIRED en vez de pasar. Las suites unitarias siguen en verde (gate 42/42). probado en lógica
• El dominio de control como base de confianza. Rebobinar su estado, borrar el diario o entregarle al observador un flujo falsificado (F9). Sigue creando los dominios y los hechos de ciclo de vida, aporta las claves públicas que usa el verificador (un dominio de control malicioso durante el arranque podría dar una falsa) y puede inspeccionar la memoria de una celda viva, así que la firma dentro de la celda no lo protege sin hardware de memoria cifrada, declarado como futuro. Lo que lab47 cerró es que la verificación salió de ahí, no esto.
• Escala y física. La escala, la profundidad n>1, el brazo adversarial de la compuerta bajo carga, una carrera de reserva, el costo del fan-out de recursos y la frontera observada de la celda ya corrieron en un dom0 físico, ahora bajo IOMMU estricto, que deniega una transferencia no mapeada incluso a la memoria del anfitrión (§05). El confinamiento DMA entre dominios con un dispositivo asignado ya está medido en bare metal (lab50). El canal lateral SMT también está medido (lab52): una celda co-ubicada en el hilo hermano roba ~5 a 6x del throughput, y el placement en un core separado lo devuelve a ~1.1x; el residual de caché entre núcleos queda declarado. Escalar celdas entre máquinas es función del broker, no del hipervisor: dom0 Xen independientes, uno por nodo, cada uno su propia raíz de confianza local que firma sus propios recibos, con la compuerta repartiendo celdas y sin migración de estado vivo. Proxmox y KVM se evaluaron para esto y se dejaron de lado, porque romperían las celdas PVH, la introspección de memoria y los artefactos de arranque y resetearían la evidencia en metal sin entregar el escalado; es una decisión, aún no una prueba.

La arquitectura ahora opera bajo IOMMU estricto en un dom0 físico, con la ruta criptográfica corriendo dentro de celdas reales, la verificación fuera del dominio de control y la compuerta exigiendo la firma por sí misma, todo acotado. El cierre del sign-off sigue pendiente; el confinamiento DMA entre dominios ya está medido en bare metal (lab50), y el pendiente principal es la revisión externa independiente, con un check-and-activate persistente en producción, mTLS (corrido en el dominio de control físico, con la separación en principales y dominios Xen aún abierta) y n de al menos 2 aún abiertos (la composición lab47+48 ya corrió en metal, 5/5, lab55); el canal lateral SMT está ahora medido y suprimido por el placement (lab52).

07  /  Por qué es atractivo, y por qué ahora

07Los agentes hicieron del trabajo la unidad de riesgo.

Los agentes de IA autónomos convirtieron cada plataforma en un generador de trabajo no confiable que se autogenera. No decimos que seamos los mejores, ni que la contención existente esté equivocada. La afirmación es más acotada: este enfoque podría, si las pruebas se sostienen, proteger mejor el trabajo agéntico. Reduce la superficie de ataque a lo que requiere cada paso y apila controles independientes: una celda mínima, autoridad delegada, sucesión gobernada por evidencia y un testigo fuera de la celda. Ninguna capa carga con todo el peso.

Nos apoyamos en controles maduros y poco usados más que en cualquier cosa exótica. Los canales con autenticación mutua (mTLS) en cada enlace son un ejemplo: existen hace décadas, rara vez vienen por defecto, y en Kawésqar ya están construidos y probados, mutuos en ambas direcciones, y corridos en el dominio de control físico; lo que no es principales de SO separados ni dominios Xen separados, el tier siguiente. Cuando una tecnología sólida no se usa por desconocimiento y no por una dificultad real, la adoptamos.

Cómo mediríamos “funciona mejor”

08  /  La solicitud de cómputo

08Qué probaríamos con cómputo, y qué devolvemos.

Cada ítem corresponde a un experimento, un presupuesto de máquinas, un criterio de falsación y un entregable. La mayoría ya corrió en metal, acotada y n=1, así que la solicitud se concentra ahora en tres cosas concretas: hardware con SEV-SNP o TDX para cerrar la secrecía de memoria frente al dominio de control (lab54); una CPU con Intel CAT para particionar la L3 compartida y cerrar el residual de caché entre núcleos (lab53); y un segundo host, distinto, para alcanzar n de al menos 2, más la revisión externa independiente. La tabla de abajo mantiene cada hipótesis con su costo y entregable.

El bare metal es lo único que una VM no puede reemplazar, y el gasto de mayor señal y menor costo: un solo anfitrión con IOMMU convierte el resultado de arquitectura en un resultado de física.

09  /  Transparencia, propiedad intelectual y reproducibilidad

09Resultados públicos, mecanismo reservado.

Una sola política: resultados y conteos son públicos; vectores, formatos y logs crudos van bajo NDA.

Cada cifra sale de un script con veredicto reproducible. Los FAIL salen con código distinto de cero a propósito (lab14 y lab15 lo hacen), y los logs de TLC no son reproducibles bit a bit, así que los resultados formales se verifican por veredicto. Las revisiones internas fueron adversariales y cambiaron esta página: eliminaron la sobreafirmación “confirmado empírica y formalmente” y obligaron a incluir las etiquetas de plano.

Riesgos que no ocultamos

• Dependencia de Xen. La garantía es “suponiendo un hipervisor correcto”. Una base de confianza más pequeña y diversa sigue siendo investigación.
• Los resultados en bare metal son acotados, n=1. Lo que corrió en metal corrió en una máquina, una vez, bajo IOMMU estricto; el modo estricto deniega una transferencia no mapeada incluso a la memoria del anfitrión, y el confinamiento DMA entre dominios con un dispositivo asignado está medido (lab50). Dos límites físicos siguen declarados, a la vista, y ahora medidos: el dominio de control todavía puede leer la memoria de una celda viva, mostrado directamente al recuperar un secreto de la RAM de una celda viva (lab54), que requiere hardware de memoria cifrada (SEV-SNP o TDX, futuro); y un canal de caché entre núcleos distintos, ahora medido y pequeño (~1.1x de interferencia, lab53), un residual que el placement no puede quitar porque todos los cores comparten la L3. El canal lateral SMT está medido y suprimido por el placement: una celda co-ubicada en el hilo hermano roba ~5 a 6x del throughput, y un core separado lo devuelve a ~1.1x (lab52 en metal).
• La novedad es defendible, no demostrada como única. El juicio final corresponde a la revisión externa por pares, un entregable financiado.

El paper completo de arquitectura (v1.3) y el paquete de reproducción están disponibles bajo NDA: rodrigo@kawesqar.org.

01  /  Today · v0.1

What exists, and where each piece stops.

Version 0.1 is a bootable amd64 live ISO of 594 MiB. The maintainer has booted it in VirtualBox to the login prompt and checked it on the serial console. It is not published yet. Everything below was observed on that system or measured in the repository, each number with its limit.

The kernel is our own, 6.12.111-kawesqar, compiled from versioned config fragments on the maintainer’s host. A survival gate, kernel-config.sh --verify-config, runs inside the kernel build and stops it if a single hardening symbol is missing from the built .config.

GRUB · live medium · 2026-10-02
▸ Live system (6.12.111-kawesqar)
  Live system (6.12.111-kawesqar fail-safe mode)
  Start installer
  Advanced install options …

serial console, first boot
Welcome to Kawesqar Secure Linux!
LSM: initializing lsm=capability,landlock,lockdown,yama,safesetid,apparmor,ima,evm
Reached target multi-user.target
Started nftables.service (default-deny ruleset applied) · sshguard.service
kawesqar login: █

What the kernel enforces

• Lockdown in confidentiality mode, forced. LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY=y. Not even root can read or patch kernel memory from user space. This and the next two lines are the strongest part of the kernel.
• Module signatures, enforced. MODULE_SIG_FORCE=y. A module without a valid signature does not load.
• One fixed user-mode helper. STATIC_USERMODEHELPER=y. Every helper the kernel launches goes through one fixed binary, closing a classic route to a root shell.
• Memory zeroed on allocation. init_on_alloc is on by default, so stale data does not leak into new kernel objects.
• Also on. Yama, Landlock, AppArmor, SafeSetID, retpoline, page-table isolation and the SRSO mitigation. Core dumps and debugfs are off.

On the booted system an nftables ruleset (inet kawesqar) loads with a default-deny policy, and in the maintainer’s test sshguard blocked an address after three failed logins. SSH accepts public keys only. Three hardening levels, base, hardened and blindado, are applied after install with kawesqar-harden and are still provisional. Xen can be installed as a package (Xen 4.20, its own tier in the package policy), although the v0.1 ISO does not include it.

Limits of v0.1

• Boot is optical or VM only. The kernel has USB_STORAGE=n, so the ISO does not start from a USB stick.
• No install with LUKS. The kernel has DM_CRYPT=n.
• On the live medium AppArmor loads 0 profiles. They apply only on an installed system.
• No Secure Boot.
• The ISO is not signed, because the DEV key lists are empty.
• The kernel was built twice, on two independent machines, and compared byte by byte: the 292 modules are identical in code, and the only differences are the per-build module signing key and the Rust compiler version the config auto-detects on one host, which the kernel does not use. Full bit-for-bit identity also needs a pinned toolchain and signing key.
• The v0.1 kernel does not carry Xen dom0 support, so the packaged hypervisor cannot run on it. A separate kernel variant with dom0 support is what the lab runs on a physical Xen host, and it is not in v0.1.

02  /  The alpha · what we are building

What the public alpha is meant to carry.

Everything in this block is a goal for the public alpha, not something you can run today. The alpha ships Kawésqar Server together with the Agent Fabric, described in the Overview. Where tooling already exists, we say how far it has been run.

For the public alpha, every package is rebuilt from source with our own flags: PIE, full RELRO, BIND_NOW, stack protector and FORTIFY 3. Today the image ships three packages of our own, the kernel, the hardening profiles and Ramón. The other 226 are installed as upstream binaries.

planned · public alpha tooling in tests · no real runs

03  /  Ramón

A mouse on row one of the console. mechanism with tests, not field-tested

Ramón is the console companion of Kawésqar Server, written in Go and already in the v0.1 image: a grumpy mouse that watches the system, speaks rarely and acts only with your approval. It holds no credentials and never hides a security alert. No AI service runs by default; Ramón has an opt-in, default-deny LLM client whose network gate stays closed until you open it. In a measurement dated 2026-10-01, go test passed in 38 packages and two builds on the same host gave an identical binary. Open limit: on the latest test image the watcher restarts in a loop.

04  /  Governance and licence

Who decides, and what is still missing.

Why a server carries these names is told in the Kawésqar tab.

01  /  Hoy · v0.1

Lo que existe, y dónde se detiene cada pieza.

La versión 0.1 es una ISO live amd64 arrancable de 594 MiB. El mantenedor la arrancó en VirtualBox hasta el prompt de login y la revisó por la consola serie. Aún no está publicada. Todo lo que sigue se observó en ese sistema o se midió en el repositorio, cada número con su límite.

El kernel es propio, 6.12.111-kawesqar, compilado desde fragmentos de configuración versionados en el anfitrión del mantenedor. Una compuerta de supervivencia, kernel-config.sh --verify-config, corre dentro de la compilación del kernel y la detiene si falta un solo símbolo de endurecimiento en el .config resultante.

GRUB · medio live · 2026-10-02
▸ Live system (6.12.111-kawesqar)
  Live system (6.12.111-kawesqar fail-safe mode)
  Start installer
  Advanced install options …

consola serie, primer arranque
Welcome to Kawesqar Secure Linux!
LSM: initializing lsm=capability,landlock,lockdown,yama,safesetid,apparmor,ima,evm
Reached target multi-user.target
Started nftables.service (reglas de denegación por defecto aplicadas) · sshguard.service
kawesqar login: █

Lo que el kernel exige

• Lockdown en modo confidentiality, forzado. LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY=y. Ni siquiera root puede leer ni parchear la memoria del kernel desde el espacio de usuario. Esto y las dos líneas siguientes son lo más fuerte del kernel.
• Firma de módulos, exigida. MODULE_SIG_FORCE=y. Un módulo sin firma válida no se carga.
• Un único ayudante de modo usuario. STATIC_USERMODEHELPER=y. Todo ayudante que lanza el kernel pasa por un binario fijo, y así se cierra una ruta clásica hacia una shell de root.
• Memoria a cero al asignarla. init_on_alloc viene activo por defecto, así que datos viejos no se filtran a objetos nuevos del kernel.
• También activos. Yama, Landlock, AppArmor, SafeSetID, retpoline, aislamiento de tablas de páginas y la mitigación SRSO. Volcados de memoria y debugfs apagados.

En el sistema arrancado se carga un conjunto de reglas nftables (inet kawesqar) con política de denegación por defecto, y en la prueba del mantenedor sshguard bloqueó una dirección tras tres logins fallidos. SSH acepta solo llaves públicas. Tres niveles de endurecimiento, base, hardened y blindado, se aplican tras la instalación con kawesqar-harden y siguen siendo provisionales. Xen se puede instalar como paquete (Xen 4.20, un grupo propio en la política de paquetes), aunque la ISO v0.1 no lo incluye.

Límites de v0.1

• El arranque es solo desde óptico o VM. El kernel lleva USB_STORAGE=n, así que la ISO no arranca desde un pendrive.
• No se puede instalar con LUKS. El kernel lleva DM_CRYPT=n.
• En el medio live AppArmor carga 0 perfiles. Solo aplican en un sistema instalado.
• Sin Secure Boot.
• La ISO no va firmada, porque las listas de claves DEV están vacías.
• El kernel se compiló dos veces, en dos máquinas independientes, y se comparó byte a byte: los 292 módulos son idénticos en código, y las únicas diferencias son la clave de firma de módulos por build y la versión del compilador de Rust que el config auto-detecta en un anfitrión, que el kernel no usa. La identidad bit a bit total pide además fijar el toolchain y la clave de firma.
• El kernel de v0.1 no trae soporte dom0 de Xen, así que el hipervisor empaquetado no puede correr sobre él. Una variante de kernel aparte, con soporte dom0, es la que usa el laboratorio en un anfitrión Xen físico, y no está en v0.1.

02  /  El alfa · lo que estamos construyendo

Lo que el alfa público debe traer.

Todo este bloque es un objetivo del alfa público, no algo que puedas correr hoy. El alfa entrega Kawésqar Server junto con el Agent Fabric, descrito en Inicio. Donde ya hay herramientas, decimos hasta dónde se han ejecutado.

Para el alfa público, cada paquete se recompila desde el fuente con nuestros propios flags: PIE, RELRO completo, BIND_NOW, protector de pila y FORTIFY 3. Hoy la imagen trae tres paquetes propios, el kernel, los perfiles de endurecimiento y Ramón. Los otros 226 se instalan como binarios de upstream.

planificado · alfa público herramientas en tests · sin corridas reales

03  /  Ramón

Un ratón en la fila uno de la consola. mecanismo con tests, sin uso en campo

Ramón es el acompañante de consola de Kawésqar Server, escrito en Go y ya incluido en la imagen v0.1: un ratón gruñón que vigila el sistema, habla poco y actúa solo con tu aprobación. No tiene credenciales y nunca oculta una alerta de seguridad. Ningún servicio de IA corre por defecto; Ramón trae un cliente LLM opcional, con denegación por defecto, cuya salida de red sigue cerrada hasta que tú la abras. En una medición del 2026-10-01, go test pasó en 38 paquetes y dos compilaciones en el mismo anfitrión dieron un binario idéntico. Límite abierto: en la última imagen de prueba el vigía se reinicia en bucle.

04  /  Gobernanza y licencia

Quién decide, y qué falta todavía.

Por qué un servidor lleva estos nombres se cuenta en la pestaña Kawésqar.

01  /  Who it is for

People who open a terminal first.

The server's spine with a screen on it: no suite, no store, no bloat. For the administrator who lives in ssh and tmux, the responder who needs tools and nothing else, the network engineer with many consoles, and the hacker who wants to know exactly what is running.

02  /  Two editions

BlackBox and Motif.

03  /  Inherited from the server

The same hardened base.

By design, once the image exists.

• The hardening. Same sysctl, PAM, login policy and module loading. Same default-deny firewall. Same security modules at boot.
• Kernel choice. For laptops, the choice is open. Where hardware allows it, the server's hardened kernel. Where different drivers are needed, a documented choice.
• The updater. ramon update, signed and with snapshots for rollback, once it reaches the workstation. kswup, the earlier design, stays on paper.
• Identity. Boot splash, login theme, wallpapers, MOTD, os-release.

·  /  Ramón

The same mouse, on the workstation too.

Ramón comes with the workstation as well: the same first row in the terminal, the same watch over logs and sessions, the same customs gate for a coding agent. Only in terminals, never in the file manager and never as desktop notifications. It is described on the Server page and is in development for the next release.

04  /  Status

A prototype under construction.

Today it runs on the maintainer's workstation; there is no image yet. Not part of the first alpha. What is built: BlackBox and Motif are working, branding is in progress. Everything else is open.

Conceived in Chilean Patagonia · a system for work · the shell is the interface.

01  /  Para quién es

Gente que abre primero una terminal.

La columna del servidor con una pantalla encima: sin suite, sin tienda, sin relleno. Para el administrador que vive en ssh y tmux, quien atiende incidentes y solo pide herramientas, el ingeniero de red con muchas consolas y el hacker que quiere saber exactamente qué corre.

02  /  Dos ediciones

BlackBox y Motif.

03  /  Hereda del servidor

La misma base endurecida.

Por diseño, una vez que la imagen exista.

• El hardening. Mismo sysctl, PAM, política de login y carga de módulos. Mismo firewall de negación por defecto. Mismos módulos de seguridad al arrancar.
• Kernel. Para notebooks, la opción está abierta. Donde hardware lo permite, el kernel endurecido del servidor. Donde se necesitan drivers distintos, una decisión documentada.
• El actualizador. ramon update, firmado y con snapshots para revertir, cuando llegue a la workstation. kswup, el diseño anterior, queda en papel.
• Identidad. Splash de arranque, tema de login, fondos, MOTD, os-release.

·  /  Ramón

El mismo ratón, también en la workstation.

Ramón viene también con la workstation: la misma primera fila en la terminal, la misma vigilancia de logs y sesiones, la misma aduana para un agente de código. Solo en terminales, nunca en el gestor de archivos ni como notificaciones de escritorio. Está descrito en la página Server y en desarrollo para la siguiente versión.

04  /  Estado

Un prototipo en construcción.

Hoy corre en la estación de trabajo del mantenedor; aún no hay imagen. No es parte del primer alfa. Lo que está construido: BlackBox y Motif funcionan, identidad visual en curso. El resto está anotado como brecha, a la vista.

Concebido en la Patagonia chilena · un sistema para el trabajo · la shell es la interfaz.

→  /  Nine lines

Nine questions, ordered by how soon we could test them.

L2, L1 and L3 are the easiest to test. Every line is at design stage, with no code. L9 closes the table because it is a problem line, not a hypothesis. The fourth column lists only where the analogy stops explaining; engineering risks are covered by the hard limit above. Read the table first, then open a card for the biology, a question for specialists and the disciplines we hope to hear from.

→  /  The detail

Open a line to read the biology.

→  /  How to take part

Tell us what makes sense, and what doesn’t.

An objection of three lines is enough: which line, what breaks, and what observation would show it. No portfolio and no statement of motivation. We will keep a public register of every objection received and what we did with it, including the lines we withdraw.

The working memoranda behind these summaries are shared under the access tiers described in the Vision tab. We would rather hear the objection that breaks an idea than the reasons it sounds nice.

Rodrigo Gutiérrez · rodrigo@kawesqar.org · northern Patagonia, Chile

→  /  Nueve líneas

Nueve preguntas, ordenadas por lo pronto que podríamos probarlas.

L2, L1 y L3 son las más fáciles de probar. Todas las líneas están en etapa de diseño, sin código. L9 cierra la tabla porque es una línea de problema, no una hipótesis. La cuarta columna recoge solo dónde la analogía deja de explicar; los riesgos de ingeniería los cubre el límite duro de arriba. Lee primero la tabla y abre después una ficha para ver la biología, una pregunta para especialistas y las disciplinas que esperamos escuchar.

→  /  El detalle

Abre una línea para leer la biología.

→  /  Cómo participar

Dinos qué tiene sentido y qué no.

Basta una objeción de tres líneas: qué línea, qué se rompe y qué observación lo mostraría. Sin portafolio y sin carta de motivación. Llevaremos un registro público de cada objeción recibida y de lo que hicimos con ella, incluidas las líneas que retiremos.

Los memorandos de trabajo detrás de estos resúmenes se comparten bajo los niveles de acceso descritos en la pestaña Visión. Preferimos escuchar la objeción que rompe una idea antes que las razones por las que suena bien.

Rodrigo Gutiérrez · rodrigo@kawesqar.org · Patagonia norte, Chile

01  /  Why it isn’t here yet

The will is here. The ecosystem isn’t.

What Chile does not yet have is the ecosystem this work needs: a critical mass of deeply specialized talent and an investment culture willing to back it. The country is intensely centralized, and almost every serious path runs through the capital or abroad. According to IDB Lab, only about 10% of Chile’s venture capital reaches deep tech, which starves the slow, expensive stages between a prototype and a product. Of more than 18,300 PhDs, around 7% work in companies.

That the south has the talent is a conviction, and the best proof we can offer is a track record: the person behind this reported maximum-severity vulnerabilities, worked at Trustix in Norway, led cyberdefense in industry at Itaú Corpbanca and builds today from northern Patagonia. See Who is behind this, below.

02  /  Not idealism

Anchored to a product.

A vision alone is a wish. This one rides on Agent Fabric, aimed at a problem that is global and growing: running untrusted, autonomous AI agents without handing them standing authority. An industry in the south does not have to live on subsidy. It can sustain itself the ordinary way, by building something the world needs to a standard the world can verify.

• Overview: the execution fabric for untrusted agents.
• Server: the hardened distribution it runs on.
• Research: open lines of defense science.

03  /  A high bar, on purpose

An industry that is hard to stand up overnight.

We hold this work to a first-rate international standard, not the bar that often passes for “enough”. Deep security and systems engineering of this kind are not improvised overnight without the knowledge and experience behind them. That difficulty is the point: a demanding field can take root in northern Patagonia and compete globally on its own merits, not on proximity to a capital.

04  /  What we build here, concretely

An industry, one deliverable at a time.

Each piece has its own page, its own evidence and its own maturity label.

• Agent Fabric: disposable execution cells on Xen, gated by external evidence.
• Kawésqar Research: open defense science, with a lab for those who come to build.
• Laboratories in northern Patagonia, with universities and partners who bring equipment first.
• Talks and hands-on time for young people in vulnerable situations.

The horizon is an intention, not a promise. Each row moves to the product pages only when there is evidence behind it.

05  /  Universities, on practical terms

We don’t need a badge. We need labs.

We are not tied to any university, and we are not here to give courses: there is too much to build. We are open to something concrete. If a university brings what is scarce here, the infrastructure to do real science, with laboratories and equipment up front, we will support it, take part and experiment with the hard, new ideas alongside it. Scientists whose fields might inform system defense are welcome too, and the Research tab is the open call.

06  /  Talent where it is overlooked

A degree does not make you someone.

Our founder and maintainer gives talks to motivate and to show what is possible. Teaching would happen only where a class can change a life: with children and young people in vulnerable situations, who cannot picture a future because nobody at home can pay for university.

Their disadvantage starts long before tuition: public schools without a private school’s resources, a society that judges you by how you speak, a system that tells you that without a degree you are nobody. This trade proves otherwise. Here a degree counts for little, and the work does not care about your accent or where you studied. It asks for the self-taught kind of learning, watching, reading, failing twenty times and persisting until it runs. What always worked against you can become your advantage: a lateral way of seeing and the resilience to hold it. That is the talent we most want to find.

07  /  Who is behind this

We did not arrive yesterday.

Our founder and maintainer has 27 years in the field: he helped build pioneering secure-Linux distributions and reported maximum-severity vulnerabilities. The road began with reverse engineering in the 1990s, and the first formal home was Trustix, in Norway: secure Linux, firewalls, infrastructure management and over-the-air updates for mobile devices, a company ahead of its time and a very good school. Later, in industry: security roles at CSC and IBM, and then director of cyberdefense at Itaú Corpbanca, leading six areas.

Among them is CVE-2004-0214, a long share-name buffer overflow in Microsoft Windows (Explorer and Internet Explorer), rated CVSS 10.0 and fixed in Microsoft bulletin MS04-037. A flaw of that class could have compromised essentially every Windows system of its time. That history does not make this work flawless. It means the instincts were earned, and there is a public trail you can check instead of taking it on faith.

The record is public and it is old. In the early 2000s he reported a remote buffer overflow in the Blue World Lasso web platform (CVE-2002-2118), and in 2005 he found and disclosed cross-site scripting in the “Speaking of Security” blog of RSA, one of the most important security companies in the world, kept in the industry errata. All of that around 2005, when most people had not yet heard the word cybersecurity.

We are a small team of motivated professionals and we treat evidence as the final judge: every claim carries where it was tested, and every gap is shown instead of buried. It is built on personal time and limited means, out of conviction.

Rodrigo Gutiérrez · linkedin.com/in/ciberdefensa · rodrigo@kawesqar.org · northern Patagonia, Chile

08  /  How we work · who we are looking for

Open, evidence-first, and built on other people’s late nights.

The core is, and will remain, free and open source: a small contribution to a movement we believe in and to the years of work in the software beneath us. Everything we claim has its evidence beside it, for you to read, question, improve or refute with a proof of concept or a well-reasoned argument.

Who we are looking for

People who like to experiment and can prove what they imagine: kernel developers, Linux and BSD alike; scientists, physicists and biologists whose ideas may map onto system defense; cyber-defense veterans and creative pentesters; anyone who can take an idea and make it run on an old machine. You do not need a title, decades on paper or public recognition. Knowledge, the right motivation and contributions backed by believable evidence are the whole bar. Tell us your motivation, how you could contribute now, and show us some of your work. Early access to the evidence is narrow and need-to-know until the public alpha, when the repositories open and the bar becomes the ordinary one: good work, in the open.

For partners and funders

Infrastructure, compute credits or financial support are welcome, and supporters are recognized. You get the data behind every claim, the experimental code and the documentation of how each test was run, so you can reproduce it. In return, tell us what you bring, what you expect back and what motivates you. The project is not for sale: the core will be free and open, and that is a commitment, not a negotiating position.

Building fast with new tools is a skill we respect. At this stage we present to organizations already working in experimental systems engineering or AI, because explaining how a Linux kernel or an open hypervisor works would use time we need for the evidence. Many products do not hold up on the inside, and this one is judged by what is underneath.

The proof of concept is a trimmed, hardened kernel and Xen hypervisor shipped with an untouched baseline to measure against, and its goal is to stand up to a serious frontier agent attacking it. The architecture has been tested nested and then re-tested on a physical Xen host, scoped and n=1, assuming a correct hypervisor. That re-test ran under the strictest IOMMU mode, which denies transfers that were never mapped, and with the cryptographic path working end to end inside real cells and composing at depth beyond one. Verification also ran outside the control domain, and the Gate itself now demands the in-cell signature, two separate results. The cell boundary was also measured: a cell without a disk exposes only its console to the host, with zero private memory pages, and a 400-cycle soak under strict IOMMU leaked no IOMMU or grant structures. The SMT side channel is measured and suppressed by placement (lab52): a co-located sibling-thread cell steals about 5 to 6x of a victim's throughput, and a separate core brings it back to about 1.1x. The cross-core cache channel is measured too and small (about 1.1x, lab53), left as a declared residual since placement cannot remove it. DMA confinement between domains was measured on bare metal (lab50); the main remaining item is an independent external review, with n of at least 2 and a persistent check-and-activate still open. It may not hold, and we will report what happens either way.

01  /  Por qué todavía no está aquí

Las ganas están. El ecosistema no.

Lo que a Chile aún le falta es el ecosistema que este trabajo necesita: una masa crítica de talento muy especializado y una cultura de inversión dispuesta a respaldarlo. El país está muy centralizado, y casi todo camino serio pasa por la capital o por el extranjero. Según IDB Lab, solo cerca del 10 % del capital de riesgo de Chile llega al deep tech, lo que deja sin recursos las etapas lentas y caras entre un prototipo y un producto. De más de 18 300 doctores, alrededor del 7 % trabaja en empresas.

Que el sur tiene el talento es una convicción, y la mejor prueba que podemos ofrecer es una trayectoria: quien está detrás de esto reportó vulnerabilidades de severidad máxima, trabajó en Trustix, en Noruega, dirigió la ciberdefensa en la industria en Itaú Corpbanca y construye hoy desde la Patagonia norte. Ver Quién está detrás, más abajo.

02  /  No es idealismo

Anclado a un producto.

Una visión sola es un deseo. Esta se apoya en Agent Fabric, que apunta a un problema global y en crecimiento: ejecutar agentes de IA autónomos y no confiables sin entregarles autoridad permanente. Una industria en el sur no tiene por qué vivir de subsidios. Puede sostenerse como cualquier otra, construyendo algo que el mundo necesita con un estándar que el mundo puede verificar.

• Inicio: el fabric de ejecución para agentes no confiables.
• Server: la distribución endurecida sobre la que corre.
• Investigación: líneas abiertas de ciencia de defensa.

03  /  Una vara alta, a propósito

Una industria difícil de levantar de la noche a la mañana.

Sostenemos este trabajo con un estándar internacional de primer nivel, no con la vara que a menudo pasa por “suficiente”. La seguridad profunda y la ingeniería de sistemas de este tipo no se improvisan de un día para otro sin el conocimiento y la experiencia que las respaldan. Esa dificultad es el punto: un campo exigente puede echar raíces en la Patagonia norte y competir en el mundo por sus propios méritos, no por su cercanía a una capital.

04  /  Qué construimos aquí, concretamente

Una industria, un entregable a la vez.

Cada pieza tiene su propia página, su propia evidencia y su propia etiqueta de madurez.

• Agent Fabric: celdas de ejecución desechables sobre Xen, gobernadas por evidencia externa.
• Kawésqar Research: ciencia de defensa abierta, con un laboratorio para quien viene a construir.
• Laboratorios en la Patagonia norte, con universidades y socios que aportan el equipamiento por adelantado.
• Charlas y horas de práctica para jóvenes en situación de vulnerabilidad.

El horizonte es una intención, no una promesa. Cada fila pasa a las páginas de producto solo cuando hay evidencia detrás.

05  /  Universidades, en términos prácticos

No necesitamos una placa. Necesitamos laboratorios.

No estamos atados a ninguna universidad, y no estamos aquí para dar cursos: hay demasiado por construir. Estamos abiertos a algo concreto. Si una universidad aporta lo que aquí escasea, la infraestructura para hacer ciencia de verdad, con laboratorios y equipamiento por adelantado, la apoyamos, participamos y experimentamos junto a ella con las ideas nuevas y difíciles. También son bienvenidos los científicos cuyos campos puedan aportar a la defensa de sistemas, y la pestaña Investigación es la convocatoria abierta.

06  /  Talento donde se pasa por alto

Un título no te hace alguien.

Nuestro fundador y mantenedor da charlas para motivar y mostrar lo que es posible. Enseñar solo ocurriría donde una clase puede cambiar una vida: con niños y jóvenes en situación de vulnerabilidad, que no logran imaginarse un futuro porque en su casa nadie puede pagar la universidad.

Su desventaja empieza mucho antes de la matrícula: escuelas públicas sin los recursos de un colegio pagado, una sociedad que te juzga por cómo hablas, un sistema que te repite que sin título no eres nadie. Este oficio demuestra lo contrario. Aquí el título pesa poco, y al trabajo no le importa tu acento ni dónde estudiaste. Pide aprender como autodidacta: mirando, leyendo, fallando veinte veces y persistiendo hasta que corra. Lo que siempre jugó en tu contra puede volverse tu ventaja: una forma lateral de ver y la resistencia para sostenerla. Ese es el talento que más queremos encontrar.

07  /  Quién está detrás

No llegamos ayer.

Nuestro fundador y mantenedor lleva 27 años en el área: participó en distribuciones pioneras de Linux seguro y reportó vulnerabilidades de severidad máxima. El camino empezó con la ingeniería inversa en los años 90, y el primer hogar formal fue Trustix, en Noruega: Linux seguro, firewalls, gestión de infraestructura y actualizaciones por aire para dispositivos móviles, una empresa adelantada a su época y una muy buena escuela. Después, en la industria: roles de seguridad en CSC e IBM, y luego director de ciberdefensa en Itaú Corpbanca, a cargo de seis áreas.

Entre ellas está CVE-2004-0214, un desbordamiento de búfer por nombre de recurso compartido largo en Microsoft Windows (Explorer e Internet Explorer), calificado CVSS 10.0 y corregido en el boletín MS04-037 de Microsoft. Una falla de esa clase pudo comprometer prácticamente todos los Windows de su época. Esa trayectoria no vuelve impecable este trabajo. Significa que el instinto se ganó a pulso, y que hay un rastro público que puedes comprobar en vez de aceptarlo por fe.

El registro es público y viene de lejos. A comienzos de los 2000 reportó un desbordamiento de búfer remoto en la plataforma web Blue World Lasso (CVE-2002-2118), y en 2005 encontró y divulgó cross-site scripting en el blog “Speaking of Security” de RSA, una de las empresas de seguridad más importantes del mundo, guardado en el errata de la industria. Todo eso alrededor de 2005, cuando la mayoría todavía no había escuchado la palabra ciberseguridad.

Somos un equipo pequeño de profesionales motivados y tratamos la evidencia como juez final: cada afirmación lleva el lugar donde fue probada, y cada brecha se muestra en vez de enterrarse. Se construye con tiempo personal y medios limitados, por convicción.

Rodrigo Gutiérrez · linkedin.com/in/ciberdefensa · rodrigo@kawesqar.org · Patagonia norte, Chile

08  /  Cómo trabajamos · a quién buscamos

Abierto, con la evidencia primero, y construido sobre las noches en vela de otros.

El núcleo es, y seguirá siendo, libre y de código abierto: un pequeño aporte a un movimiento en el que creemos y a los años de trabajo del software sobre el que nos apoyamos. Todo lo que afirmamos tiene su evidencia al lado, para que la leas, la cuestiones, la mejores o la refutes con una prueba de concepto o un argumento bien fundado.

A quién buscamos

Gente que disfruta experimentar y sabe probar lo que imagina: desarrolladores de kernel, de Linux y de BSD por igual; científicos, físicos y biólogos cuyas ideas puedan trasladarse a la defensa de sistemas; veteranos de la ciberdefensa y pentesters creativos; quien sea capaz de tomar una idea y hacerla correr en una máquina vieja. No necesitas un título, décadas de currículum ni reconocimiento público. Conocimiento, la motivación correcta y contribuciones respaldadas por evidencia creíble son toda la vara. Cuéntanos tu motivación, cómo podrías aportar ahora y muéstranos parte de tu trabajo. El acceso temprano a la evidencia es acotado y por necesidad de saber hasta el alfa público, cuando se abren los repositorios y la vara pasa a ser la habitual: buen trabajo, a la vista de todos.

Para socios y financistas

Agradecemos la infraestructura, los créditos de cómputo o el apoyo financiero, y reconocemos a los patrocinadores. Tienes los datos detrás de cada afirmación, el código experimental y la documentación de cómo se ejecutó cada prueba, para que puedas reproducirla. A cambio, cuéntanos qué aportas, qué esperas a cambio y qué te motiva. El proyecto no está en venta: el núcleo será libre y abierto, y eso es un compromiso, no una postura de negociación.

Construir rápido con herramientas nuevas es una habilidad que respetamos. En esta etapa nos presentamos ante organizaciones que ya trabajan en ingeniería de sistemas experimentales o en IA, porque explicar cómo funciona un kernel Linux o un hipervisor abierto gastaría el tiempo que necesitamos para la evidencia. Muchos productos no se sostienen por dentro, y este se juzga por lo que hay debajo.

La prueba de concepto es un kernel y un hipervisor Xen recortados y endurecidos, entregados con una línea base intacta contra la cual medir, y su meta es resistir a un agente de frontera serio que la ataque. La arquitectura se probó anidada y luego se volvió a probar en un anfitrión Xen físico, acotado y n=1, suponiendo un hipervisor correcto. Esa nueva prueba corrió bajo el modo de IOMMU más estricto, que deniega las transferencias que nunca se mapearon, y con la ruta criptográfica funcionando de extremo a extremo dentro de celdas reales y componiendo a profundidad mayor que uno. La verificación también corrió fuera del dominio de control, y la compuerta misma ahora exige la firma dentro de la celda, dos resultados separados. También se midió la frontera de la celda: una celda sin disco expone al anfitrión solo su consola, con cero páginas de memoria privada, y una prueba de resistencia de 400 ciclos bajo IOMMU estricto no tuvo fugas de estructuras del IOMMU ni de concesiones. El canal lateral SMT está medido y suprimido por el placement (lab52): una celda co-ubicada en el hilo hermano roba ~5 a 6x del throughput de la víctima, y un core separado lo devuelve a ~1.1x. El canal por caché entre núcleos también está medido y es pequeño (~1.1x, lab53), como residual declarado porque el placement no lo puede quitar. El confinamiento DMA entre dominios quedó medido en bare metal (lab50); el pendiente principal es una revisión externa independiente, con n de al menos 2 y un check-and-activate persistente aún abiertos. Puede no cumplirse, y contaremos lo que ocurra en cualquier caso.

·  /  Who they are

The canoe people of the austral channels.

The Kawésqar (also written Kawéskar) are an Indigenous people of the Patagonian archipelago of south-western Chile. For thousands of years they lived as nómadas canoeros, canoe nomads: moving through cold, storm-worn waters, fishing, diving for shellfish, hunting sea mammals, and carrying fire with them from one shore to the next.

Contact with Europeans began from the sixteenth century, and with full force in the nineteenth and twentieth. Disease and displacement reduced them to a small community, today centred around Puerto Edén on Wellington Island, and the Kawésqar language is critically endangered, held now by only a handful of fluent speakers.

Sources: the Museo Chileno de Arte Precolombino; the Mineduc Programa de Lengua y Cultura de Pueblos Originarios, pueblo Kawésqar; the dictionary work of Aguilera and Tonko; and the state’s La lengua kawésqar.

·  /  How they lived

A territory made of water.

The Kawésqar lived not on the land so much as between the islands, from the Gulf of Penas to the Strait of Magellan, a maze of channels where it rains most days and the wind rarely stops.

In numbers: about 4,000 people before European contact; 3,448 identified as Kawésqar in the 2017 census, up from 2,622 in 2002; and 2.84 million hectares in the Kawésqar National Park, created in 2018.

Figures from Chile’s 2017 census (INE), the park decree and published research on the 1881 exhibitions. We are engineers, not historians; where we are wrong, we will correct it.

·  /  Words we borrow

Three words, used with care.

Spelled as in the sources above; spellings vary and we are not linguists. The words are a mental model for the people who run the machine, not a claim about a language.

·  /  Why we honor it

To endure a demanding world, fit it.

This is our reading of how the Kawésqar endured, not a claim about their philosophy. We see a people who did not try to dominate the channels, and who read their environment with patient, exact knowledge built over thousands of years. How they would put it is theirs to say.

From that reading we take a few principles for our own work. A secure system does not get safer by carrying more code, more capability, more standing authority “just in case.” It gets safer by carrying less.

·  /  Where it was conceived

Conceived in northern Patagonia.

Kawésqar was imagined in northern Patagonia, Chile, under a similar climate, further north along the same coast. That place is the temperament we want for the work: patient, self-reliant, unimpressed by noise, and more interested in what holds up against the wind than in what looks good on a calm day.

Our mark is the Southern Cross, the constellation that names the south.

If this work keeps the name in the light and sends a few readers to learn about the Kawésqar people and their endangered language, that is part of the point.

·  /  Quiénes son

El pueblo canoero de los canales australes.

Los Kawésqar (también escrito Kawéskar) son un pueblo indígena del archipiélago patagónico, en el suroeste de Chile. Durante miles de años vivieron como nómadas canoeros. Recorrían aguas frías y azotadas por los temporales, pescaban, buceaban en busca de mariscos, cazaban mamíferos marinos y llevaban el fuego consigo de una orilla a otra.

El contacto con los europeos comenzó desde el siglo XVI, y con toda su fuerza en los siglos XIX y XX. Las enfermedades y el desarraigo los redujeron a una comunidad pequeña, hoy centrada en Puerto Edén, en la isla Wellington. La lengua kawésqar está en peligro crítico: solo un puñado de personas la habla con fluidez.

Fuentes: el Museo Chileno de Arte Precolombino; el Programa de Lengua y Cultura de Pueblos Originarios, pueblo Kawésqar, del Mineduc; el trabajo lexicográfico de Aguilera y Tonko; y La lengua kawésqar, del Estado.

·  /  Cómo vivían

Un territorio hecho de agua.

Los Kawésqar vivían no tanto sobre la tierra como entre las islas, del golfo de Penas al estrecho de Magallanes, un laberinto de canales donde llueve casi todos los días y el viento rara vez para.

En cifras: unas 4000 personas antes del contacto europeo; 3448 se identificaron como Kawésqar en el censo de 2017, frente a 2622 en 2002; y 2,84 millones de hectáreas en el Parque Nacional Kawésqar, creado en 2018.

Cifras del censo 2017 (INE), del decreto del parque y de investigación publicada sobre 1881. Somos ingenieros, no historiadores; donde nos equivoquemos, corregiremos.

·  /  Palabras que tomamos

Tres palabras, usadas con cuidado.

Grafías según las fuentes de arriba; varían y no somos lingüistas. Las palabras son un modelo mental para quienes operan la máquina, no una afirmación sobre una lengua.

·  /  Por qué lo honramos

Para perdurar en un mundo exigente, encaja en él.

Esta es nuestra lectura de cómo perduraron los Kawésqar, no una afirmación sobre su filosofía. Vemos a un pueblo que no intentó dominar los canales, y que leyó su entorno con un conocimiento paciente y exacto, acumulado durante miles de años. Cómo lo dirían ellos es cosa suya.

De esa lectura tomamos unos pocos principios para nuestro propio trabajo. Un sistema no se vuelve más seguro cargando más código, capacidad o autoridad permanente “por si acaso”, sino cargando menos.

·  /  Dónde fue concebido

Concebido en la Patagonia norte.

Kawésqar fue imaginado en la Patagonia norte, bajo un clima parecido, más al norte sobre la misma costa. Ese lugar es el temperamento que queremos para el trabajo: paciente, autosuficiente, indiferente al ruido, más atento a lo que resiste el viento que a lo que impresiona en un día de calma.

Nuestra marca es la Cruz del Sur, la constelación que nombra el sur.

Si este trabajo mantiene visible el nombre y lleva a algunos lectores a conocer al pueblo y su lengua, eso es parte del propósito.