OWASP Agentic Security

OWASP Agentic Security Guide

Companion del AI-First Engineering Framework v6.5

1. Por Que Este Documento

Los agentes AI toman acciones, no solo generan texto. Esto amplifica la superficie de ataque: un agente comprometido puede ejecutar codigo, llamar APIs, modificar bases de datos y propagarse a otros agentes.

El OWASP Top 10 for Agentic Applications (2026) y el OWASP Top 10 for LLM Applications (2025) son los estandares de facto para seguridad en sistemas AI. Este documento mapea cada riesgo a mitigaciones concretas dentro de nuestro framework.

“AI engineering is not magic; it is distributed systems engineering with a highly unreliable component in the middle.” — Alex Ewerlof, 2026

---

2. OWASP Top 10 for Agentic Applications (ASI01-ASI10)

Tabla de Mapping: Riesgo → Framework

ID	Riesgo	Descripcion	Mitigacion en Framework	Fase(s)
ASI01	Agent Goal Hijack	Input malicioso manipula el objetivo del agente	prompt_injection_tests (quality gate) + @security_reviewer + input sanitization	F08
ASI02	Tool Misuse & Exploitation	Agente usa tool autorizado de forma destructiva	MCP tool_annotations (readOnly, destructive) + MCP security checklist + permissions en settings.json	F06, F08
ASI03	Identity & Privilege Abuse	Agentes escalan o comparten credenciales	OAuth 2.1 para MCP remoto + JIT ephemeral tokens + boundary rules (NEVER list)	F08, F09
ASI04	Supply Chain Vulnerabilities	MCP servers, skills o dependencias comprometidas	Skill audit policy (36% stat) + MCP source_code_reviewed + dependency_audit gate + AI-BOM	F08
ASI05	Unexpected Code Execution (RCE)	Agente genera y ejecuta codigo peligroso	Sandbox (hooks.sh) + code_execution_grader en sandbox aislado + no eval() policy	F06, F07
ASI06	Memory & Context Poisoning	RAG o memoria a largo plazo envenenada	Tenant isolation + data provenance tags + expire unverified memory + .claudeignore	F03, F08
ASI07	Insecure Inter-Agent Communication	Agente comprometido envia instrucciones maliciosas	Zero trust entre agents + message contract validation + escalation protocol (Level 2+)	F06, F08
ASI08	Cascading Failures	Fallo de un agente se propaga por automacion	Circuit breakers (session cost hard_limit) + escalation Level 3 + fan-out caps	F09
ASI09	Human-Agent Trust Exploitation	Agente manipula al humano para autorizar acciones riesgosas	Confidence scores en output + step-up auth fuera del chat + boundaries “Ask First”	F08
ASI10	Rogue Agents	Agente se desvía lentamente de su objetivo	Baseline de comportamiento + evals en CI (regression detection) + kill switch + monitoring	F07, F10

---

3. Detalle de Mitigaciones por Riesgo

ASI01 — Agent Goal Hijack

Amenaza: Texto oculto en emails, PDFs, o inputs del usuario que inyecta nuevas instrucciones al agente.

Mitigaciones del framework:

framework-config.yaml

quality_gates:
  security:
    prompt_injection_tests: true  # Tests automaticos de inyeccion
    secrets_scan: true
    sast: true

Acciones adicionales recomendadas:

• Implementar Semantic Firewall: un modelo secundario, aislado y altamente restringido, evalua inputs/outputs sospechosos.
• En el @security_reviewer agent, incluir check explicito de prompt injection en PRs.
• Tratar todo input externo (APIs, RAG docs, user input) como no confiable.

ASI02 — Tool Misuse & Exploitation

Amenaza: Un agente con acceso a delete_user solo necesita leer. Un prompt injection puede ejecutar la accion destructiva.

Mitigaciones del framework:

.claude/settings.json

{
  "permissions": {
    "deny": ["baseline/**"]  // Proteger framework
  },
  "hooks": {
    "PreToolUse": [{
      "matcher": "Edit",
      "hooks": [{"type": "command", "command": "echo 'Edit detected'"}]
    }]
  }
}

Checklist MCP Security (§6.2 de MCP Guide):

• tool_annotations_present: true — Marcar tools como readOnly o destructive.
• destructive_tools_guarded: true — Confirmacion humana requerida.
• permissions_minimal: true — Least privilege por tool.

ASI03 — Identity & Privilege Abuse

Amenaza: Agente hereda service account con permisos amplios (ej: admin de Salesforce cuando solo necesita leer).

Mitigaciones:

• MCP auth: OAuth 2.1 obligatorio para servers remotos.
• JIT (Just-In-Time) tokens: Generar tokens efimeros con scope minimo por operacion.
• Tratar agentes como Non-Human Identities (NHIs) — no reusar credenciales humanas.
• Boundaries en CLAUDE.md:

  ### NEVER
  - Usar credenciales con permisos de admin
  - Compartir tokens entre sesiones

ASI04 — Agentic Supply Chain

Amenaza: MCP server malicioso, skill con prompt injection, dependencia typosquatted.

Mitigaciones del framework:

• Skill audit policy (v5.1): 36% de skills de terceros contienen prompt injection (Snyk, Feb 2026).
• AI-BOM/SBOM: Documentar todas las dependencias AI del proyecto.
• MCP source review: Checklist §6.2 — source_code_reviewed: true.
• Dependency pinning: Fijar versiones de MCP servers y skills por hash.

project-config.yaml

security:
  skill_policy:
    prefer_official_catalogs: true
    audit_third_party: true
    min_privilege: true
  mcp_allowlist:
    - "context7"             # Auditado
    - "sequential-thinking"  # Auditado
    - "project-tools"        # Propio
  dependency_pinning: true

ASI05 — Unexpected Code Execution (RCE)

Amenaza: LLM genera require('child_process').execSync('rm -rf /') y el sistema lo ejecuta.

Mitigaciones:

• Nunca pasar output de LLM a eval(), exec(), o shells sin sandbox.
• code_execution_grader ejecuta en sandbox aislado (tmpdir con timeout).
• Hooks PreToolUse para detectar patrones peligrosos.
• En produccion: usar micro-VMs (Firecracker) o sandboxes WASM.

ASI06 — Memory & Context Poisoning

Amenaza: Attacker sube PDF malicioso al knowledge base → RAG lo recupera → LLM lo trata como verdad.

Mitigaciones:

• Tenant isolation: Namespace criptografico en vector DB por tenant.
• Data provenance: Tags de source en cada documento RAG (quien lo subio, cuando, verificado?).
• Expire unverified memory: TTL para datos no verificados.
• .claudeignore para excluir paths no confiables del contexto.

ASI07 — Insecure Inter-Agent Communication

Amenaza: Agent A comprometido envia instrucciones maliciosas a Agent B via message bus interno. Agent B confia porque es “interno”.

Mitigaciones:

• Zero Trust entre agentes: No confiar implicitamente en mensajes de otros agentes.
• Message contract validation: Cada agente valida el formato y la intencion del mensaje.
• Escalation protocol: Cualquier instruccion cross-domain escala a Level 2 (human decision).

# Patron: Zero Trust Inter-Agent
inter_agent_security:
  trust_model: "zero_trust"    # No "trust_internal"
  message_validation: true      # Validar schema de cada mensaje
  intent_verification: true     # Re-verificar autorizacion original del usuario
  escalation_on_mutation: true  # Escalada para acciones que mutan estado

ASI08 — Cascading Failures

Amenaza: Un fallo en Agent A se propaga a B, C, D… causando DoS financiero ($$$) o destruccion de datos.

Mitigaciones:

• Circuit breakers: SessionCostTracker con hard_limit: $50.
• Fan-out caps: Limitar numero de sub-agents simultaneos (max 5-7).
• Escalation Level 3: Full stop cuando se detecta cascada.
• Rate limiting: Limitar llamadas LLM por minuto por agente.

# Patron: Circuit Breaker para Agentes
class AgentCircuitBreaker:
    MAX_FAILURES = 3
    MAX_COST_USD = 50.0
    MAX_FAN_OUT = 5
    COOLDOWN_SECONDS = 300

    def should_trip(self) -> bool:
        return (
            self.consecutive_failures >= self.MAX_FAILURES or
            self.total_cost >= self.MAX_COST_USD or
            self.active_sub_agents >= self.MAX_FAN_OUT
        )

ASI09 — Human-Agent Trust Exploitation

Amenaza: Agente presenta informacion sesgada para que el humano autorice una accion riesgosa (authority bias).

Mitigaciones:

• Confidence scores: Mostrar nivel de confianza en cada recomendacion.
• Step-up authentication: Para acciones irreversibles, autenticacion fuera del chat.
• Boundaries “Ask First”: En CLAUDE.md, listar acciones que SIEMPRE requieren confirmacion.
• Independent verification: Para decisiones criticas, segundo agente verifica independientemente.

ASI10 — Rogue Agents

Amenaza: Agente cumple su policy pero gradualmente se desvia (objective drift).

Mitigaciones:

• Evals en CI: eval-skills.yaml detecta regression automaticamente.
• Baseline de comportamiento: Golden dataset como referencia de comportamiento esperado.
• Kill switch: Capacidad de detener cualquier agente inmediatamente.
• Monitoring continuo: Dashboards de metricas de agente (utilization, cost, error rate).
• Cleanup agents: Escaneo periodico de drift (patron OpenAI “golden principles”).

---

4. OWASP Top 10 for LLM Applications (LLM01-LLM10) — Resumen

ID	Riesgo	Mitigacion Rapida
LLM01	Prompt Injection	Semantic firewall + treat user input as untrusted
LLM02	Sensitive Info Disclosure	DLP/masking antes de enviar a LLM + no PII en prompts
LLM03	Supply Chain	AI-BOM/SBOM + pin dependencies por hash
LLM04	Data & Model Poisoning	Verificacion criptografica de datasets + zero-trust RAG
LLM05	Improper Output Handling	Nunca eval() output de LLM + sandbox execution
LLM06	Excessive Agency	Least privilege + JIT tokens + HITL
LLM07	System Prompt Leakage	Secrets fuera de prompts + secure vaults
LLM08	Vector & Embedding Weaknesses	Namespace segregation criptografica en vector DB
LLM09	Misinformation	RAG grounding + confidence scoring + cross-validation
LLM10	Unbounded Consumption	Rate limits + cost ceilings + circuit breakers

---

5. Tres Principios de Seguridad Agentica

5.1 Simplicity (Statelessness)

• Mantener llamadas LLM lo mas stateless posible.
• No dejar que agentes mantengan memoria a largo plazo sin validacion rigurosa.
• Si un agente necesita contexto, inyectarlo limpiamente por request.

5.2 Robustness (Sandboxing & Scoping)

• Tratar el LLM como un usuario hostil.
• Poner funciones agenticas detras de los mismos API Gateways, rate limiters e IAM boundaries que usarias para trafico externo.
• Least privilege everywhere: cada tool, cada agente, cada sesion.

5.3 Verifiability (Observability)

• Loguear: prompt exacto enviado, output recibido, tool selection rationale, parametros.
• Shadow Mode: agente planifica acciones pero no ejecuta sin review humano (hasta establecer confianza).
• Audit trail completo para EU AI Act (§7 de Observability Guide).

---

6. Agent Runtime Sandboxing (ASI05 Deep Dive)

El riesgo ASI05 (Unexpected Code Execution) exige mas que “no usar eval()”. En produccion, todo codigo generado o ejecutado por agentes debe correr en un sandbox aislado con multiples capas de defensa.

6.1 Modelo de Capas de Aislamiento

┌─────────────────────────────────────────────┐
│  Capa 4: Network Policy (deny-all default)  │
│  ┌───────────────────────────────────────┐  │
│  │ Capa 3: Filesystem (read-only root)   │  │
│  │ ┌───────────────────────────────────┐ │  │
│  │ │ Capa 2: Kernel (seccomp/AppArmor)│ │  │
│  │ │ ┌─────────────────────────────┐  │ │  │
│  │ │ │ Capa 1: Container/microVM   │  │ │  │
│  │ │ │    [Agent Code Execution]   │  │ │  │
│  │ │ └─────────────────────────────┘  │ │  │
│  │ └───────────────────────────────────┘ │  │
│  └───────────────────────────────────────┘  │
└─────────────────────────────────────────────┘

6.2 Implementacion por Capa

Capa 1: Container / MicroVM Isolation

docker-compose.agent-sandbox.yaml

services:
  agent-executor:
    image: agent-sandbox:latest
    security_opt:
      - no-new-privileges:true     # Evitar escalada de privilegios
      - seccomp:seccomp-agent.json # Perfil seccomp restrictivo
    cap_drop:
      - ALL                         # Eliminar TODAS las capabilities
    cap_add:
      - NET_BIND_SERVICE            # Solo si necesita red (raro)
    read_only: true                 # Filesystem read-only
    tmpfs:
      - /tmp:size=100M,noexec       # tmpfs sin ejecucion, 100MB max
    mem_limit: 512m                 # Limite de memoria
    cpus: 0.5                       # Limite de CPU
    pids_limit: 50                  # Limite de procesos
    networks:
      - agent-sandbox-net           # Red aislada
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: '0.5'

Alternativa para aislamiento fuerte (entornos de alta seguridad):

• gVisor (runsc): Intercepta syscalls del container — defense-in-depth contra kernel exploits.
• Firecracker microVMs: Cada agente en su propia microVM (~125ms boot). Usado por AWS Lambda.
• WASM sandboxes: Wasmtime/Wasmer para ejecucion de codigo generado sin acceso al sistema.

/etc/docker/daemon.json

# Uso de gVisor como runtime alternativo
{
  "runtimes": {
    "runsc": {
      "path": "/usr/bin/runsc",
      "runtimeArgs": ["--network=none", "--file-access=rdonly"]
    }
  }
}

Capa 2: Kernel Security (seccomp & AppArmor)

// seccomp-agent.json — Perfil restrictivo para agentes
{
  "defaultAction": "SCMP_ACT_ERRNO",
  "syscalls": [
    {
      "names": [
        "read", "write", "close", "fstat", "lseek",
        "mmap", "mprotect", "munmap", "brk",
        "rt_sigaction", "rt_sigprocmask",
        "access", "pipe", "select", "dup2",
        "getpid", "getuid", "getgid",
        "clock_gettime", "nanosleep",
        "exit_group", "exit"
      ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}
// BLOQUEADO: execve, fork, clone, ptrace, mount, socket (si no necesita red)

Capa 3: Filesystem Restrictions

# Montar filesystem read-only con tmpfs writable limitado
# Solo /tmp es writable, sin ejecucion
mount -o remount,ro /
mount -t tmpfs -o size=100M,noexec,nosuid tmpfs /tmp

# Alternativamente con Docker volumes
docker run --read-only \
  --tmpfs /tmp:size=100M,noexec,nosuid \
  --tmpfs /var/tmp:size=50M,noexec,nosuid \
  agent-sandbox:latest

Capa 4: Network Policies

# Kubernetes NetworkPolicy para agentes
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-sandbox-policy
spec:
  podSelector:
    matchLabels:
      role: agent-executor
  policyTypes:
    - Ingress
    - Egress
  egress:
    # Solo permitir acceso al API del LLM
    - to:
        - namespaceSelector:
            matchLabels:
              name: llm-gateway
      ports:
        - port: 443
          protocol: TCP
    # DNS (requerido)
    - to: []
      ports:
        - port: 53
          protocol: UDP
  ingress: []  # Sin ingress — agentes no reciben trafico directo

6.3 Timeouts y Resource Limits

# Patron: Sandbox Executor con timeouts
import subprocess
import resource
import os

class SandboxExecutor:
    """Ejecuta codigo generado por agente en sandbox aislado"""

    MAX_EXECUTION_TIME_SEC = 30
    MAX_MEMORY_BYTES = 256 * 1024 * 1024  # 256MB
    MAX_OUTPUT_BYTES = 1024 * 1024          # 1MB
    MAX_FILE_SIZE_BYTES = 10 * 1024 * 1024  # 10MB

    def _set_limits(self):
        """Limites de recursos para el proceso hijo"""
        resource.setrlimit(resource.RLIMIT_CPU, (self.MAX_EXECUTION_TIME_SEC, self.MAX_EXECUTION_TIME_SEC))
        resource.setrlimit(resource.RLIMIT_AS, (self.MAX_MEMORY_BYTES, self.MAX_MEMORY_BYTES))
        resource.setrlimit(resource.RLIMIT_FSIZE, (self.MAX_FILE_SIZE_BYTES, self.MAX_FILE_SIZE_BYTES))
        resource.setrlimit(resource.RLIMIT_NPROC, (10, 10))  # Max 10 procesos

    def execute(self, code: str, language: str = "python") -> dict:
        try:
            result = subprocess.run(
                [language, "-c", code],
                capture_output=True,
                timeout=self.MAX_EXECUTION_TIME_SEC,
                preexec_fn=self._set_limits,
                cwd="/tmp/sandbox",
                env={"PATH": "/usr/bin", "HOME": "/tmp"},  # Env minimo
            )
            return {
                "success": result.returncode == 0,
                "stdout": result.stdout[:self.MAX_OUTPUT_BYTES].decode(),
                "stderr": result.stderr[:self.MAX_OUTPUT_BYTES].decode(),
            }
        except subprocess.TimeoutExpired:
            return {"success": False, "error": "TIMEOUT", "stderr": "Execution exceeded time limit"}
        except Exception as e:
            return {"success": False, "error": "SANDBOX_ERROR", "stderr": str(e)}

6.4 Decision Tree: Nivel de Sandboxing por Track

Track	Nivel recomendado	Implementacion
Solo	Basico	Docker --read-only + timeouts + resource limits
Lean	Medio	Docker + seccomp + network policies + tmpfs
Full	Alto	gVisor/Firecracker + seccomp + AppArmor + NetworkPolicy + audit logging

---

7. Agent Identity & Non-Human Identity (NHI) Management

Los agentes AI son Non-Human Identities (NHIs) — entidades que actuan en sistemas sin ser personas. Cada agente necesita su propia identidad con governance, lifecycle, y audit trail. Reusar credenciales humanas o service accounts compartidos es un anti-patron critico (OWASP ASI03 + ASI06).

7.1 Principios de Agent Identity

1. Un agente = una identidad: Nunca compartir credenciales entre agentes.
2. Least privilege por tool: Cada identidad solo tiene acceso a los tools que necesita.
3. Short-lived tokens (JIT): Tokens efimeros por operacion, no tokens de larga duracion.
4. Audit trail completo: Cada accion vinculada a un agent_id + session_id + user_id.
5. Credential rotation: Rotacion automatica de secretos con zero-downtime.

7.2 Arquitectura de Agent Identity

┌──────────────────────────────────────────────────────────┐
│                   Identity Provider (IdP)                 │
│  (Vault / AWS IAM / Azure Entra / Google Workload ID)    │
└─────────┬──────────────────────────────────┬─────────────┘
          │ Short-lived token (5min)         │ Short-lived token
          ▼                                  ▼
┌──────────────────┐             ┌──────────────────┐
│   @architect     │             │  @security_rev   │
│   agent_id: AG01 │             │  agent_id: AG03  │
│   scope: read    │             │  scope: read     │
│   tools: [plan,  │             │  tools: [scan,   │
│    analyze]      │             │    review]       │
└────────┬─────────┘             └────────┬─────────┘
         │                                │
         ▼                                ▼
  ┌─────────────┐                 ┌─────────────┐
  │ MCP: github │                 │ MCP: snyk   │
  │ scope: repo │                 │ scope: scan │
  │   :read     │                 │   :read     │
  └─────────────┘                 └─────────────┘

7.3 Implementacion de JIT Token Issuance

# agent_identity.py — Just-In-Time token issuance para agentes
from datetime import datetime, timedelta
import jwt
import hashlib

class AgentIdentityManager:
    """Gestiona identidades y tokens efimeros para agentes AI"""

    TOKEN_TTL_SECONDS = 300  # 5 minutos

    AGENT_REGISTRY = {
        "AG-01": {"role": "architect",         "allowed_tools": ["plan", "analyze", "read_code"],   "max_scope": "read"},
        "AG-02": {"role": "qa_engineer",       "allowed_tools": ["test", "lint", "coverage"],       "max_scope": "read"},
        "AG-03": {"role": "security_reviewer", "allowed_tools": ["scan", "review", "audit"],        "max_scope": "read"},
        "AG-04": {"role": "spec_writer",       "allowed_tools": ["read_spec", "write_spec"],        "max_scope": "write:specs"},
        "AG-05": {"role": "code_reviewer",     "allowed_tools": ["read_code", "comment", "approve"],"max_scope": "read"},
    }

    def issue_token(self, agent_id: str, session_id: str, requested_tools: list[str], requesting_user: str) -> dict:
        """Emite token efimero con scope minimo para la operacion solicitada"""
        agent = self.AGENT_REGISTRY.get(agent_id)
        if not agent:
            raise ValueError(f"Unknown agent: {agent_id}")

        # Validar que los tools solicitados estan permitidos
        unauthorized = set(requested_tools) - set(agent["allowed_tools"])
        if unauthorized:
            raise PermissionError(f"Agent {agent_id} not authorized for tools: {unauthorized}")

        now = datetime.utcnow()
        token_payload = {
            "sub": f"agent:{agent_id}",
            "agent_id": agent_id,
            "agent_role": agent["role"],
            "session_id": session_id,
            "requesting_user": requesting_user,
            "scope": agent["max_scope"],
            "tools": requested_tools,
            "iat": now,
            "exp": now + timedelta(seconds=self.TOKEN_TTL_SECONDS),
            "jti": hashlib.sha256(f"{agent_id}:{session_id}:{now.isoformat()}".encode()).hexdigest()[:16],
        }

        token = jwt.encode(token_payload, self._get_signing_key(), algorithm="ES256")

        # Audit log
        self._audit_log("TOKEN_ISSUED", agent_id=agent_id, session_id=session_id,
                       tools=requested_tools, ttl=self.TOKEN_TTL_SECONDS, user=requesting_user)

        return {"token": token, "expires_in": self.TOKEN_TTL_SECONDS, "scope": agent["max_scope"]}

    def validate_tool_access(self, token: str, tool_name: str) -> bool:
        """Valida que el token permite acceso al tool solicitado"""
        try:
            payload = jwt.decode(token, self._get_verification_key(), algorithms=["ES256"])
            return tool_name in payload.get("tools", [])
        except jwt.ExpiredSignatureError:
            self._audit_log("TOKEN_EXPIRED_ACCESS_ATTEMPT", tool=tool_name)
            return False
        except jwt.InvalidTokenError:
            self._audit_log("INVALID_TOKEN_ACCESS_ATTEMPT", tool=tool_name)
            return False

    def revoke_session(self, session_id: str):
        """Revoca todos los tokens de una sesion (kill switch)"""
        self._add_to_revocation_list(session_id)
        self._audit_log("SESSION_REVOKED", session_id=session_id)

    def _audit_log(self, event: str, **kwargs):
        """Registra evento en audit trail inmutable"""
        # Implementar con Langfuse, CloudWatch, o sistema de audit
        pass

    def _get_signing_key(self):
        """Obtiene clave de firma desde vault (nunca hardcoded)"""
        # Implementar con HashiCorp Vault, AWS KMS, etc.
        pass

    def _get_verification_key(self):
        pass

    def _add_to_revocation_list(self, session_id: str):
        pass

7.4 Credential Rotation Pattern

# agent-credential-rotation.yaml — GitHub Action para rotacion automatica
name: Agent Credential Rotation
on:
  schedule:
    - cron: '0 2 * * 1'  # Cada lunes a las 2:00 UTC
  workflow_dispatch: {}

jobs:
  rotate:
    runs-on: ubuntu-latest
    steps:
      - name: Rotate agent signing keys
        run: |
          # Generar nuevo par de claves
          openssl ecparam -genkey -name prime256v1 -out new-agent-key.pem
          openssl ec -in new-agent-key.pem -pubout -out new-agent-key-pub.pem

          # Subir a vault con periodo de overlap (24h)
          vault kv put secret/agent-identity/signing-key \
            current=@new-agent-key.pem \
            previous=@old-agent-key.pem \
            rotation_date=$(date -u +%Y-%m-%dT%H:%M:%SZ)

      - name: Verify rotation
        run: |
          # Test que tokens nuevos se verifican con nueva clave
          python scripts/test-agent-identity.py --verify-rotation

      - name: Audit log rotation event
        run: |
          echo "CREDENTIAL_ROTATION agent_signing_key $(date -u +%Y-%m-%dT%H:%M:%SZ)" >> audit.log

7.5 Agent Identity por Track

Track	Nivel	Implementacion
Solo	Basico	agent_id en logs + API key con scope limitado por .env
Lean	Medio	JIT tokens por sesion + vault para secretos + audit log en Langfuse
Full	Alto	Full NHI lifecycle (issuance, rotation, revocation) + IdP integration + SIEM audit

7.6 Anti-patrones de Agent Identity

Anti-patron	Riesgo	Remediacion
Compartir service account entre agentes	Blast radius total si uno se compromete	Un identity por agente
Tokens de larga duracion (>1h)	Ventana de ataque amplia	JIT tokens ≤5min
Credenciales en variables de entorno sin vault	Leak via logs o process listing	HashiCorp Vault / AWS Secrets Manager
Sin audit trail de acciones por agente	Imposible investigar incidentes	Langfuse traces con agent_id obligatorio
Reusar credenciales humanas para agentes	Confusion de identidad, imposible RBAC	NHI dedicados con scoping independiente

---

8. AI System Classification & EU AI Act Technical Compliance

8.1 AI System Classification Workflow

Antes de implementar cualquier control de compliance, el equipo debe clasificar su sistema AI segun el EU AI Act. Esta clasificacion determina las obligaciones legales aplicables.

                    ┌─────────────────────┐
                    │ START: Tenemos un   │
                    │ sistema que usa IA? │
                    └────────┬────────────┘
                             │ Si
                             ▼
               ┌──────────────────────────┐
               │ Esta en la lista de      │     Si    ┌────────────────┐
               │ practicas prohibidas?    │──────────▶│ PROHIBIDO      │
               │ (Art. 5 EU AI Act)       │           │ No comercializar│
               └────────────┬─────────────┘           └────────────────┘
                            │ No
                            ▼
               ┌──────────────────────────┐
               │ Es un modelo de          │     Si    ┌────────────────┐
               │ proposito general (GPAI)?│──────────▶│ GPAI           │
               │ (Art. 51-55)             │           │ Arts. 51-55    │
               └────────────┬─────────────┘           │ + riesgo       │
                            │ No                      │ sistemico?     │
                            ▼                         └────────────────┘
               ┌──────────────────────────┐
               │ Esta en Annex I          │     Si    ┌────────────────┐
               │ (legislacion armonizada) │──────────▶│ ALTO RIESGO    │
               │ o Annex III (areas)?     │           │ Arts. 6-49     │
               │ (Art. 6)                 │           │ Full compliance│
               └────────────┬─────────────┘           └────────────────┘
                            │ No
                            ▼
               ┌──────────────────────────┐
               │ Interactua directamente  │     Si    ┌────────────────┐
               │ con personas? (chatbot,  │──────────▶│ RIESGO LIMITADO│
               │ genera contenido, deep-  │           │ Art. 52        │
               │ fakes, biometria?)       │           │ Transparencia  │
               └────────────┬─────────────┘           └────────────────┘
                            │ No
                            ▼
               ┌──────────────────────────┐
               │ RIESGO MINIMO            │
               │ Sin obligaciones         │
               │ especificas del AI Act   │
               │ (buenas practicas        │
               │ voluntarias)             │
               └──────────────────────────┘

8.2 Practicas Prohibidas (Art. 5) — Checklist Rapida

Practica	Descripcion	Tu sistema lo hace?
Social scoring	Puntuar personas basandose en conducta social	[ ] No
Explotacion de vulnerabilidades	Usar IA para explotar edad, discapacidad, situacion economica	[ ] No
Biometric categorization (sensible)	Clasificar personas por raza, orientacion sexual, creencias	[ ] No
Scraping facial no dirigido	Recopilar imagenes faciales de internet/CCTV sin consentimiento	[ ] No
Reconocimiento de emociones	En trabajo o educacion (con excepciones medicas/seguridad)	[ ] No
Predictive policing individual	Predecir criminalidad individual basandose en perfil	[ ] No

Si alguna casilla es “Si” → STOP. El sistema no puede comercializarse en la UE.

8.3 Annex III — Areas de Alto Riesgo

Verificar si tu sistema AI opera en alguna de estas areas:

Area	Ejemplos
Biometria	Identificacion remota, categorizacion biometrica
Infraestructura critica	Agua, gas, electricidad, transporte, telecomunicaciones
Educacion y formacion	Scoring de exámenes, admisiones, deteccion de trampas
Empleo y RRHH	Screening de CVs, evaluacion de candidatos, promociones
Servicios esenciales	Scoring crediticio, seguros, servicios sociales
Law enforcement	Evaluacion de riesgo de reincidencia, polygraphs AI
Migracion y asilo	Evaluacion de solicitudes, deteccion de documentos falsos
Justicia y democracia	Asistencia en sentencias, analisis de evidencia

8.4 Requisitos Tecnicos para Alto Riesgo (Arts. 9-15)

Si tu sistema es alto riesgo, estos son los requisitos tecnicos y como implementarlos:

Articulo	Requisito	Implementacion en Framework	Artefacto
Art. 9	Risk Management System	F01 risk register + F08 compliance_matrix + monitoreo continuo	project/F01/risk_register.yaml
Art. 10	Data Governance	F03 knowledge_map + data provenance tags + bias testing	project/F03/data_governance.yaml
Art. 11	Technical Documentation	Framework docs + system card + ADRs + API specs	project/F04/system_card.yaml
Art. 12	Record-Keeping	Langfuse traces + audit trail + decision logging	Observability Guide §8
Art. 13	Transparency	AI disclosure labels + system card publica + user documentation	AIActCompliance.add_ai_disclosure()
Art. 14	Human Oversight	HITL gates + escalation protocol + boundaries (Ask First/NEVER)	CLAUDE.md + Multi-Agent Guide
Art. 15	Accuracy, Robustness, Security	Evals CI pipeline + golden dataset + OWASP checklist + SLAs	Evals Guide + OWASP Guide

8.5 AI Literacy Obligation (Art. 4) — Aplica a TODOS

Importante: Art. 4 aplica a TODOS los proveedores y deployers de IA, independientemente del nivel de riesgo.

ai-literacy-checklist.yaml

ai_literacy_program:
  scope: "Todos los empleados que desarrollan, despliegan u operan sistemas AI"

  training_modules:
    - name: "AI Fundamentals"
      audience: "all_staff"
      frequency: "annual"
      topics: ["que es IA", "limitaciones", "riesgos", "EU AI Act basico"]

    - name: "AI Engineering Ethics"
      audience: "engineering_team"
      frequency: "semi_annual"
      topics: ["bias", "fairness", "transparency", "OWASP Agentic Top 10"]

    - name: "AI Risk Assessment"
      audience: "product_managers + tech_leads"
      frequency: "annual"
      topics: ["clasificacion de riesgo", "FRIA", "conformity assessment", "Art. 9-15"]

    - name: "AI Incident Response"
      audience: "ops_team + security"
      frequency: "quarterly"
      topics: ["reporting", "serious incident definition", "post-mortem AI"]

  documentation:
    training_records: true          # Registro de quien completo que modulo
    knowledge_assessments: true     # Evaluaciones post-training
    annual_review: true             # Revision anual del programa

8.6 Fundamental Rights Impact Assessment (FRIA) Template

Para sistemas de alto riesgo, el deployer debe realizar un FRIA antes del despliegue:

# fria-template.yaml — Fundamental Rights Impact Assessment
fria:
  system_name: ""
  version: ""
  assessor: ""
  date: ""

  # 1. Descripcion del sistema
  description:
    purpose: ""
    intended_users: ""
    affected_persons: ""
    geographic_scope: ""
    data_processed: ""

  # 2. Evaluacion de derechos fundamentales
  rights_assessment:
    - right: "Non-discrimination (Art. 21 EU Charter)"
      impact: "low | medium | high"
      mitigation: ""
      residual_risk: ""

    - right: "Privacy (Art. 7-8 EU Charter)"
      impact: "low | medium | high"
      mitigation: ""
      residual_risk: ""

    - right: "Freedom of expression (Art. 11 EU Charter)"
      impact: "low | medium | high"
      mitigation: ""
      residual_risk: ""

    - right: "Human dignity (Art. 1 EU Charter)"
      impact: "low | medium | high"
      mitigation: ""
      residual_risk: ""

    - right: "Right to an effective remedy (Art. 47 EU Charter)"
      impact: "low | medium | high"
      mitigation: ""
      residual_risk: ""

    - right: "Rights of the child (Art. 24 EU Charter)"
      impact: "low | medium | high"
      mitigation: ""
      residual_risk: ""

  # 3. Decision
  overall_risk: "acceptable | conditional | unacceptable"
  conditions: []
  review_date: ""  # Max 12 meses
  approved_by: ""

8.7 EU AI Act Timeline de Obligaciones

Feb 2025 ──── Prohibiciones en vigor (Art. 5)
               └── Social scoring, explotacion vulnerabilidades, etc.

Ago 2025 ──── Obligaciones GPAI en vigor (Arts. 51-55)
               └── Documentacion tecnica, copyright, evaluaciones

Ago 2026 ──── Obligaciones principales en vigor ← PROXIMO DEADLINE
               ├── Alto riesgo: Arts. 6-49 (full compliance)
               ├── Transparencia: Art. 52 (chatbots, deepfakes)
               ├── AI Literacy: Art. 4 (todos los proveedores)
               ├── Regulatory sandboxes: Art. 57 (1 por estado miembro)
               └── Registro en EU database para alto riesgo

Ago 2027 ──── Sistemas existentes (grandfathering)
               └── Sistemas ya en mercado pre-Ago 2026 tienen 1 año extra

8.8 Conformity Assessment Workflow

Para sistemas de alto riesgo (Annex III), el proceso de conformity assessment es:

1. Internal conformity assessment (Art. 43.2) — Self-assessment para la mayoria de los casos
2. Third-party assessment (Art. 43.1) — Obligatorio para biometria remota (Annex III, punto 1)

conformity-assessment-checklist.yaml

conformity_assessment:
  type: "internal | third_party"
  steps:
    - step: "1. Quality Management System"
      status: "pending"
      evidence: ""
      description: "Documentar QMS que cubra AI lifecycle"

    - step: "2. Technical Documentation"
      status: "pending"
      evidence: ""
      description: "System card + architecture + data governance + testing"

    - step: "3. Risk Management"
      status: "pending"
      evidence: ""
      description: "Risk register + mitigations + residual risks"

    - step: "4. Data Governance"
      status: "pending"
      evidence: ""
      description: "Training data docs + bias testing + representativity"

    - step: "5. Record-Keeping"
      status: "pending"
      evidence: ""
      description: "Audit logs + decision traces + automatic logging"

    - step: "6. Transparency"
      status: "pending"
      evidence: ""
      description: "Instructions for use + system card + AI disclosure"

    - step: "7. Human Oversight"
      status: "pending"
      evidence: ""
      description: "HITL mechanisms + override capabilities + training"

    - step: "8. Accuracy & Robustness"
      status: "pending"
      evidence: ""
      description: "Evals results + golden dataset + adversarial testing"

    - step: "9. Cybersecurity"
      status: "pending"
      evidence: ""
      description: "OWASP checklist + penetration testing + incident plan"

    - step: "10. EU Declaration of Conformity"
      status: "pending"
      evidence: ""
      description: "Signed declaration + CE marking + EU database registration"

---

9. Checklist de Seguridad Agentica

Setup inicial

• Mapear riesgos ASI01-10 al proyecto (cuales aplican?)
• Clasificar sistema AI segun EU AI Act (§8.1 flowchart)
• Configurar prompt_injection_tests: true en quality gates
• Implementar MCP security checklist (§6.2 de MCP Guide)
• Definir boundaries NEVER/ALWAYS en CLAUDE.md
• Crear AI-BOM con todas las dependencias AI
• Asignar identidad unica (NHI) a cada agente (§7)
• Configurar sandbox para code execution (§6)
• Completar FRIA si sistema es alto riesgo (§8.6)
• Verificar AI literacy program activo (§8.5)

Por sprint

• @security_reviewer revisa cada PR con componente AI
• Ejecutar evals de seguridad (security_review grader)
• Verificar que tools no exponen mas permisos de los necesarios
• Auditar nuevas skills/MCP servers antes de instalar
• Verificar que tokens de agente son JIT (≤5min TTL)

Mensual

• Review de permisos de agentes (privilege creep?)
• Actualizar AI-BOM con nuevas dependencias
• Ejecutar scan completo: SAST + secrets + dependency audit
• Revisar alertas de budget y circuit breakers
• Rotar credenciales de agentes (§7.4)
• Verificar conformity assessment progress (si alto riesgo)

---

10. Slopsquatting — Playbook Operativo (NUEVO — Cerrando GAP G3)

Fuente: USENIX Security 2025, Socket.dev Research, Cycode ADLC Report 2026 Riesgo OWASP: ASI04 (Supply Chain Vulnerabilities)

10.1 Que es Slopsquatting

Slopsquatting es el ataque de supply chain donde actores maliciosos registran paquetes con nombres que los LLMs inventan frecuentemente (paquetes alucinados). Estadística: ~20% de las dependencias sugeridas por LLMs no existen (USENIX 2025). Los atacantes registran esos nombres con código malicioso.

Agente sugiere → pip install flask-cognito-auth
Paquete no existe → Atacante lo registra con malware
Próximo agente → pip install flask-cognito-auth → COMPROMETIDO

10.2 Por Que es Critico en Software Factories

En una Dark Software Factory (L3+), los agentes instalan dependencias sin supervisión humana. Un solo paquete slopsquatted puede:

1. Exfiltrar secrets del environment
2. Instalar backdoors en el código generado
3. Propagarse a otros agentes via shared environments
4. Comprometer el pipeline CI/CD completo

10.3 Politica de Dependencias Anti-Slopsquatting

Regla 1: Lockfile Obligatorio

# En project-config.yaml o CLAUDE.md
dependencies:
  policy: "lockfile_required"
  rules:
    - "NUNCA instalar dependencias sin lockfile actualizado"
    - "Todo package-lock.json / requirements.txt / Cargo.lock DEBE ser committed"
    - "pip install sin --require-hashes está PROHIBIDO en CI"

Regla 2: Pin por Hash

# Python — generar hashes
pip-compile --generate-hashes requirements.in -o requirements.txt

# Verificar al instalar
pip install --require-hashes -r requirements.txt

# Node.js — verificar integridad
npm ci  # Siempre usar ci, NUNCA npm install en CI

# Go — verificar checksums
go mod verify

Regla 3: Allowlist de Paquetes

# dependency_allowlist.yaml — solo paquetes verificados
allowlist:
  python:
    - name: "langchain"
      min_version: "0.3.0"
      registry: "pypi"
      verified_publisher: true
    - name: "anthropic"
      min_version: "0.40.0"
      registry: "pypi"
      verified_publisher: true
    - name: "fastapi"
      min_version: "0.115.0"
      registry: "pypi"
      verified_publisher: true

  node:
    - name: "@anthropic-ai/sdk"
      min_version: "0.30.0"
      registry: "npm"
      verified_publisher: true
    - name: "langchain"
      min_version: "0.3.0"
      registry: "npm"
      verified_publisher: true

  policy:
    new_package_requires: "human_approval"  # Agentes NO pueden agregar paquetes nuevos sin aprobación
    audit_frequency: "weekly"
    auto_reject_if:
      - "package_age_days < 30"
      - "weekly_downloads < 1000"
      - "no_verified_publisher"
      - "no_source_repository"

Regla 4: Validación Pre-Install en CI

.github/workflows/dependency-guard.yaml

name: Dependency Guard (Anti-Slopsquatting)
on:
  pull_request:
    paths:
      - "requirements*.txt"
      - "package*.json"
      - "Cargo.toml"
      - "go.mod"

jobs:
  dependency-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Detect new dependencies
        run: |
          # Compare con main para detectar nuevas dependencias
          git diff origin/main -- requirements.txt package.json | grep "^+" | grep -v "^+++" > new_deps.txt
          if [ -s new_deps.txt ]; then
            echo "⚠️ NUEVAS DEPENDENCIAS DETECTADAS — requiere review humana"
            cat new_deps.txt
            echo "::warning::New dependencies added — manual review required"
          fi

      - name: Verify package exists and is legitimate
        run: |
          # Python: verificar que el paquete existe en PyPI y tiene historia
          for pkg in $(grep "^+" requirements.txt | sed 's/^+//' | cut -d'=' -f1 | cut -d'>' -f1); do
            response=$(curl -s -o /dev/null -w "%{http_code}" "https://pypi.org/pypi/$pkg/json")
            if [ "$response" != "200" ]; then
              echo "🚨 SLOPSQUATTING ALERT: $pkg NO EXISTE en PyPI"
              exit 1
            fi
            # Verificar edad del paquete
            created=$(curl -s "https://pypi.org/pypi/$pkg/json" | jq -r '.releases | keys | first')
            echo "✅ $pkg existe, primera release: $created"
          done

      - name: Check for known typosquatting
        run: |
          pip install pip-audit
          pip-audit -r requirements.txt --desc on

10.4 Configuracion del Agente (Harness)

Agregar a CLAUDE.md o .claude/rules/:

## Dependency Rules (Anti-Slopsquatting)

1. NUNCA sugieras un paquete sin verificar que existe en el registry oficial
2. SIEMPRE usa la dependency_allowlist.yaml del proyecto
3. Para paquetes NUEVOS no en la allowlist: PIDE APROBACIÓN humana
4. SIEMPRE incluye la versión exacta pinned (no ranges)
5. NUNCA uses pip install directo — usa requirements.txt con hashes
6. Si no estás seguro de que un paquete existe, di "necesito verificar"

10.5 Deteccion y Respuesta

Señal	Accion	Urgencia
CI falla por paquete inexistente	Revisar si agente alucinó el nombre	Media
Paquete nuevo con < 30 días de antigüedad	Block + review manual	Alta
Paquete sin source repository	Block automático	Alta
Paquete con nombre similar a uno popular	Verificar typosquatting	Alta
Dependency audit encuentra vulnerabilidad	Patch o replace inmediato	Crítica
pip-audit o npm audit reporta advisory	Evaluar impacto + patch	Alta

10.6 Métricas

• Hallucinated packages/month: paquetes sugeridos por agentes que no existen (target: 0)
• Unverified dependencies: dependencias sin hash/lockfile (target: 0)
• New package approval time: tiempo medio para aprobar nuevos paquetes (target: < 24h)
• Dependency age compliance: % de dependencias con > 30 días de existencia (target: 100%)

10.7 Checklist Anti-Slopsquatting

• dependency_allowlist.yaml creada y mantenida
• Lockfiles committed para todos los package managers
• CI pipeline incluye dependency-guard job
• Reglas anti-slopsquatting en CLAUDE.md / agent harness
• pip-audit / npm audit ejecutándose en CI
• Política de “nuevos paquetes requieren aprobación humana”
• AIBOM incluye sección ai_dependencies con hashes
• Review mensual de dependencias (sección 9 checklist)

---

11. Drills de Enforcement en Runtime

Por que importan los drills de runtime

Los mecanismos de seguridad operacional — kill switches, circuit breakers de costo, senales de parada — solo son utiles si funcionan cuando se necesitan. Un kill switch que falla en produccion es peor que no tenerlo, porque genera falsa confianza.

El EU AI Act Art. 12 (Record-Keeping) y Art. 9 (Risk Management System) requieren que los sistemas de alto riesgo demuestren que sus controles operacionales funcionan de manera continua, no solo al momento de despliegue. Los drills automatizados proveen evidencia auditable de que los mecanismos de parada de emergencia y los circuit breakers responden correctamente.

Ademas, en una Software Factory autonoma (L3+), donde los FABs operan sin supervision humana directa, la verificacion periodica de estos mecanismos es critica para evitar escenarios donde un agente desbocado no pueda ser detenido.

11.1 Kill Switch Drill

Ejecuta una simulacion completa del kill switch: parada graceful, limpieza de senales, y checkpoint de emergencia.

# Ejecucion local (output humano)
bash scripts/fab-kill-switch-drill.sh

# Ejecucion en CI (output JSON)
bash scripts/fab-kill-switch-drill.sh --json

El drill verifica:

1. Que la senal .fab-signal se crea correctamente con formato STOP_REQUESTED
2. Que la senal se puede limpiar (cleanup)
3. Que el checkpoint de emergencia (KILL_REQUESTED) genera un commit git
4. Que todos los pasos se ejecutan sin errores

Frecuencia recomendada: Mensual, o despues de cada cambio en fab-kill-switch.sh.

11.2 Cost Guard Verification

Ejecuta una simulacion dry-run de los umbrales del cost guard sin escribir archivos .fab-signal.

# Ejecucion local (output humano)
python3 scripts/fab-cost-guard.py verify

# Ejecucion en CI (output JSON)
python3 scripts/fab-cost-guard.py verify --json

La verificacion simula:

1. Costo al 85% del budget → debe retornar exit code 1 (yellow/warn)
2. Costo al 100% del budget → debe retornar exit code 3 (critical/stop)
3. Costo al 120% del budget → debe retornar exit code 3 (critical/stop)

Frecuencia recomendada: Semanal, o despues de cada cambio en umbrales de .fab-config.yaml.

11.3 Checklist de Compliance para Drills

• Kill switch drill ejecutado mensualmente con resultado PASS
• Cost guard verification ejecutado semanalmente con resultado PASS
• Resultados JSON de ambos drills almacenados como evidencia de audit (Art. 12)
• Drills integrados en pipeline CI (GitHub Actions o equivalente)
• Alertas configuradas para notificar si algun drill falla en CI

---

12. Referencias

Recurso	URL
OWASP Top 10 Agentic Applications 2026	genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
OWASP Top 10 LLM Applications 2025	genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/
OWASP AI Agent Security Cheat Sheet	cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet
Alex Ewerlof OWASP Engineering Guide	blog.alexewerlof.com/p/owasp-top-10-ai-llm-agents
Anthropic Agentic Coding Trends (Trend 8)	resources.anthropic.com/2026-agentic-coding-trends-report
Snyk Skills Audit (36% injection)	Referenced in Context Engineering Guide v5.1
Auth0 OWASP Agentic Lessons	auth0.com/blog/owasp-top-10-agentic-applications-lessons/
Entro Security OWASP Agentic & NHIs	entro.security/blog/the-owasp-agentic-top-10-2026
Palo Alto Networks OWASP Agentic	paloaltonetworks.com/blog/cloud-security/owasp-agentic-ai-security/
OWASP GenAI RSA 2026 Expansion	prnewswire.com (OWASP GenAI RSA 2026)
EU AI Act (full text)	eur-lex.europa.eu/eli/reg/2024/1689/oj
LegalNodes EU AI Act Roadmap Aug 2026	legalnodes.com/article/eu-ai-act-compliance-roadmap-for-august-2026-deadline
McKenna High-Risk Technical Guide	mckennaconsultants.com/eu-ai-act-high-risk-compliance
gVisor Documentation	gvisor.dev/docs/
Firecracker microVMs	firecracker-microvm.github.io/

---

Documento generado como companion operativo del AI-First Engineering Framework v6.1