AI Context Injection: Supply Useful Information Safely

AI context injection means deliberately adding information to an assistant’s input so it can perform a particular task. That information might be your instructions, a document excerpt, a tool result, or the current project status. The useful distinction is who supplied each part and whether it has authority to direct the work.

Tools like fenbs keep approved project rules and decisions outside a private conversation, giving the next assistant a record to consult. You still need to distinguish those instructions from a web page, email, or attachment that the assistant was asked to analyze. Reading a source does not give that source permission to change the job.

What are you adding when you inject context?

Think of context as the working material in front of an assistant. The context window, the space available for its current input and response, is not a permanent filing cabinet. Your application or conversation supplies material for the model to use on this turn.

For example, a studio might ask for a client update and supply the approved scope, the latest task status, and a client email. Those three sources have different jobs. The scope sets a boundary, the status describes progress, and the email provides a request to consider.

• Instructions say what the assistant should do and which constraints apply.
• Reference material provides facts or claims to evaluate, with its source attached.
• Work state explains what is complete, uncertain, blocked, or awaiting a person.
• Examples demonstrate a style or format without automatically making every detail a rule.

Labeling these parts helps people review them. Our context engineering guides cover the broader practice of choosing useful input, while the AI context window guide explains the space that input occupies.

How is useful context different from a prompt injection attack?

Useful context supports the request you authorized. A prompt injection attack tries to make an assistant follow instructions from material that should be treated as data. A page requested for research might contain text asking the assistant to ignore your task or send information elsewhere.

The OWASP prompt injection guidance↗ (opens in a new tab) describes both direct attacks in user input and indirect attacks inside external content. The issue is the attempted change of authority. A sentence does not become a valid instruction merely because a tool returned it.

Not every conflict is malicious. An old meeting note might say to use a retired brand name, while an approved decision requires the replacement. Treating both as equally current can still produce the wrong answer. Investigate the source and scope before deciding which text should govern.

Suppose the client email says to publish an unfinished draft immediately. The assistant can report that request, explain how it conflicts with the approval process, and prepare a draft for review. It should not turn the quoted email into permission to publish.

How do you keep instructions and evidence separate?

Begin with the task you actually authorized. State the goal, the material to consult, the output you want, and the actions that require approval. Then identify the source material as something to analyze rather than obey. Keep the approved rules in a separate, clearly named part of the request.

Include enough source identity to investigate a disagreement: a document name, link, section, or task reference. Avoid anonymous pasted paragraphs when the original is available. The context files comparison helps you understand where file-based instructions fit into this arrangement.

Clear labels improve understanding, but they are not a security boundary. OWASP explicitly distinguishes formatting from enforceable protection and recommends controlling permissions at the tool boundary. A connected application must enforce access even if the model misreads a malicious instruction.

For recurring project constraints, fenbs keeps people’s choices in Decisions and rules, where the assistant can distinguish an approved instruction from an unresolved proposal.

What should you check before allowing an action?

Review the proposed action against your original request. A summary task should not quietly expand into sending email, changing permissions, or deleting records. Check the target, the exact change, and the authority of the person who requested it.

For a tool-connected assistant, use the narrowest access that still lets it do the job. Read access may be sufficient for research. A person should review consequential actions with the details visible, rather than approving a vague promise to handle everything.

The Microsoft RAG overview↗ (opens in a new tab) explains retrieval-augmented generation, where relevant documents are fetched to support an answer, and identifies access control as a core concern. Retrieval makes material available to a model; it does not make every retrieved instruction legitimate.

A useful small test is to include a harmless source sentence asking for an unrelated action. Check whether the assistant reports it as source content rather than following it. Passing that example is evidence about that test, not proof that every future attack will fail.

How do you avoid carrying bad context into the next session?

Save conclusions with their limits. If an assistant saw a suspicious request, record what was found and what remains unresolved. Do not paste the instruction into a future rules list as if it were approved. Preserve the source link so another person can inspect the original.

Keep confirmed facts separate from interpretations. A client asked for a change is a fact about the email. The change is approved is a different claim that needs a decision. This distinction matters especially when a later assistant sees only the summary.

Review records when the project changes. The guide to AI context rot covers input becoming less useful or reliable; AI context optimization covers selecting and arranging input rather than establishing which sources have authority.

How to do this with fenbs

1. Create a free account and add the project whose instructions need a clear home.
2. Record the decisions a person has made in Decisions and rules. Identify the project scope and keep unanswered choices open.
3. Add the task and a plan that names the approved inputs, outside sources, expected result, and review needed before consequential actions.
4. Connect a supported assistant using the setup guides. Ask it to read the project context, apply the approved rules, and treat outside material as evidence to inspect.
5. Before stopping, save what changed, what was verified, and any conflicting source requests in the task and Where we left off.

fenbs is useful for keeping the work record and its human decisions available across sessions. It does not sanitize arbitrary web pages or provide an application security filter. If you are building an AI system, you still need tool permissions, input handling, and tests appropriate to the actions it can take.