The AI era is not a post-engineering era. A boundary-first pattern for security, governance, and auditability in agentic AI workflows.
Prompt-injection attacks are not just an AI cybersecurity problem. They are a symptom of weak agentic architecture: raw inputs travel too far, agents lack clear boundaries, and reading, reasoning, tool access, and execution collapse into the same operational path.
The Real Problem Is Architectural
We treat AI like magic that makes classic IT engineering obsolete — just throw data at it and let one super-intelligent agent handle everything.
At first, I thought this was just an immaturity problem. Agentic AI is new, so the lack of reliable architectural patterns looked like an early-adoption issue that would fade with maturity. But it increasingly looks like a common practice, not a temporary mistake.
That temptation becomes dangerous when agentic systems process real documents: invoices, emails, PDFs, support tickets, purchase orders, contracts, or payment requests. Written sources are the easiest target, but they are not the only attack surface. Scanned images, OCR text, metadata, API responses, retrieved documents, logs, and even internal user prompts may carry instructions, poisoned context, or misleading data into the workflow.
Once an agent receives those inputs raw, the attacker is no longer fully outside the workflow. Malicious instructions can travel inside the content the agent is supposed to process.
That is where prompt injection becomes not just a chatbot trick, but a workflow-design failure: free-form input, reasoning, tool access, and execution rights blur into the same operational path.
The deeper problem is simple: raw material is allowed to travel too far through the agentic AI chain. It moves from input, to reasoning, to execution before its risk has been reduced. In the worst designs, there is not even a real chain: raw input and execution live inside the same agent.
Filtered Input-Process-Output
The fix isn’t some revolutionary new idea. It starts with the classic Input-Process-Output (IPO) pattern we’ve known for decades: inputs enter the system, a process transforms them, and outputs leave the system.
This is not a net-new paradigm. It is the opposite. Filtered IPO resurrects a classic software pattern and forces AI to play by its rules: explicit boundaries, narrow responsibilities, controlled hand-offs, and no direct path from raw input to execution.
Filtered Input-Process-Output (Filtered IPO) is my proposal for an agentic AI architecture pattern that adapts the classic IPO model by inserting explicit boundaries and deterministic filters between each stage. Its goal is to ensure that raw inputs, reasoning, governance, and execution remain separated, auditable, and controlled.
The central layer of the architecture is the Logic Agents layer — this is where intelligent reasoning happens, protected on both sides by deterministic filters.
Build your agentic system with three isolated layers connected only by deterministic filters:
The point is not the diagram itself. The point is the boundary: raw input, reasoning, policy enforcement, and execution should not collapse into the same component.
Do Not Put AI Everywhere
One important clarification: every layer does not need to be agentic. Filtered IPO is not an excuse to put AI everywhere.
Each Input, Process, or Output layer should use the simplest reliable component for the job. If a deterministic parser, rule engine, validator, workflow engine, or API connector can do the task safely, use that instead. Agentic AI should appear only where reasoning, ambiguity handling, classification, planning, or contextual interpretation is actually required.
When an AI agent is needed, it should still be narrowly scoped. Each agent should have a clear specialization, bounded context, limited tools, least-privilege access, and domain-relevant outputs.
Collaboration should happen across filtered layers, not through one oversized agent that tries to read, reason, decide, and execute everything. This reduces mistakes, improves security, and makes governance easier to audit.
The rule is simple: use agents where reasoning is needed, deterministic components where certainty is possible, and filters at every boundary.
No agent should talk directly to another in a way that bypasses architectural boundaries. Even when using Model Context Protocol (MCP) or similar standards, the protocol should carry structured, policy-checked hand-offs — not become a shortcut around filters. Used well, MCP can help standardize clean exchanges. Used poorly, it can become another path for raw context and tool access to leak across layers.
Multiplexed Filtered IPO
In simple workflows, Filtered IPO can be linear. In larger systems, it can be multiplexed: different routes can use different specialized Input, Process, and Output components as needed, with dedicated filters between each step.
This may look like added complexity, but the point is to make each component simpler and less error-prone. Clear cases can use deterministic processors. Ambiguous cases can use agentic reasoning. Rejected invoices can route to an email-output component that sends a denial or clarification request. Approved invoices can route to a separate payment-output component with stricter permissions and stronger validation.
The same principle applies to filters: use specialized filters for different structures, risks, and actions instead of forcing one generic filter to understand everything.
This architectural pattern is not just more secure. It also lets you build scoped agents, cleaner structured contexts, and safer combinations of AI and deterministic components.
Filtered IPO also scales better than a single long-running agent. When needed, you can use fleets of short-lived, scoped agents to process tasks in parallel, then pass their outputs through the same deterministic filters. For critical decisions, you can add consensus processing — such as majority voting or independent cross-checks — but only as input to policy enforcement, not as a replacement for it.
Filters Become Governance Infrastructure
Filtered IPO creates a layer where traceable governance can be added: audit trails, logs, access control, and policy enforcement. Filters become natural governance enforcement points because every hand-off passes through them. They are the right place to add:
- audit logging
- schema validation
- security checks
- RBAC / ABAC policy enforcement
- allowed-action validation
- escalation rules
- quarantine rules
- tool-permission checks
- data-minimization controls
As a best practice, every filter should write its outcome into an audit trail. That means logging what it received from the previous layer, what schema or policy check was applied, where the payload was routed, and whether it was passed, rejected, quarantined, escalated, or transformed into a safer structure. It should also ensure that downstream layers receive the business process ID needed to chain the audit trail, plus a safe reference ID to the original source — not a raw copy of the source itself.
A filter is not designed to make the business decision. It should make the boundary decision: whether the payload is valid, safe, policy-compliant, and eligible to move to the next step. The audit trail should make the full workflow traceable without requiring raw content to be copied through every layer.
Even if the final review or viewer layer uses AI, and therefore can still be exposed to prompt injection, the damage is contained by design. That layer should have a narrow purpose, limited permissions, and no direct execution rights. A successful injection against the viewer should not be able to trigger payments, modify records, call privileged tools, or contaminate the rest of the workflow. The blast radius stays bounded because the architecture does not give that layer more authority than it needs.
Filters also help reduce the Human-In-The-Loop (HITL) approval flood without pretending humans are obsolete. In
Contain the Blast Radius
Any meaningful deviation should trigger an “Input corruption detected” quarantine and alert. The goal is to stop prompt-injection attempts at the first filter — or quarantine them before they reach the reasoning layer.
This does not make agentic systems invulnerable. It simply moves the attack surface from free-form language into narrower, inspectable, testable interfaces.
Of course, when audit or Human-In-The-Loop review needs the original content, retrieve it through the safe source reference only. There is no need to pass the entire raw document through the whole AI chain. The raw source should be displayed or reprocessed only in the final review layer, only when needed, and under limited permissions.
Key Benefits
- Dramatically higher security
- Strong fault isolation: problems stay contained
- Fully auditable workflows
- Clear governance enforcement points
- Reduced Human-In-The-Loop fatigue by escalating only exceptions and ambiguous cases
- Shorter context windows, which means fewer hallucinations and distortions
- Much clearer engineering and maintenance
- Reduced prompt complexity
- Lower complexity per individual agent or component
Trade-offs / Caveats
- Some added latency
- More upfront engineering work to define schemas, filters, routing rules, and policy checks
- Higher orchestration complexity across specialized components
- More components to test, monitor, version, and maintain
- Risk of filter sprawl if every edge case becomes a custom filter
- Requires discipline to keep filters reusable, composable, and well-governed
- Possible higher cost in some cases, depending on implementation
This pattern is a natural corollary to what I argued in
The AI era is not the post-engineering era.
If anything, agentic AI makes engineering discipline more important, not less.
AI is only the engine. Structure, boundaries, patterns, and engineering discipline are the chassis that keep it safe and reliable.
3 Key Takeaways
- Build secure agentic AI the old-school way: Filtered Input-Process-Output (Filtered IPO) plus deterministic filters.
- Never pass raw data between layers — only clean structured data and safe references.
- Use agents where reasoning is needed, deterministic components where certainty is possible, and filters at every boundary.