An agent can read a webpage, inspect a document, retrieve a record, summarize an email, and use a tool in one smooth-looking workflow.
That convenience hides a structural change: the agent is no longer receiving instructions from a single user in a closed conversation. It is continuously ingesting content written by people and systems that do not share the user's goals. Some of that content is useful evidence. Some of it may be misleading, manipulative, or irrelevant. The agent must still keep working without allowing the act of reading to become permission to act.
This is the core of prompt-injection resilience.
The problem is not simply that a model might encounter a suspicious phrase. It is that untrusted content can influence a system that has access to data, links, applications, or tools. OpenAI's recent security guidance describes this as a social-engineering challenge and uses source–sink analysis, where a sink may be a consequential capability: risk grows when an external influence can reach a capability that matters.
Untrusted content can be evidence. It is never authority.
That distinction moves the design question away from “Can we filter every bad input?” and toward “What influence can this content have, and what does the system still require before it creates an effect?”
Why filtering alone cannot carry the burden
Content filters and model-level defenses are valuable. They can reduce the chance that a system follows irrelevant or malicious instructions. But they cannot be the only control.
External content is often ambiguous. A useful public document can contain a quoted instruction, a warning, a user-generated comment, or a link that leads elsewhere. A reliable system cannot assume it will perfectly classify every sentence as safe or unsafe before the agent reasons about it.
More importantly, a correct classifier does not settle the authority question. A source may be entirely legitimate and still have no standing to:
- redefine the user's task;
- request unrelated access to private data;
- broaden an agent's tool scope;
- require the agent to contact a new destination; or
- overrule a confirmation or approval boundary.
That is why reputation lists and input filtering are incomplete solutions. OpenAI's agent link-safety account similarly explains why destination reputation alone cannot constrain every data-flow or navigation risk. The system needs an independent policy that says what a piece of content can do in the workflow even if the content appears credible.
The Influence Boundary Map
The Influence Boundary Map is a proposed design record for tasks that combine untrusted content with agent capabilities. It is not a claim that any one tool or model implements this record. It gives teams a common way to separate content, authority, and effects before the agent begins a high-trust workflow.
- Map element: Source identity and posture — Question it answers: Where did this material come from, and is it user-provided, system-provided, public, connected, or otherwise untrusted? — Why it matters: Keeps provenance visible without pretending that source identity alone proves safety
- Map element: Allowed purpose — Question it answers: May this material serve as evidence, a lead, a quotation target, a user preference, or a task instruction? — Why it matters: Prevents a factual source from being promoted into a command source
- Map element: Influence boundary — Question it answers: Which decisions may this material inform, and which decisions are reserved for higher-trust instructions or human approval? — Why it matters: Makes authority explicit instead of relying on placement in a context window
- Map element: Data exposure boundary — Question it answers: What task-relevant data, if any, may be considered while processing this source? — Why it matters: Applies least access to the content pathway, not only to the tool list
- Map element: Capability and effect boundary — Question it answers: Which read, navigation, communication, or change capabilities remain available after the content is read? — Why it matters: Limits the impact if the agent is misled
- Map element: Confirmation and escalation rule — Question it answers: Which proposed effects require a person, a trusted policy check, or a safe hold before continuing? — Why it matters: Prevents external material from creating a silent path to consequential action
- Map element: Audit and re-entry state — Question it answers: What source, decision, hold, or block should a resumed task see before it continues? — Why it matters: Lets later turns distinguish a verified task instruction from untrusted context
The map does not require labeling every paragraph on the internet. It requires making the important transitions explicit: content enters, the agent forms a judgment, a capability becomes relevant, and an effect may be proposed.
Treat instruction authority as a separate channel
Many interfaces place user requests, retrieved documents, tool output, and system guidance in the same conversational frame. The model may see all of it as text, but the product should not treat all text as equally authoritative.
A useful implementation-independent rule is:
- Material: User request — May influence: Task objective, priorities, and permitted outcome within the product's rules — Must not do on its own: Override safety policy or hidden authorization requirements
- Material: System and product policy — May influence: Allowed capabilities, privacy boundaries, confirmation rules, and task constraints — Must not do on its own: Invent user intent or make a source current without verification
- Material: Trusted task state — May influence: What has already been approved, verified, completed, or held — Must not do on its own: Be silently rewritten by newly retrieved content
- Material: External or connected content — May influence: Facts, leads, alternatives, and evidence that can be evaluated — Must not do on its own: Change the objective, expand permissions, or direct unrelated tool use
This is not a demand to show users a complex trust taxonomy. It is a way to ensure the system itself knows why a particular piece of text is present and what it is allowed to influence.
For a research task, a webpage may help answer the question. It should not redirect the task to a new objective. For a connected application, a record may supply data under the existing task scope. It should not cause the agent to request unrelated data because the record contains a persuasive message.
Constrain the source-to-effect path
OpenAI's security writing recommends thinking about sources and sinks: an external influence becomes dangerous when it can drive an action or transmission. That is a useful general model for agent builders.
The goal is not to ban all content or all actions. It is to make the route between them narrow, observable, and policy-controlled.
Consider four design questions:
- What source is influencing the next step? The answer might be a user request, a current task artifact, a public source, or an application record. If the source is unclear, the agent should not treat it as a command.
- What data is available on that path? A task that only needs public facts should not receive broad access to unrelated private context.
- What capability would the next step invoke? Reading, drafting, navigating, proposing, and changing an external record have different consequences and deserve different checks.
- What independent condition must hold before the effect? This may be a matching user instruction, a current approval, a confirmation, or a policy rule that the content cannot satisfy itself.
The crucial design property is independence. A third-party source should never be able to manufacture the condition that authorizes an effect.
Do not collapse evidence into permission
A subtle failure happens when the agent treats useful evidence as a permission grant.
Suppose an agent reads a well-supported claim in a source. The claim may justify an analysis or a draft. It does not automatically justify changing a user-controlled setting, sharing information, creating a new external artifact, or widening the agent's scope. Evidence tells the system what may be true. Authority tells the system what it may do about that truth.
Keeping those concepts separate gives an agent a safer and more useful next step:
- It can cite or summarize evidence with a clear source posture.
- It can prepare a proposal instead of applying an effect.
- It can ask for the narrow decision that is missing.
- It can abstain if the source is trying to redefine the task.
This is why confirmations matter. They should not be a generic warning after the work is finished. A meaningful confirmation identifies the proposed effect, the relevant destination or work surface, the data class involved if applicable, and the fact that the request still matches the user's stated goal.
Make task scope narrower than the open web
OpenAI's public prompt-injection guidance recommends giving agents explicit, well-scoped tasks and limiting access to the data needed for those tasks. That is sound architecture, not merely a user-tip checklist.
Broad prompts create broad interpretation space. A task such as “take care of everything that looks important” forces the agent to infer priorities, authority, and exceptions from a changing information environment. The result may be hard to review even when every individual step appears reasonable.
Instead, define:
- the goal and the artifact expected at the end;
- the acceptable source classes;
- the data scope needed to complete the work;
- the effects the agent may prepare versus the effects it may apply;
- the conditions that require confirmation or a hold; and
- the stopping condition.
This lets the system make progress while preserving a legible boundary. If the agent encounters content that falls outside the stated purpose, it can record the finding as a lead rather than follow it automatically.
Test the boundary, not only the model
Prompt-injection resilience should be evaluated as a system property.
Testing only whether a model ignores a suspicious-looking string misses the question that matters most: could untrusted content still move sensitive data or cause an unintended effect through a connected capability?
Useful evaluation scenarios include:
- a relevant external source that contains instructions unrelated to the assigned task;
- a source that asks the agent to widen the task scope;
- a source that attempts to turn public research into a request for private data;
- a source that suggests a consequential effect without a matching user instruction; and
- a resumed task that must remember an earlier hold or blocked transition.
The expected behavior should not be “the model gives a particular response.” It should be “the task state, tool policy, and confirmation boundary prevent the source from becoming authority.”
Measure things that reveal the whole path:
- Unauthorized-influence rate: How often does external content change a task objective or effect proposal without a valid higher-trust basis?
- Unnecessary-access rate: How often does a task receive data or tool scope it did not need?
- Confirmation fidelity: How often does a proposed effect still match the displayed task objective and current data boundary?
- Blocked-path explainability: Can a reviewer see why the agent held or declined a transition?
- Boundary-regression rate: Do model, connector, or tool changes accidentally re-open a path that earlier policy blocked?
No single classifier score proves resilience. These measurements test whether the system kept its promises when content, capabilities, and user authority met.
A practical adoption path
- Choose one agent workflow that reads from more than one external or connected source.
- List the source classes and define what each is allowed to contribute: evidence, preference, task instruction, or none of these.
- Map the data and capabilities reachable after each source is processed.
- Add explicit task-scope and confirmation rules at the points where a read could become an effect.
- Add a durable hold state for content that conflicts with task scope or requests a new authority boundary.
- Evaluate the end-to-end source-to-effect route, including retries and resumed tasks.
- Review the map whenever a connector, tool, or new agent capability is introduced.
The lasting lesson is not that agents should distrust every document. It is that systems should never ask a document to decide what an agent is permitted to do.
What we are learning building Virillio Code
Virillio Code is in development. High-level work around scoped tools, durable task state, and permission boundaries supports a general security principle: content can inform an agent's work, but the authority to broaden scope or create an external effect must remain in an independent, visible control path. The Influence Boundary Map is a proposed educational framework, not a description of a released security architecture.
Sources and further reading
- Designing AI agents to resist prompt injection — OpenAI — Agent security can use source–sink analysis to constrain paths from untrusted external influence to consequential capabilities instead of relying only on input detection.
- Understanding prompt injections — OpenAI — Third-party content can mislead agents, and layered protections, limited access, clear task scope, and confirmations help reduce unintended effects.
- Keeping your data safe when an AI agent clicks a link — OpenAI — Destination reputation alone is not sufficient to constrain unintended data flow and navigation risk.
Editorial disclosure
This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.