·  /  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, pending not run yet.

• 01 · The idea
• 02 · A different axis
• 03 · One invariant, four properties
• 04 · Three 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 (§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 does not attest the content of the commit. That gap is C5 (§06). The guest is never a trusted source of evidence about itself. Current limits: the observer runs in its own domain on the same host, depends on the event stream the control domain relays to it, and in the VM runs used a symmetric key the verifier also holds. Moving it to an independent notary is on the roadmap.

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 · three planes

04Three planes of evidence.

A security claim is worth the evidence under it. We validate on three 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. Summary: tested in logic, modeled formally, Xen isolation shown on a VM, cryptographic VM run and bare metal still pending.

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 on a VM. Re-run the chain with asymmetric signatures, an observer that shares no key with the verifier, and a lying broker.
• Compromised broker (C5), the most critical gap. It already falls in logic: the observer countersigns a false COMMITTED, even for a hash never stored, and the Gate creates B. The VM experiment is designed and pending, and C5 is outside today's declared threat model.
• 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 sequential case is closed.
• Evidence semantics and expiry. Evidence marked advisory still passes one Gate check, and expiry fails open. Both fixes come before the next phase.
• The control domain as trust base. Rewinding its state, deleting the journal, or feeding the observer a forged stream (F9).
• Scale & physics. More than one concurrent cell, and the bare-metal campaign (DMA/IOMMU isolation, performance, side channels), which a VM cannot measure.

The nested architecture validation is advanced. The cryptographic VM run and the sign-off are pending, followed by a physics campaign on hardware.

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 planned, not built. 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 pending item maps to one experiment, a machine budget, a falsification criterion and a 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.
• Nested results are not physics. Everything here is nested, n=1, until the bare-metal campaign.
• Novelty is defensible, not proven 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, pendiente aún sin ejecutar.

• 01 · La idea
• 02 · Un eje distinto
• 03 · Un invariante, cuatro propiedades
• 04 · Tres 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 (§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. No atestigua el contenido del commit. Esa brecha es C5 (§06). El invitado nunca es fuente confiable de evidencia sobre sí mismo. Límites actuales: el observador corre en su propio dominio en el mismo anfitrión, depende del flujo de eventos que le relaya el dominio de control y en las corridas en VM usó una clave simétrica que también tiene el verificador. Llevarlo a una notaría independiente está en la hoja de ruta.

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 · tres planos

04Tres planos de evidencia.

Una afirmación de seguridad vale lo que vale la evidencia que la sostiene. Validamos en tres 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. Resumen: probado en lógica, modelado formalmente, aislamiento de Xen mostrado en una VM, y siguen pendientes la corrida criptográfica en VM y el bare metal.

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 en una VM. Volver a ejecutar la cadena con firmas asimétricas, un observador que no comparta clave con el verificador y un broker mentiroso.
• Broker comprometido (C5), la brecha más crítica. Ya cae en lógica: el observador contrafirma un COMMITTED falso, incluso de un hash nunca almacenado, y la compuerta crea a B. El experimento en VM está diseñado y pendiente, y C5 queda fuera del modelo de amenazas declarado hoy.
• 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. El caso secuencial está cerrado.
• Semántica y expiración de la evidencia. Una evidencia marcada como advisory pasa igual una verificación de la compuerta, y la expiración falla abierta. Ambas correcciones van antes de la fase siguiente.
• El dominio de control como base de confianza. Rebobinar su estado, borrar el diario o entregarle al observador un flujo falsificado (F9).
• Escala y física. Más de una celda concurrente, y la campaña en bare metal (aislamiento DMA/IOMMU, rendimiento, canales laterales), que una VM no puede medir.

La validación anidada de la arquitectura está avanzada. Faltan la corrida criptográfica en VM y el cierre del sign-off, y después una campaña de física sobre hardware.

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 están planificados, no construidos. 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 pendiente corresponde a un experimento, un presupuesto de máquinas, un criterio de falsación y un 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 anidados no son física. Todo aquí es anidado, n=1, hasta la campaña en bare 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 has not been shown to be reproducible. Nobody has built it twice and compared the results.
• Our kernel does not carry Xen dom0 support yet, so the packaged hypervisor cannot run on it.

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.
• No se ha demostrado que el kernel sea reproducible. Nadie lo ha compilado dos veces para comparar.
• Nuestro kernel aún no trae soporte dom0 de Xen, así que el hipervisor empaquetado no puede correr sobre él.

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.
• kswup. The signed, snapshot-and-rollback updater, once it exists (design only).
• 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.
• kswup. El actualizador firmado, con snapshot y reversión, cuando exista (hoy, solo diseño).
• 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 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 when much of the industry did not yet use the word cybersecurity. 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.

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.

We are a small team of motivated professionals and we treat evidence as the final judge: every claim carries where it was proven, 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 next step is a proof of concept that can stand up to a serious frontier agent attacking it, shipped with a trimmed, hardened kernel and Xen hypervisor and an untouched baseline to measure against. 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, 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 cuando gran parte de la industria aún no usaba la palabra ciberseguridad. 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.

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.

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.

El siguiente paso es una prueba de concepto capaz de resistir a un agente de frontera serio que la ataque, entregada con un kernel y un hipervisor Xen recortados y endurecidos y una línea base intacta contra la cual medir. Puede no cumplirse, y informaremos 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.