La Prompt Injection No Está Resuelta: Diseñá Tus Agentes Alrededor de Ella

1. El Problema: Instrucciones y Datos Comparten un Solo Canal

Un programa clásico mantiene separados el código y los datos. Un LLM no: tu system prompt, el pedido del usuario y el cuerpo de un email llegan como un único flujo de tokens. LLM01:2025 de OWASP divide el problema en dos. La inyección directa es cuando el input del propio usuario cambia el comportamiento del modelo. La inyección indirecta es cuando el modelo ingiere contenido externo — una página web, un archivo, un email — que trae instrucciones propias. Los agentes viven todo el día en la segunda categoría, porque leer contenido de afuera es su trabajo.

Así que cambia la postura de ingeniería. Asumí que el modelo a veces va a obedecer el texto equivocado, y diseñá para que un modelo engañado no tenga nada valioso al alcance ni forma de sacarlo. Eso es arquitectura, no redacción de prompts, y es de lo que trata el resto del post.

2. Conceptos Mínimos Antes de Tocar Código

Seis ideas sostienen todo el post. Cada tarjeta enlaza a la fuente primaria, así podés contrastar mi resumen con las palabras de los autores.

3. Auditoría Concreta: Un Asistente de Email Contra las Tres Patas

Conocé a MailPilot, un asistente hipotético que representa a los muchos que existen. Tiene tres herramientas: read_inbox, search_mail y send_email. Resume el correo de la noche, redacta respuestas y — en la versión que me preocupa — las envía solo. No hace falta ningún ataque para ver el problema; alcanza con una revisión de diseño en papel.

Escribir la auditoría como código la vuelve exigible. Cada herramienta declara qué propiedades otorga, y un chequeo de arranque se niega a levantar un agente cuyo toolset combinado cubre las tres — la Rule of Two como aserción.

TypeScript — manifiesto de capacidades más chequeo de Rule of Two

type Property = "untrusted_input" | "private_data" | "external_effect";

interface ToolSpec {
  name: string;
  grants: Property[];
}

const MAILPILOT_TOOLS: ToolSpec[] = [
  { name: "read_inbox", grants: ["untrusted_input", "private_data"] },
  { name: "search_mail", grants: ["untrusted_input", "private_data"] },
  { name: "send_email", grants: ["external_effect"] },
];

// Rule of Two as a startup assertion: at most two properties per session.
export function assertRuleOfTwo(tools: ToolSpec[]): void {
  const held = new Set(tools.flatMap((t) => t.grants));
  if (held.size === 3) {
    throw new Error(
      "Rule of Two violated: untrusted input + private data + external effect. " +
        "Drop a tool, split the session, or require human approval."
    );
  }
}

assertRuleOfTwo(MAILPILOT_TOOLS); // throws: this agent holds all three

4. Paso 1 — Cortá la Pata 3 con una Allow-List de Egreso

Empezá por donde el daño sale del edificio. Un único módulo es dueño de todo efecto saliente y niega por defecto: los destinatarios deben ser contactos conocidos o estar en un dominio permitido, el HTTP va solo a hosts que operás vos y las redirecciones no se siguen. El modelo propone; este código dispone.

TypeScript — egress.ts, la única puerta de salida

// egress.ts - the only module allowed to talk to the outside world.
const RECIPIENT_DOMAINS = new Set(["mycompany.com"]);
const HTTP_HOSTS = new Set(["api.mycompany.com"]);

export class EgressDenied extends Error {}

export function assertRecipient(address: string, knownContacts: ReadonlySet<string>): string {
  const addr = address.trim().toLowerCase();
  const domain = addr.split("@").pop() ?? "";
  if (!knownContacts.has(addr) && !RECIPIENT_DOMAINS.has(domain)) {
    throw new EgressDenied("recipient not allow-listed: " + domain);
  }
  return addr;
}

export async function safeFetch(rawUrl: string, init: RequestInit = {}): Promise<Response> {
  const url = new URL(rawUrl);
  if (url.protocol !== "https:") throw new EgressDenied("https only");
  if (!HTTP_HOSTS.has(url.hostname)) {
    throw new EgressDenied("host not allow-listed: " + url.hostname);
  }
  // A redirect could leave the allow-list, so never follow one silently.
  return fetch(url, { ...init, redirect: "manual" });
}

Dos detalles importan más de lo que parece. Derivá el destinatario de datos estructurados que parseó tu propio código, nunca de texto del modelo. Y contá como egreso lo que renderiza tu UI: una imagen que carga sola o una vista previa de enlace es un request saliente que lleva lo que haya en su URL.

5. Paso 2 — Poné en Cuarentena el Texto No Confiable (Dual LLM, Salidas Tipadas)

Ahora cortá la pata 2 hasta donde el producto lo permita. Leer sigue siendo necesario, así que confinalo: un modelo en cuarentena ve el email crudo, no tiene herramientas y solo puede responder en un schema fijo. El controlador guarda el texto crudo bajo un handle como $MAIL_1. El planificador privilegiado — el modelo que tiene las herramientas — recibe handles y campos tipados, nunca el cuerpo. Es el patrón Dual LLM de Willison de 2023 en su forma más chica.

Python — triage en cuarentena con schema de Pydantic y un almacén de variables

from typing import Literal
from pydantic import BaseModel, Field


class Triage(BaseModel):
    category: Literal["invoice", "meeting", "newsletter", "personal", "other"]
    needs_reply: bool
    urgency: int = Field(ge=1, le=5)


class VarStore:
    """Controller-owned. Untrusted text lives here; the planner sees handles."""

    def __init__(self) -> None:
        self._values: dict[str, str] = {}

    def put(self, text: str) -> str:
        handle = "$MAIL_" + str(len(self._values) + 1)
        self._values[handle] = text
        return handle

    def get(self, handle: str) -> str:
        return self._values[handle]


def quarantined_triage(llm, raw_email: str) -> Triage:
    # No tools are attached to this call and the output is schema-constrained.
    # llm.parse stands for your structured-output call (OpenAI parse, AI SDK Output, instructor).
    return llm.parse(
        system="Classify the email into the schema. You have no tools.",
        user=raw_email,
        schema=Triage,
    )

Python — el planificador solo ve handles y campos tipados

def planner_view(handle: str, triage: Triage) -> dict:
    # Typed, bounded fields only: no subject, no body, no free text.
    return {"handle": handle, **triage.model_dump()}


def morning_run(inbox, planner, quarantine_llm, store: VarStore):
    views = []
    for message in inbox.fetch_unread():
        handle = store.put(message.body)  # raw text never leaves the store
        triage = quarantined_triage(quarantine_llm, message.body)
        views.append(planner_view(handle, triage))
    # The privileged planner owns the tools but only ever receives views.
    return planner.plan(task="Order today's mail by urgency", mail=views)

Dos límites para tener presentes. La ingeniería social sobrevive: si el resumen en cuarentena te llega y suena convincente, el humano pasa a ser la superficie de ataque. Y el propio Willison dice que el patrón no es 100% confiable y que funciones agregadas después pueden filtrar texto no confiable hacia el lado privilegiado — su post ahora aclara que el paper de CaMeL encontró una falla en su propuesta original.

6. Paso 3 — Toolsets por Sesión, Gates de Aprobación y un Log de Auditoría

Última capa: acotá qué puede siquiera intentar cada sesión. La Rule of Two aplica por sesión, así que dividí MailPilot en modos. Triage lee y clasifica pero no tiene ninguna herramienta saliente. Reply puede guardar borradores en local. Solo el modo send — que no lee correo — puede transmitir, y solo después de que un humano aprueba una tarjeta que renderizó tu código.

TypeScript — toolsets por modo y un gate sobre efectos secundarios

type Effect = "read" | "write_local" | "external";
type Mode = "triage" | "reply" | "send";

interface Session {
  id: string;
  mode: Mode;
  untrustedIds: string[]; // ids of emails/pages that entered this context
  askHuman(card: string): Promise<boolean>;
}

interface Tool {
  name: string;
  effect: Effect;
  run(args: Record<string, unknown>): Promise<unknown>;
}

// One session = one mode = at most two of the three properties.
const TOOLSETS: Record<Mode, string[]> = {
  triage: ["read_inbox", "search_mail"], // no outbound tool exists here
  reply: ["read_thread", "save_draft"],  // drafts stay local
  send: ["send_email"],                  // reads no mail; runs after approval
};

// Built by our code from structured fields, never from model-written text.
function renderCard(name: string, args: Record<string, unknown>): string {
  const to = String(args.to ?? "");
  return name + " to domain " + to.split("@").pop() + "\nsubject: " + String(args.subject ?? "");
}

export async function callTool(s: Session, tool: Tool, args: Record<string, unknown>) {
  if (!TOOLSETS[s.mode].includes(tool.name)) {
    throw new Error("tool not in toolset for mode " + s.mode);
  }
  let decision: "auto" | "approved" | "denied" = "auto";
  if (tool.effect === "external") {
    decision = (await s.askHuman(renderCard(tool.name, args))) ? "approved" : "denied";
  }
  auditLog(s, tool, args, decision);
  if (decision === "denied") throw new Error("denied by human");
  return tool.run(args);
}

El log es cómo te enterás de un ataque que funcionó. Registrá cada llamada con su modo, un hash de argumentos, los ids de los ítems no confiables presentes en el contexto y la decisión humana. Después alertá sobre la única combinación que nunca debería pasar en silencio: un efecto externo emitido con contenido no confiable en el contexto.

TypeScript — log de auditoría estructurado con alerta de taint

import { createHash } from "node:crypto";

declare function alertSecurity(reason: string, entry: object): void; // your pager

function auditLog(s: Session, tool: Tool, args: Record<string, unknown>, decision: string) {
  const entry = {
    ts: new Date().toISOString(),
    session: s.id,
    mode: s.mode,
    tool: tool.name,
    effect: tool.effect,
    argsSha256: createHash("sha256").update(JSON.stringify(args)).digest("hex"),
    untrustedIds: s.untrustedIds, // carry these from reply into send so taint survives
    decision,
  };
  console.log(JSON.stringify(entry));
  if (tool.effect === "external" && s.untrustedIds.length > 0) {
    alertSecurity("external effect with untrusted content in context", entry);
  }
}

7. Lo Que Esto No Arregla (Leelo Antes de Shippear)

Todo lo anterior reduce el radio de impacto. Nada lo vuelve ‘resuelto’, y las fuentes primarias son directas al respecto.

8. Errores Comunes (y los Hábitos que los Reemplazan)

Casi todo diseño de agente débil que reviso falla en uno de estos baldes. La columna izquierda es lo que aguanta cuando el modelo es engañado; la derecha es lo que solo funciona mientras no lo es.

Conclusión

La prompt injection no es un bug que espera su parche; es una propiedad de los sistemas que mezclan instrucciones y datos en un solo canal. Lo que controlás es la arquitectura: qué patas de la trifecta tiene un agente a la vez, hasta dónde viaja el texto no confiable y quién confirma antes de que algo salga.

Esta semana, agarrá tu agente más ocupado y escribí su manifiesto de herramientas como en la auditoría de arriba. Si cubre las tres propiedades, cortá una pata en la sesión más riesgosa, canalizá los efectos salientes por un módulo con allow-list y prendé el log. Después repetí la auditoría cada vez que alguien agregue una herramienta — sobre todo un servidor MCP, ya que Willison señala que el protocolo facilita mezclar herramientas de distintas fuentes.

Fuentes

• Simon Willison — The lethal trifecta for AI agents (16 jun 2025)
• Meta AI — Agents Rule of Two: A Practical Approach to AI Agent Security (31 oct 2025)
• Debenedetti et al. — Defeating Prompt Injections by Design (CaMeL), arXiv:2503.18813
• Beurer-Kellner et al. — Design Patterns for Securing LLM Agents against Prompt Injections, arXiv:2506.08837
• Simon Willison — Design Patterns for Securing LLM Agents against Prompt Injections (13 jun 2025)
• Simon Willison — The Dual LLM pattern for building AI assistants that can resist prompt injection (25 abr 2023)
• Nasr, Carlini et al. — The Attacker Moves Second, arXiv:2510.09023
• Simon Willison — New prompt injection papers: Agents Rule of Two y The Attacker Moves Second
• OWASP GenAI — LLM01:2025 Prompt Injection