Separate what the assistant reads from what it may do
A supplier PDF can provide facts for a summary without being allowed to change the rules for payment or sharing. An incoming support message can describe a customer problem without granting access to other customers’ records. This distinction is easy for a person to state but must also be reflected in the application and connected systems.
OWASP’s LLM01:2025 describes direct injection through input and indirect injection through outside content. It also notes that retrieval-augmented generation and fine-tuning do not remove the issue. The practical consequence is to examine the workflow’s trust boundaries instead of judging safety from the apparent quality of a summary.
Do not turn every unusual sentence into a confirmed security incident. Record the source, the behavior observed and the potential reach. A confusing answer, a suspected manipulation and a verified unauthorized action require different evidence and follow-up. The business should be able to describe which of those it actually knows.
Draw the path from an outside source to a business consequence
List the entry points: uploaded documents, retrieved pages, messages, database notes and results returned by tools. Then identify what information is available in the same workflow and which operations the application can request. A read-only public FAQ assistant has a different consequence boundary from a connected assistant that can email documents or edit customer records.
Use the table to ask where a decision is enforced. A sentence telling the model not to disclose information is useful guidance, but it is not the same control as withholding access to that information. Likewise, an output marked “approved” is not evidence of approval by an authorized person.
| Stage | Business question | Evidence to request |
|---|---|---|
| External source | Who can place or alter this content? | Source provenance and whether it is treated as untrusted input |
| Retrieval | Which documents can this user actually retrieve? | Access checks before content reaches the model |
| Model output | Is this a draft, proposed instruction or attempted operation? | Defined output handling and permitted workflow |
| Connected tool | What identity, records and actions are available? | Actual scopes and downstream authorization |
| Sensitive action | Who approves the exact recipient, object and change? | Enforced transaction-specific approval outside model text |
| Follow-up | Can the owner stop the workflow and trace events? | Revocation route and appropriately limited logs |
Test a fictional document without opening a live action path
An initial review can use invented content and a disconnected test workflow. Establish the expected legitimate result first. Observe whether unrelated material changes the answer or causes the application to propose an operation outside the task. The point is to verify the boundary and record a failure clearly, not to experiment against customer mailboxes or publish an attack recipe.
Keep test records synthetic and the destination controlled. If a tool may send, edit or delete, disable or safely stub that capability for the exercise unless a separately authorized controlled test specifically includes it. A screenshot of a refusal is only one observation; it does not establish that every wording, source or connected route is protected.
Enforce permissions where the real action happens
Give the workflow only the records and operations required for the business task. Separate preparation of a proposed change from execution. Before a sensitive operation, present the actual object, recipient and effect to an authorized reviewer; check authorization again when the tool executes. The model must not be able to create its own approval merely by emitting a phrase or changing a field.
OWASP’s excessive-agency guidance places downstream authorization and high-impact approval outside the model’s judgment. Apply that principle to the integration you actually control: a narrow draft operation is preferable to an unnecessary general-purpose action interface. Keep access scoped to the relevant user and business context.
Read-only does not settle confidentiality. An assistant able to read the whole drive can still include inappropriate information in an answer. Review retrieval scope, audience and output destinations alongside write permissions. Do not place secrets in system instructions as a substitute for a proper credential store and tool boundary.
Use prompts and filters as layers with stated limits
Clear task instructions, separation of external material and checks on output can reduce mistakes and make the workflow easier to inspect. They belong alongside authorization, minimal data exposure, controlled operations and review. Avoid a success criterion that consists only of a stronger system prompt or a list of blocked phrases.
Also review the wider environment. An assistant may receive information from a connector, then pass a result to another automation. Each handoff needs its own allowed inputs and operations. A safe-looking first response does not prove that a later integration will treat its content safely. Changes to a source, model, retrieval configuration or tool can invalidate a previous observation.
Document limits honestly. A scoped test can show what happened under the tested conditions and help prioritize controls. It cannot establish that prompt injection is impossible or that an organization has achieved a universal AI-security certification.
Define containment and the next responsible review
If suspicious behavior appears, stop further sensitive operations through the owner’s supported control, preserve the relevant times and event references, and examine the connected system for actual actions. Avoid broad account deletion or loss of logs during triage. Revoke or restrict affected access in coordination with the people who own the business dependencies.
CyberFixCrew is an Israeli cybersecurity company serving worldwide businesses. We bring practical Israeli website and digital-infrastructure knowledge to discussions about account scope, integrations and operational boundaries. Describe the affected workflow and available evidence first. Any specialist application assessment or additional work needs an explicit scope; this guide does not claim a deployed AI platform or red-team credential.
A useful handover names the source, permitted task, connected identity, potentially exposed records, actual operations and open questions. Link each proposed correction to a repeatable acceptance check and a responsible owner. That turns an abstract AI concern into a bounded business-security decision.
