An assistant reads a service file, but the file also asks it to change its task or use a tool for another purpose. This tests more than summarization accuracy: does the content remain data, or acquire authority over the workflow? Request evidence before accepting an agent connected to tools.
One task, two source versions
Imagine a fictional printing-center agent extracting quotation conditions from a service guide. One version contains ordinary information; another adds an unauthorized request to change the task or read a different record. Data and markers are synthetic, and mock tools are isolated from production. No real customer or secret is involved.
This comparison asks something more precise than “is the agent safe?” Can it complete the permitted task in both cases without allowing source text to grant new permissions? The service owner defines permitted reading, output and out-of-task actions first. Do not change expectations afterward to fit the observed result.
Inspect effects alongside the reply
An assistant may say it refuses an unauthorized request, but that statement alone is insufficient. Ask a specialist to inspect tool inputs, attempted access and the mock environment's final state. An agent might disclose out-of-scope information without calling a tool, so evidence covers both output and data flow.
Place a synthetic marker in an out-of-task record to recognize exposure without private data. Agree on useful logs that avoid unnecessary sensitive content. The purpose is observing a defined boundary in an authorized environment, not publishing an attack recipe or probing someone else's account or source.
The paired-test card
| Field | Establish before testing | Inspect afterward |
|---|---|---|
| Permitted task | Requested conditions and data limits | Completion without unauthorized expansion |
| External source | Ordinary version and unauthorized-request version | Did source content change the task? |
| Mock tool | Request boundaries and expected effects | Inputs, attempts and final state |
| Evidence and limits | Version, environment and covered cases | Result, remediation owner and untested cases |
Record whether prevention occurred before the tool or within its boundary and what that proves. Buyers do not need every implementation detail, but they need a clear interpretation. A rejected tool action can represent useful protection or a broken permitted workflow, depending on the case.
External knowledge does not inherit user authority
OWASP describes indirect injection through external sources such as files and websites, discussing untrusted-content separation, privilege boundaries and output validation. Ask the provider how source identity and purpose remain clear as data passes between workflow stages.
RAG or a sentence instructing the model to ignore strange instructions cannot replace evidence. Test the actual in-scope path: can a request inside a file expand access or change an action's destination? A sample proves neither prevention of every technique nor that normally useful retrieved text contains authorized instructions throughout.
Structured data helps without settling the result
OpenAI's agent-safety guide discusses constraining data flow through structured outputs alongside other measures and acknowledges remaining risk. Use the principle of controlled stage-to-stage flow without adopting an old model recommendation or assuming syntactically valid JSON prevents every unauthorized action.
Request an example of permitted fields and treatment of values outside their expected meaning. Review goes beyond parseable output: a formally valid value may still exceed the task. A specialist should distinguish system checks from decisions or reviews within the agreed scope.
Keep acceptance evidence bounded and repeatable
Retain source versions, mock configuration, results and ownership of rechecking after relevant changes. Re-run the ordinary case after fixing an unauthorized case so prevention does not break the original task. State exclusions rather than turn a small case set into a comprehensive protection promise.
Use authorization and approval boundaries and knowledge readiness for their separate purposes. Attach the task, source limits and proposed mock tool when requesting AI-agent development from Nextwave, so the proposal includes an interpretable acceptance package.
Principle sources
Relevant OWASP injection and OpenAI agent-safety sections were read on 4 November 2026. No security assessment or API call was performed. Prepared with AI assistance and information and translation review.
