Agentic AI Security Needs Filtered IPO
#Security

Agentic AI Security Needs Filtered IPO

Startups Reporter
4 min read

Sebastian Martinez Torregrosa argues that the security problems of agentic AI stem from weak architectural boundaries. He proposes a “Filtered Input‑Process‑Output” (Filtered IPO) pattern that inserts deterministic filters between each stage, keeping raw data, reasoning, and execution separate, improving auditability and reducing attack surface.

Agentic AI Security Needs Filtered IPO

Featured image

The problem that keeps surfacing

Prompt‑injection attacks are no longer a quirky chatbot issue; they are a symptom of a deeper architectural flaw. In many deployments, raw inputs—whether they are PDFs, OCR text, API responses, or even metadata—are fed directly into an agent that both reasons and executes actions. The lack of clear boundaries lets malicious instructions travel inside the workflow, turning a simple document into a vector for compromise.

When an agent can read, decide, and act on the same payload, a single injection can trigger payments, modify records, or launch privileged tools. The root cause is simple: raw material moves too far without being sanitized.

Re‑introducing a classic pattern

The remedy does not require a brand‑new paradigm. It revives the classic Input‑Process‑Output (IPO) model, but with explicit, deterministic filters at every hand‑off. This “Filtered IPO” forces the system to treat AI like any other component: it receives well‑defined data, performs a bounded reasoning step, and then passes a vetted result to the next stage.

Three layers, strict borders

  1. Input Layer – Handles ingestion, parsing, and initial validation. Deterministic parsers or rule‑based validators are preferred here; AI is only used if the content is ambiguous.
  2. Logic Agents Layer – Performs the reasoning that truly requires language models. Each agent is narrowly scoped, has least‑privilege tool access, and operates on sanitized inputs.
  3. Output Layer – Executes actions (e.g., sending an email, creating a payment) after the payload has passed through a final filter that checks schema, policy, and access rights.

Every transition between these layers is mediated by a filter that:

  • Enforces schema compliance
  • Applies RBAC/ABAC policies
  • Logs the hand‑off for audit purposes
  • Quarantines or escalates suspicious payloads

Not every component needs to be an agent

A common mistake is to sprinkle language models everywhere. The filtered approach insists on using the simplest reliable tool for each job. Deterministic parsers, rule engines, or workflow orchestrators handle the bulk of the work. Agents appear only where ambiguity, classification, or planning is unavoidable.

Multiplexed flows for larger systems

In a simple pipeline the layers are linear, but real‑world workflows often branch. Different invoice types, for example, can be routed to specialized input parsers, distinct reasoning agents, and separate output handlers (payment vs. denial). Each branch still respects the filter contract, keeping the overall system easier to test and audit.

Filters become the governance backbone

Because every hand‑off passes through a filter, these points become natural places to embed governance:

  • Audit logging – Record the original payload reference, validation outcome, and routing decision.
  • Policy enforcement – Validate against compliance rules, data‑minimization constraints, and tool‑access matrices.
  • Quarantine & escalation – Detect corrupted or suspicious inputs early and alert operators before they reach the reasoning layer.

Human‑in‑the‑loop (HITL) reviewers are no longer a bottleneck for every transaction. They intervene only on exceptions that deterministic filters cannot resolve, preserving their expertise for truly ambiguous cases.

Benefits and trade‑offs

Benefit Trade‑off
Higher security – attacks stop at the first filter Added latency from extra validation steps
Clear audit trails – every step is logged More upfront engineering to define schemas and policies
Fault isolation – failures stay within a single layer Increased orchestration complexity
Reduced hallucinations – agents see only concise, structured context Need for disciplined filter design to avoid sprawl

Why this matters now

Agentic AI is being deployed in finance, legal, and support operations where a single erroneous instruction can have monetary or regulatory consequences. Treating AI as a magical black box ignores the centuries‑old discipline of software engineering. By reinstating explicit boundaries, organizations can reap the benefits of intelligent reasoning without surrendering control.

Takeaways

  1. Adopt Filtered IPO – Separate input, reasoning, and execution with deterministic filters.
  2. Use agents sparingly – Deploy language models only where genuine ambiguity exists.
  3. Make filters the governance layer – Log, validate, and quarantine at every hand‑off.

The AI era is not a post‑engineering era; it is a call to reinforce engineering fundamentals around powerful models.


Author: Sebastian Martinez Torregrosa
Published: May 28 2026 on HackerNoon

Comments

Loading comments...