DEV Community: Fenix

Open Source. Código Abierto.

Fenix — Thu, 23 Jul 2026 14:10:07 +0000

La dependencia del sistema mundial actual del código abierto es prácticamente absoluta. No se trata de una alternativa opcional, sino del cimiento invisible sobre el que opera la economía global.

Las Tasas de Dependencia Clave.

La dependencia se mide a través de métricas extraídas de auditorías de ciberseguridad e investigaciones globales:

96% de las bases de código comercial del mundo contienen componentes de código abierto. Esto abarca desde el software de tu banco hasta los sistemas de aviación y plataformas médicas.

77% del volumen total de código en las aplicaciones modernas promedio está compuesto estrictamente por librerías open source. El software comercial actual es, en realidad, un cascarón propietario construido encima de un enorme bloque comunitario.

70% a 90% de la infraestructura en la nube global (servidores de AWS, Google Cloud, Microsoft Azure) corre sobre Linux y herramientas de orquestación de código abierto, la espina dorsal de internet.

El Valor Económico de esta Dependencia.

Un estudio histórico de la Harvard Business School estimó el impacto financiero global si el código abierto dejara de existir repentinamente:

$8.8 billones de dólares ($8.8 Trillion en inglés) es el valor de reemplazo de la demanda del open source. Si todas las empresas del planeta tuvieran que reescribir desde cero ese código comunitario para mantener sus negocios en marcha, el coste global ascendería a esa cifra.

Las empresas tendrían que multiplicar por 3.5 veces su presupuesto de TI actual para sostener sus operaciones sin la existencia de este ecosistema gratuito.

La Paradoja de la Fragilidad Mundial.

El sistema es tan dependiente que la seguridad global descansa en muy pocas manos. El mismo estudio de Harvard descubrió que el 96% del valor económico total del código abierto es mantenido por apenas el 5% de los desarrolladores.

Muchos de estos componentes críticos que sostienen la banca, las telecomunicaciones y la energía global dependen del mantenimiento voluntario de pequeños grupos de personas, lo que genera riesgos estructurales ante ataques de inyección de código o agotamiento informático.

Teniendo en cuenta que el código abierto sostiene casi el 80% de las aplicaciones comerciales, ¿te interesa saber qué mecanismos de auditoría (como las regulaciones SBOM) están implementando los gobiernos para proteger esta infraestructura crítica?

Archivos Predator. Anmistia Internacional.

Fenix — Thu, 23 Jul 2026 10:15:33 +0000

Global: El escándalo de los ‘Archivos Predator’ revela ataques descarados con software espía contra la sociedad civil, figuras políticas y altos cargos.

https://www.amnesty.org/es/latest/news/2023/10/global-predator-files-spyware-scandal-reveals-brazen-targeting-of-civil-society-politicians-and-officials/

Una vez más, tenemos pruebas de que se están usando potentes herramientas de vigilancia en ataques descarados. En esta ocasión, los objetivos son periodistas en el exilio, figuras públicas y funcionarios y funcionarias intergubernamentales. Pero no nos equivoquemos: las víctimas somos toda la población, nuestras sociedades, la buena gobernanza y los derechos humanos de todas las personas.
Agnès Callamard, secretaria general de Amnistía Internacional.

Fortalecimiento de Agentes de IA en Producción: Arquitectura de Defensa

Fenix — Wed, 22 Jul 2026 14:19:21 +0000

Fortalecimiento de Agentes de IA en Producción: Una Arquitectura Completa de Defensa en Profundidad para Implementaciones Corporativas y Científicas

Introducción

El panorama actual del despliegue de IA en entornos corporativos y científicos es similar a navegar por un campo minado. Las empresas están desplegando cada vez más agentes de IA autónomos sin protecciones adecuadas en tiempo de ejecución, exponiéndose a una miríada de vulnerabilidades y fallos lógicos. Este artículo tiene como objetivo abordar estos problemas críticos al introducir un ecosistema completo de 46 repositorios de GitHub diseñados para fortalecer agentes de IA en entornos de producción.

La Arquitectura de Tres Capas (Runtime & Orquestación)

Hermes Crew Hybrid

El repositorio hermes-crew-hybrid propone un modelo soberano con micro-tripulaciones de CrewAI aisladas en contenedores Docker. Esta arquitectura asegura que cada agente de IA opere dentro de un entorno seguro y controlado, minimizando el riesgo de contaminación cruzada y acceso no autorizado.

Agent Shield Runtime

El repositorio agent-shield-runtime incluye cinco sensores esenciales:

scope-lib: Asegura que los agentes de IA operen dentro de su alcance definido.
adi-shield: Proporciona una capa adicional de seguridad contra ataques adversarios.
wallet-guard: Protege contra vulnerabilidades financieras como ataques de Denegación de Wallet.
goal-anchor: Asegura que los agentes de IA permanezcan alineados con sus objetivos previstos.
trajectory-sentinel: Monitorea la trayectoria de los agentes de IA para detectar y prevenir cualquier desviación de su camino previsto.

Fortalecimiento y Validación en Ciencias Duras e Industria Crítica

Nuestra suite no es solo software común; incluye capas de validación científica ultra-estrictas y soluciones CPU-only para bioinformática, ciencia de materiales y astronomía. Herramientas clave incluyen:

astrocp: Para el procesamiento de datos astronómicos.
ssb-validate: Para la validación de enlaces de hebra única.
qchem-leak-screen: Para la detección de fugas en química cuántica.
rnvalidate: Para la validación de ARN.
cryoval: Para la validación criogénica.
EnzyOrchestra: Para la orquestación enzimática.
dock-confidence: Para la validación de confianza en el acoplamiento.

Auditoría, Privacidad y Proxies (MCP & PII)

MCP Core Defense

El repositorio mcp-core-defense ofrece un proxy de siete fases contra el envenenamiento de herramientas, asegurando que todas las herramientas utilizadas por los agentes de IA sean seguras y estén libres de código malicioso.

Corpus Scrub

El repositorio corpus-scrub proporciona la redacción local de Información de Identificación Personal (PII), asegurando que todos los datos sensibles sean manejados y protegidos de manera segura.

Modelo de Licencia Comercial y Consultoría a Medida

Todo el ecosistema está disponible bajo la estricta licencia de código abierto AGPL-3.0, que protege el software y asegura su integridad. Para empresas que requieren:

Licencias comerciales privadas para cerrar el código e integrarlo sin restricciones de copyleft.
Consultoría experta y servicios de fortalecimiento para arquitecturas Docker y diseño de gateways seguros.

Por favor, contáctenos directamente a través de correo amurlaniakea@gmail.com para consultas comerciales.

Conclusión

https://github.com/amurlaniakea

En conclusión, nuestro ecosistema de 46 repositorios de amurlaniakea en GitHub ofrece una solución completa para el fortalecimiento de agentes de IA en entornos de producción. Al aprovechar nuestras herramientas y arquitecturas avanzadas, las empresas pueden asegurar la seguridad, integridad y confiabilidad de sus implementaciones de IA.

P.D. Y lo voy a dejar aqui porque son tantisimos los agujeros de seguridad que generan los agentes IA y las tecnologias IAs que sencillamente no es solo una persona o un canal de github quien lo va a solucionar, ni con un manojo de repos. Es una labor colectiva del open source y de empresas, desarrolladores, programadoras y todo el sector de investigacion, innovacion y desarrollo y heuristica quien podria solucionarlo. Gracias. Aloha. Atte. MagoPredator.

agent-shield-runtime v0.1.0: hook de despliegue que conecta 5 sensores de defensa de agentes IA

Fenix — Mon, 20 Jul 2026 09:22:55 +0000

agent-shield-runtime v0.1.0: hook de despliegue que conecta 5 sensores de defensa de agentes IA

Los sensores de defensa de un agente no sirven si nada los invoca. Este repo intercepta cada tool-call y lo evalúa contra 5 sensores antes de ejecutarlo.

El problema

En el ecosistema de defensa de agentes IA (scope-lib, adi-shield, wallet-guard, goal-anchor, trajectory-sentinel) los 5 sensores están implementados y auditados. Pero son librerías: nadie los invoca en un agente real. Con los paquetes instalados y sin un hook, el agente ejecuta sus tool-calls directos y los sensores se quedan en disco. La detección que demostramos en tests unitarios no ocurre en producción.

La solución

agent-shield-runtime es el sexto repositorio: un hook de despliegue que intercepta cada tool-call del agente y lo despacha a los 5 sensores en orden, antes de ejecutarlo:

scope-lib — evaluación de alcance (3 criterios, fail-safe).
adi-shield — detección de inyección de prompt (ADI) en 5 vectores.
wallet-guard — guardrails de bucle y presupuesto.
goal-anchor — integridad de objetivo (deriva brusca).
trajectory-sentinel — correlación agregada de señales vía bus compartido.

Si cualquier sensor dice block, la acción NO se ejecuta. Si hay confirm, se pausa a humano. Solo si todos dicen allow se ejecuta el tool nativo.

Cómo funciona

El runtime envuelve el executor del agente. El núcleo solo conoce GenericToolCall; los adaptadores de framework (LangChain, AutoGen, loop propio) traducen el tool-call nativo a ese formato y viven aislados. Así el runtime es reutilizable sin acoplarse a ningún agente concreto, y los 5 sensores no cambian: este repo solo orquesta.

Resultados verificados

5 tests de integración end-to-end (tests/test_integration_e2e.py) contra los 5 sensores REALES instalados (sin mocks de sensor): AC1 (deny bloquea y no ejecuta), AC2 (inyección ADI bloquea), AC3 (deriva brusca confirma), AC5 (integración sin modificar los sensores).
CI verde en GitHub Actions (ruff + pytest + bandit + gitleaks) en entorno limpio.
Licencia AGPL-3.0-or-later (texto oficial FSF verbatim).

Lo que queda abierto (honestamente)

WebTrap sutil no se cierra. El hook extiende la cobertura de despliegue, no la de detección. Los vectores de deriva sutil que preservan apariencia de alcance (T1/T2/T4) siguen sin detectarse en la Capa 1 de goal-anchor (benchmark corregido: TPR=0.25 real, FPR=0.0). Cerrarlos requiere semántica real, descartada por peso en esta fase.
Adaptador de framework real pendiente. Hoy solo el adaptador genérico; el cableado al executor nativo de LangChain/AutoGen es el siguiente hito (H3).
Auditoría independiente en curso. El repo se hizo público para que un auditor externo lo clone y verifique en fresco.

Pruébalo

git clone https://github.com/amurlaniakea/agent-shield-runtime.git
cd agent-shield-runtime
python -m venv .venv && . .venv/bin/activate
pip install -e .
pytest

Stack

Componente	Rol
ShieldRuntime	intercepta y decide block/confirm/allow
GenericToolCall	formato interno neutro
LocalSignalBus	bus compartido de señales
los 5 sensores	evaluación por especialidad

trajectory-sentinel v0.1.0: correlación de señales de defensa de agentes

Fenix — Sun, 19 Jul 2026 20:53:19 +0000

trajectory-sentinel v0.1.0: correlación de señales de defensa de agentes

Monitor que junta las señales de adi-shield, wallet-guard y
goal-anchor y detecta ataques que un solo sensor no ve.

El problema

Cada sensor ve una parte. Un atacante puede pasar por uno que dice "allow" si
otro ve deriva. Hace falta una capa que correlacione las señales y decida por
la trayectoria completa, no por cada tool-call aislado.

Qué hace

trajectory-sentinel expone TrajectorySentinel y correlate(). Reglas
deterministas (0-LLM):

block/kill de cualquier sensor corta.
goal-anchor ve deriva mientras los demás dicen allow → confirma riesgo.
goal-anchor emite drift_retract (ampliación humana tardía) → revisa el veredicto a allow, sin congelarse ni ocultar la alerta previa.
≥2 sensores en confirm → confirm agregado.

Cómo funciona

from trajectory_sentinel.monitor import TrajectorySentinel
from adi_shield.bus import LocalSignalBus
bus = LocalSignalBus()
sentinel = TrajectorySentinel(bus)
bus.publish(signal)            # Signal de cualquier sensor
rec = sentinel.report(task_id="t1")
print(rec.to_dict()["correlated"]["verdict"])

El bus real (LocalSignalBus) se usa en los tests E2E; la integración con
goal-anchor está verificada de punta a punta.

Resultados de la auditoría

13 tests en trajectory-sentinel, todos verdes; ruff limpio.
Auditado en clone fresco (rama main, commit 35c02e2).

Limitaciones (honestamente)

La retractación es por tarea completa, no por sub-objetivo: si dos
sub-objetivos derivan y solo uno se retracta, la tarea baja a allow entera.
Está documentado en el README. El sistema no está desplegado como middleware de
un agente real.

Pruébalo

git clone --branch main https://github.com/amurlaniakea/trajectory-sentinel.git
cd trajectory-sentinel && python -m venv .venv && . .venv/bin/activate
pip install -e . && pip install -e ../adi-shield && pip install -e ../goal-anchor
pytest tests/ -v

goal-anchor v0.1.0: integridad de objetivo para agentes multi-paso

Fenix — Sun, 19 Jul 2026 20:53:16 +0000

goal-anchor v0.1.0: integridad de objetivo para agentes multi-paso

Sensor contra Agent Goal Hijack: detecta desviación del objetivo acordado,
con ancla confirmada por humano y ampliación autorizada en medio del paso.

El problema

En tareas largas, un atacante puede redirigir al agente hacia un objetivo
distinto manteniendo apariencia de éxito (WebTrap). Hace falta una referencia
de objetivo que el humano confirma y que el agente no puede reescribir solo.

Qué hace

goal-anchor expone GoalAnchor, AnchorProposal y DriftMonitor.

Capa 1 (estructural, 0-LLM): señal acumulada de hitos reclamados fuera del ancla. Detecta deriva brusca (caso T3 del corpus).
Capa 2 (semántica): interfaz pluggable de embedder. El stub por defecto no es operacional a propósito — documentado como gap conocido.
confirm_amplification(): ampliación tardía validada (el ancla debe estar confirmada primero) que retrata cicatrices sin borrar el rastro.

Cómo funciona

from goal_anchor.anchor import GoalAnchor, AnchorProposal
ga = GoalAnchor("store.json", human_secret="h")
a = ga.propose(AnchorProposal("t1", "precios de vuelos a Madrid",
                              ["research_prices"]))
ga.confirm(a)                      # ancla fijada por humano
sig = ga.report_drift("t1", "iii_transitive", "otra_cosa")
print(sig.soft_score)              # 0.0..1.0, determinista

Resultados de la auditoría

18 tests en goal-anchor, todos verdes; ruff limpio.
Auditado en clone fresco (rama main, commit 7b10ce2).

Limitaciones (honestamente)

La Capa 2 no cierra el vector WebTrap sutil (T1/T2/T4): redirecciones con
texto lexicalmente ortogonal al ancla. Lo verifiqué contra el corpus — ninguna
técnica léxica sin modelo (n-gramas, TF-IDF, edición) da señal sobre 0.00 ahí.
Quedó como gap documentado, no maquillado. El hook de ejecución real no está
desplegado.

Pruébalo

git clone --branch main https://github.com/amurlaniakea/goal-anchor.git
cd goal-anchor && python -m venv .venv && . .venv/bin/activate
pip install -e .
pytest tests/ -v

wallet-guard v0.1.0: guardrails de bucle y presupuesto para agentes

Fenix — Sun, 19 Jul 2026 20:53:13 +0000

wallet-guard v0.1.0: guardrails de bucle y presupuesto para agentes

Sensor que corta bucles de reintento sin progreso y fuerza límites de
gasto, sin bloquear permanentemente por una confirmación legítima.

El problema

Un agente puede quedarse en un bucle de reintentos que nunca avanza, o gastar
más de lo autorizado. El riesgo opuesto es el bloqueo permanente: si una simple
petición de confirmación del usuario se trata como error, el agente se para
para siempre.

Qué hace

wallet-guard expone LoopGuard y un presupuesto. Dos comportamientos
verificados por tests:

Corte de bucle: si N reintentos no producen progreso medible, detiene.
Presupuesto: respeta un límite de gasto/configuración.
No bloqueo por confirmación: una petición de confirmación del usuario no cuenta como fallo irreversible (bug encontrado y corregido en auditoría).

Cómo funciona

from wallet_guard.guard import LoopGuard
guard = LoopGuard(max_retries=3, progress_fn=lambda s: s.done)
guard.observe(state)          # registra intento
if guard.should_stop():
    print("bucle sin progreso: cortado")

Resultados de la auditoría

8 tests en wallet-guard, todos verdes; ruff limpio.
Auditado en clone fresco (rama main, commit 372b2a9).

Limitaciones (honestamente)

El progreso se mide con un predicado que el integrador debe definir; el paquete
no infiere "progreso" por sí solo. No está enganchado aún como middleware de un
agente en producción.

Pruébalo

git clone --branch main https://github.com/amurlaniakea/wallet-guard.git
cd wallet-guard && python -m venv .venv && . .venv/bin/activate
pip install -e .
pytest tests/ -v

adi-shield v0.1.0: detección de inyección de prompt en 5 vectores

Fenix — Sun, 19 Jul 2026 20:53:10 +0000

adi-shield v0.1.0: detección de inyección de prompt en 5 vectores

Sensor de defensa que marca datos no confiables y detecta instrucciones
inyectadas antes de que el agente las ejecute, sin depender del modelo.

El problema

La inyección de prompt (CWE-1427) es el vector principal contra agentes:
instrucciones embebidas en un email, una página web, un ticket o un repo que
el agente trata como mandato propio. Detectarlo requiere marcar el origen de
cada dato, no pedirle al LLM que se autodefenda.

Qué hace

adi-shield expone InjectionShield y evaluate(). Cubre cinco vectores
motivados por el paper que origina el proyecto:

Vector	Origen del dato
email	mensaje entrante
web	contenido scrapeado
ticket	issue/tarea externa
repo	código de terceros
calendar	invitación de agenda

Cuando el dato viene marcado como no confiable y contiene instrucciones de
acción, evaluate devuelve un veredicto de inyección. Distingue eso de un
reenvío legítimo ya autorizado por el usuario.

Cómo funciona

from adi_shield.shield import InjectionShield
shield = InjectionShield()
verdict = shield.evaluate(data="haz esto ahora", source="web",
                          trusted=False)
print(verdict.injection)   # True/False, determinista

El bus de señales (adi_shield.bus.Signal) es la interfaz que trajectory-sentinel
consume.

Resultados de la auditoría

10 tests en adi-shield, todos verdes; ruff limpio.
Auditado en clone fresco (rama main, commit c125db4).

Limitaciones (honestamente)

Es detección de instrucciones embebidas en datos marcados, no un clasificador
semántico profundo. El hook real delante de un agente (llamar evaluate()
antes de cada tool-call) no está desplegado todavía; las pruebas usan fixtures.

Pruébalo

git clone --branch main https://github.com/amurlaniakea/adi-shield.git
cd adi-shield && python -m venv .venv && . .venv/bin/activate
pip install -e .
pytest tests/ -v

scope-lib v0.1.0: evaluación de alcance para agentes de IA en 3 criterios

Fenix — Sun, 19 Jul 2026 20:53:07 +0000

scope-lib v0.1.0: evaluación de alcance para agentes de IA en 3 criterios

Capa base de un sistema de defensa para agentes LLM. Decide si una acción
está dentro del alcance autorizado antes de ejecutarla, con fail-safe
determinista.

El problema

Un agente autónomo recibe una tarea y ejecuta tool-calls. Sin una frontera de
alcance, cualquier dato no confiable (un email, una web) puede desviarlo hacia
acciones fuera de lo acordado. Hace falta un punto de decisión explícito y
revisable, no enterrado en el prompt.

Qué hace

scope-lib expone PolicyStore y load_policy_store, y evalúa cada acción
contra tres criterios (ScopeVerdict.criterion):

i_subobjective — la acción sirve a un sub-objetivo del ancla.
ii_resource — usa recursos declarados (no laterales).
iii_transitive — el apoyo entre sub-objetivos es transitivo y acotado.

El fallo por defecto es deny: si no hay ancla confirmada, nunca se permite.
Eso es el fail-safe "sin ancla = nunca allow".

Cómo funciona

from scope_lib import load_policy_store, ScopeVerdict
store = load_policy_store("policy.json")
v = ScopeVerdict(store, task_id="t1")
verdict = v.check(criterion="i_subobjective", claimed="research_prices")
print(verdict.allowed)   # True/False, determinista

El store se versiona y persiste; goal-anchor y adi-shield lo reutilizan.

Resultados de la auditoría

10 tests en scope-lib, todos verdes; ruff limpio.
Auditado de forma independiente en clone fresco público (rama main, commit 83b626f).

Limitaciones (honestamente)

scope-lib es la capa de decisión, no el runtime que la invoca. Nadie ha
enganchado todavía este paquete como middleware delante de un agente real;
las pruebas son contra fixtures sintéticos, no tráfico de producción.

Pruébalo

git clone --branch main https://github.com/amurlaniakea/scope-lib.git
cd scope-lib && python -m venv .venv && . .venv/bin/activate
pip install -e .
pytest tests/ -v

variant-confidence v0.1.0: a calibrated confidence layer for variant-effect pathogenicity scores

Fenix — Sat, 18 Jul 2026 03:30:30 +0000

variant-confidence v0.1.0: a calibrated confidence layer for variant-effect pathogenicity scores

State-of-the-art variant-effect models are accurate in cross-validation but their scores are poorly calibrated on temporal data. variant-confidence adds an auditable calibration layer on top of existing predictors — it does not train a new model.

The problem: accuracy is not trust

Protein variant-effect predictors (AlphaMissense, ESM-1v, EVE) report pathogenicity scores, but a clinician or researcher needs to know how much to trust the number, not just its rank. The gap is calibration, not accuracy:

AnnotateMissense (2026) reports MCC 0.94 in cross-validation, dropping to 0.76 on temporal ClinVar, accuracy 0.8798.
A raw score near 0.9 may not mean 90% probability. Acting on an uncalibrated score is a risk.

What it does

variant-confidence wraps an existing predictor's score and produces a calibrated, uncertainty-aware output:

Probability calibration (AC1): Platt scaling or isotonic regression over a separate holdout. Selectable, not hardcoded.
Conformal prediction (AC1b): coverage 1−α intervals, split or Mondrian by gene.
ECE (AC2, AC9): Expected Calibration Error reported before/after calibration, with bootstrap CI and per-bin counts. Bins with too few samples are flagged as low-reliability.
Leakage-free split (AC3): temporal split by ClinVar release date with gene isolation — the same gene never appears in both train and test. This is unit-tested.
Missing-score handling (AC4): works with AlphaMissense or ESM-1v alone; emits an explicit warning instead of failing silently.
Non-deceptive reporting (AC7): every result includes interval/ECE + method + threshold, never a bare calibrated score.

Verification (clean clone, no network)

Built under a three-party governance loop: implement → independent audit in a clean clone → merge approval.

ruff check . → All checks passed.
pytest tests/ → 28 passed in 8.90s (offline fixture).

An honest bug we caught in audit

The first ECE test reported a "perfect" drop from raw ECE 0.4275 to ~0 after calibration. The audit found this was degenerate: the synthetic score generator ignored the real labels and produced an independent random true_p, so the calibrator simply collapsed to the base rate (91.5% pathogenic) — ECE≈0 by construction, not by merit. AUC of the raw score vs real labels was 0.51.

The fix derives true_p from the real label with noise, so the synthetic score is genuinely discriminative but miscalibrated. The acceptance criterion is now: ECE drops and AUC is preserved after calibration. This is in the committed code and the 28 passing tests.

What remains open (honestly)

AlphaMissense license ambiguity: the official README says CC BY 4.0, but the distributed TSV header, Ensembl VEP plugin, and EBI page state CC BY-NC-SA 4.0. The contradiction is unresolved; treat the data as restricted (non-commercial) until clarified. The software is AGPL-3.0-or-later and fully self-contained.
The end-to-end join with real AlphaMissense scores is implemented, but the flagship path is covered by an offline fixture, not a live download in CI.

Try it

pip install variant-confidence
variant-confidence --method platt --offline

Stack

Python >=3.10, numpy, pandas, scikit-learn
AGPL-3.0-or-later

astrocp: Conformal Prediction con cobertura condicional por clase para astronomía

Fenix — Fri, 17 Jul 2026 21:02:54 +0000

astrocp: Conformal Prediction con cobertura condicional por clase para astronomía

Una librería pequeña (AD-MCP) que da conjuntos de predicción con cobertura
por cada clase en datasets astronómicos con clases raras — y el registro
honesto de cómo pasó de "funciona" a "funciona y está verificado".

El problema

En sondeos astronómicos (PLAsTiCC, SDSS) las clases raras —supernovas
poco frecuentes, quasars raros— conviven con clases mayoritarias. Un
clasificador bien calibrado puede dar una cobertura marginal del 90% y,
aun así, dejar a la clase rara en un 40%. La cobertura marginal engaña:
oculta que el modelo falla justo donde importa.

Conformal Prediction (CP) controla la cobertura con garantía de muestra
finita. Pero la variante estándar (un solo cuantil global) repite el mismo
defecto: protege el promedio, no a cada clase.

Qué existe ya (y qué no)

La predicción conformista sí se ha aplicado a astronomía:
Giertych, Williams & Ghosh (2024) — "Conformal Prediction for Astronomy
Data with Measurement Error" construye
intervalos de predicción para regresión con error de medición
heterocedástico (masas de exoplanetas).

El gap que astrocp aborda es distinto y más estrecho:

No existe una librería mantenida de Conformal Prediction para
clasificación multi-clase con incertidumbre condicional por clase en
astronomía — es decir, que controle la cobertura de cada clase
(incluidas las raras) por separado, no solo la marginal.

AD-MCP es clasificación multi-clase con estratificación Mondrian por
anomaly score; el paper de 2024 es regresión. No se solapan.

Cómo funciona AD-MCP

ADMCP combina dos piezas sobre MAPIE 1.4.1:

Un modelo base global (RandomForest).
Cuantiles de conformidad RAPS por bin del anomaly score (IsolationForest), en vez de un único cuantil global. Cada punto usa el cuantil de su estrato de anomalía.

El conjunto de predicción = { clases c : score_c <= q_estrato }.

El cuantil se fija por validación cruzada (select_lambda), no a ojo.

El guardrail que el método necesitaba

Con clases de 16-30 muestras en calibración, repartidas en varios estratos,
el cuantil por estrato es ruido puro: ninguna estratificación (por
anomaly o por cualquier otra variable) es viable por falta de señal. No es
fallo del método, es falta de datos.

Por eso ADMCP marca las clases con menos de n_min_class muestras en
calibración como inviable y delega a un cuantil global para ellas. El
paquete avisa cuándo no debe estratificar, en vez de ocultar la
limitación.

Resultados (sin inflar)

AD-MCP mejora la cobertura condicional relativa vs baseline en régimen favorable (SDSS; PLAsTiCC con features pobres).
Con features ricas, el baseline de conformalización global puede superar a AD-MCP en la peor clase: el límite real no es de "régimen de anomaly" sino de muestras mínimas por clase.
lambda_reg se fija por CV con un criterio compuesto, no a dedo.

La comparación que importa es relativa (AD-MCP vs baseline, mismo
dataset, mismo modelo), no contra un umbral absoluto que se haya movido en
el camino.

Cómo se verificó (la parte que importa)

El repo no se fusionó a main porque "Hermes dijo que pasaba". Pasó por
auditoría ciega desde clone limpio:

Clone en directorio nuevo, .venv nuevo, 27 dependencias desde cero.
pytest → 11 passed, 2 failed. Los 2 fallidos son el criterio de aceptación original, preservado a propósito en rojo porque se relajó tras ver los datos (trazabilidad de los postes movidos, no borrar el test que falla).
La auditoría encontró y corrigió 3 bugs de reproducibilidad que el entorno local ocultaba: dependencia astroML no declarada, datos en .gitignore, y un cache de features que no codificaba el tamaño de muestra.
El autor (Sil) reprodujo el clone limpio por su cuenta: mismo resultado.

Esto es la prueba de calidad, no un adjetivo.

Pruébalo

git clone https://github.com/amurlaniakea/astrocp.git
cd astrocp && python3 -m venv .venv && source .venv/bin/activate
pip install -e ".[test]"
pytest   # esperado: 11 passed, 2 failed (test_coverage_red.py rojo a propósito)

Stack

Componente	Rol
MAPIE 1.4.1	Conformal Prediction base (RAPS)
scikit-learn	RandomForest, IsolationForest
astroML	Carga de SDSS (local, sin red)
PLAsTiCC	Lightcurves de supernova (Zenodo)

corpus-scrub 0.1.0: detecta y redacta PII y secretos en corpus de entrenamiento antes del entrenamiento LLM

Fenix — Fri, 17 Jul 2026 01:21:29 +0000

corpus-scrub 0.1.0: detecta y redacta PII y secretos en corpus de entrenamiento antes del entrenamiento

Los modelos memorizan y filtran lo que hay en los datos de entrenamiento. corpus-scrub los limpia antes de entrenar: detecta PII (email, teléfono, IBAN, tarjeta, nombres) y secretos (API keys, tokens) y los redacta localmente, sin enviar nada a ningún servicio.

El problema

Los corpus raspados de la web contienen rutinariamente datos personales y credenciales. La literatura lo deja claro:

Modelos de síntesis de imágenes que retroalimentan riesgos de privacidad amplificados en mezclas real-sintético (arXiv 2607.13541)
Memorización no intencionada de información sensible en fine-tuning (arXiv 2601.17480)
Direcciones de activación universales para fuga de PII (UniLeak) (arXiv 2602.16980)

GDPR y el art. 10 de la EU AI Act prohíben datos personales no estructurados en conjuntos de entrenamiento sin consentimiento. La solución barata es limpiar el corpus antes de entrenar.

Qué hace

corpus-scrub es una CLI local-first (AGPL-3.0-or-later) que escanea JSONL/TXT/Parquet y:

PII: Presidio (NER spaCy en_core_web_lg para PERSON) + regex propios para EMAIL / IBAN / CARD / PHONE que no dependen de modelo y funcionan en cualquier idioma.
Secretos: un ruleset de 16 reglas portadas verbatim de gitleaks (commit fijado 4c232b5), verificadas regla por regla contra el gitleaks.toml original en los tests.
Redacción: mask (<TYPE>), hash (sha256 truncado) o drop.
Reporte: JSON de auditoría con conteo por tipo y localizaciones.

Multi-idioma para nombres (ES/DE/FR) vía modelos spaCy _lg dedicados, con fallback multilingüe explícito y tests que fallan si el fallback se usa por accidente.

Cómo funciona

# Instalar
python -m venv .venv && source .venv/bin/activate
pip install -e .
# el primer run descarga spaCy en_core_web_lg (~400 MB)

# Escanear y enmascarar
corpus-scrub scan --input corpus.jsonl --policy mask --out redacted.jsonl --report report.json

# Solo inglés en el MVP; otros idiomas error explícito
corpus-scrub scan --input corpus.jsonl --lang en

Los detectores universales (email/teléfono/IBAN/tarjeta) son regex, así que no necesitan modelo y cubren cualquier idioma. El NER de PERSON usa Presidio para EN y spaCy directo para ES/DE/FR.

Limits honestos

No todo está garantizado, y está documentado:

AC-1 garantiza recall >= 0.95 para EMAIL, PERSON y CREDIT_CARD. PHONE e IBAN no están garantizados en el MVP: Presidio puntúa el teléfono bajo el umbral y el reconocedor de IBAN falla en algunos formatos EN. Es un KNOWN_ISSUE, no una sorpresa.
NER multilingüe exige los modelos _lg descargados; si faltan, los tests de precisión fallan en vez de pasar silenciosamente contra el fallback.

Auditoría y gobernanza

El ruleset de secretos pasó una auditoría regla-por-regla contra la fuente de gitleaks. Se encontró y corrigió una divergencia real: la regla pypi-upload-token usaba un comodín en vez del prefijo base64 fijo del token real, lo que generaba falsos positivos demostrados. El fix añadió un test que compara cada regla portada contra el gitleaks.toml embebido como fixture, así que futuras derivas se detectan solas.

Cobertura de tests: 82% (fast suite sin descarga de modelos; slow suite con los _lg).

Stack

Componente	Uso
Presidio + spaCy	NER PERSON (EN)
spaCy `es/de/fr_core_news_lg`	NER PERSON multilingüe
regex gitleaks	detección de secretos
pytest + CI	fast/slow suites, cobertura

Pruébalo

git clone https://github.com/amurlaniakea/corpus-scrub
cd corpus-scrub
python -m venv .venv && source .venv/bin/activate
pip install -e .
pytest -m "not slow"   # suite rápida, sin descargas

Repo: https://github.com/amurlaniakea/corpus-scrub

Licencia: AGPL-3.0-or-later. Autor: Pedro Sordo Martínez — amurlaniakea@gmail.com

DEV Community: Fenix

Open Source. Código Abierto.

Archivos Predator. Anmistia Internacional.

Fortalecimiento de Agentes de IA en Producción: Arquitectura de Defensa

Fortalecimiento de Agentes de IA en Producción: Una Arquitectura Completa de Defensa en Profundidad para Implementaciones Corporativas y Científicas

Introducción

La Arquitectura de Tres Capas (Runtime & Orquestación)

Hermes Crew Hybrid

Agent Shield Runtime

Fortalecimiento y Validación en Ciencias Duras e Industria Crítica

Auditoría, Privacidad y Proxies (MCP & PII)

MCP Core Defense

Corpus Scrub

Modelo de Licencia Comercial y Consultoría a Medida

Conclusión

agent-shield-runtime v0.1.0: hook de despliegue que conecta 5 sensores de defensa de agentes IA

agent-shield-runtime v0.1.0: hook de despliegue que conecta 5 sensores de defensa de agentes IA

El problema

La solución

Cómo funciona

Resultados verificados

Lo que queda abierto (honestamente)

Pruébalo

Stack

Links

trajectory-sentinel v0.1.0: correlación de señales de defensa de agentes

trajectory-sentinel v0.1.0: correlación de señales de defensa de agentes

El problema

Qué hace

Cómo funciona

Resultados de la auditoría

Limitaciones (honestamente)

Pruébalo

Links

goal-anchor v0.1.0: integridad de objetivo para agentes multi-paso

goal-anchor v0.1.0: integridad de objetivo para agentes multi-paso

El problema

Qué hace

Cómo funciona

Resultados de la auditoría

Limitaciones (honestamente)

Pruébalo

Links

wallet-guard v0.1.0: guardrails de bucle y presupuesto para agentes

wallet-guard v0.1.0: guardrails de bucle y presupuesto para agentes

El problema

Qué hace

Cómo funciona

Resultados de la auditoría

Limitaciones (honestamente)

Pruébalo

Links

adi-shield v0.1.0: detección de inyección de prompt en 5 vectores

adi-shield v0.1.0: detección de inyección de prompt en 5 vectores

El problema

Qué hace

Cómo funciona

Resultados de la auditoría

Limitaciones (honestamente)

Pruébalo

Links

scope-lib v0.1.0: evaluación de alcance para agentes de IA en 3 criterios

scope-lib v0.1.0: evaluación de alcance para agentes de IA en 3 criterios

El problema

Qué hace

Cómo funciona

Resultados de la auditoría

Limitaciones (honestamente)

Pruébalo

Links

variant-confidence v0.1.0: a calibrated confidence layer for variant-effect pathogenicity scores

variant-confidence v0.1.0: a calibrated confidence layer for variant-effect pathogenicity scores

The problem: accuracy is not trust

What it does

Verification (clean clone, no network)

An honest bug we caught in audit

What remains open (honestly)

Try it

Stack

Links