A network assistant reads a vendor advisory, summarizes a ticket, and proposes a firewall change. The security question is not simply whether its answer sounds sensible: which component decides whether that change is permitted? In this GPT-6 Cyber campaign installment, we examine that boundary without making new claims about any particular model's capabilities.
OWASP defines indirect prompt injection as the influence of external material, such as websites or files, on an application's model behavior.[1] Its excessive-agency guidance explains why the consequences depend on available functionality, permissions, and autonomy.[2] The practical objective is therefore twofold: reduce untrusted instructions reaching privileged decisions, and constrain what any resulting tool request can accomplish.[1][2]
The dangerous transition: evidence becomes authority
An advisory, repository file, search result, or ticket can provide useful information without being authorized to direct the agent. OWASP distinguishes externally supplied indirect injections from instructions supplied directly through a user prompt.[1] Treating retrieved material as task data, rather than a new instruction source, is a basic mitigation in its guidance.[1]
Consider this deliberately non-executable example: a document about troubleshooting asks the assistant to perform an unrelated administrative action. The document's subject might make it relevant to the investigation, but relevance does not establish authorization. The recommended boundary is to extract technical observations while rejecting any attempt by the document to expand the requested task.[1][2]
OpenAI's agent-safety documentation warns against inserting untrusted variables into developer messages and recommends structured data between workflow stages.[3] For a network workflow, a useful design is to keep retrieved text attached to a source identifier and extract only required fields, such as affected product and software version. Those fields should support analysis, not silently grant permission to deploy a change.[3][6]
Excessive agency turns a bad decision into impact
OWASP identifies three recurring causes of excessive agency: unnecessary functionality, overly broad permissions, and excessive autonomy.[2] An assistant asked to summarize configuration differences should not automatically receive configuration-write access simply because its integration happens to offer it.[2] Similarly, a connector designed for reading tickets should not inherit unrelated administrative privileges.[2][6]
Tool names alone are not meaningful security boundaries. OWASP recommends granular functions instead of open-ended extensions such as general shell execution.[2] For a read-only troubleshooting assistant, prefer a bounded operation like retrieving an approved device's interface status over exposing a general remote-command interface.[2] Keep the downstream identity read-only as well; limiting the visible tool while retaining broad backend privileges leaves a separate authorization problem.[2][6]
A container or separate worker is not a substitute for deciding which downstream operations are permitted. In this reference design, runtime isolation is one layer, while the tool gateway and target service independently enforce the user's permitted resources and operations.[2][6]
Build a tool gateway that can say no
OWASP explicitly recommends implementing authorization in downstream systems rather than asking the model to decide whether an action is allowed.[2] Its authorization cheat sheet calls for deny-by-default behavior and permission validation on every request.[6] Apply those principles to every proposed agent tool call, including apparently routine reads.[6]
For this article's proposed network-operations design, the gateway should evaluate five concrete inputs:
- Identity: bind the request to the authenticated user and an appropriately scoped integration identity.[2][6]
- Resource: verify that the requested device, tenant, repository, or ticket belongs to the allowed scope.[6]
- Operation: distinguish inspection, drafting, deployment, and deletion instead of treating them as one permission.[2][6]
- Arguments: validate the requested action against narrowly defined tool functionality and permitted resources.[2][6]
- Approval: require an independently checked approval before a high-impact operation proceeds.[2]
Do not accept a model-generated assertion that approval already happened. The approval decision should come from a trusted workflow component, consistent with OWASP's recommendation for independent confirmation of high-impact actions.[2] Log denied requests as well as successful ones so operators can investigate repeated attempts without granting extra privileges.[2][6]
Structured output is useful, but authorization remains separate
OpenAI recommends fixed schemas, enumerated values, and required fields to constrain data passing between nodes.[3] Its documentation also states that structured outputs and isolation reduce, but do not eliminate, prompt-injection risk.[3] In this design, a schema narrows the form of a proposal; it does not determine whether the requested resource belongs to the user.[3][6]
For example, make the analysis stage return an affected-device identifier, a finding category, and a suggested next step from a small approved set. Then validate resource ownership and permissions in application code before retrieving additional information or preparing a change.[3][6] Avoid a catch-all field that the execution service interprets as arbitrary instructions, following OWASP's recommendation to minimize extension functionality.[2]
Keep raw source material available for review, but do not pass every retrieved paragraph into the privileged execution stage. That separation is a proposed implementation of OpenAI's guidance to extract specific fields rather than let untrusted data directly drive behavior.[3]
Make human approval specific enough to matter
OWASP recommends human approval for privileged or high-impact operations.[1][2] Approval is most useful when it addresses a concrete action, not a vague request to continue. For this reference workflow, present the affected devices, intended operation, proposed configuration difference, and expected scope before asking the operator to approve.[2][6]
Treat the approval as applying to that reviewed proposal only. If the resource set or operation changes, request a fresh decision rather than extending the previous one. This is a recommended application of per-request permission checks and independent high-impact approval, not a claim that any particular platform implements those semantics automatically.[2][6]
For unattended jobs, preauthorize only a narrow class of operations and reject requests outside it. OWASP's least-privilege and complete-mediation recommendations still apply when no person is available to review an unexpected action.[2][6]
Practical checklist and a safe acceptance test
Use this checklist before connecting an assistant to operational systems:
- Inventory retrieved-content sources and mark external material as untrusted.[1]
- Remove tools and functions the assigned workflow does not need.[2]
- Scope downstream identities to the current user's permitted resources.[2][6]
- Enforce authorization outside the model and deny unmatched requests.[2][6]
- Validate every tool request, not merely the first request in a session.[6]
- Require independent confirmation for high-impact actions.[2]
- Monitor tool activity and apply rate limits where appropriate.[2]
Test these controls in an isolated demonstration workflow using synthetic tickets and simulated devices. OWASP recommends adversarial testing of trust boundaries and access controls.[1] Include benign documents that discuss instructions, as well as documents that request actions outside the assigned task. The proposed acceptance criterion is that the assistant can still summarize relevant content while the gateway rejects every unauthorized operation.[1][6]
Review both decisions and downstream activity, not just the final natural-language answer. OWASP recommends logging and monitoring extension activity, and its authorization guidance recommends unit and integration tests for permission logic.[2][6] Record false refusals alongside blocked requests so the workflow remains useful without relaxing resource boundaries.
Takeaway
Prompt-injection resistance is not permission enforcement. OWASP's combined guidance supports minimizing tool capability, narrowing credentials, independently authorizing requests, and retaining human control over high-impact operations.[1][2][6] For a practical deployment, start with one read-only workflow and prove its boundaries before enabling changes. The standard should be clear: external content may inform a proposal, but it cannot authorize execution.[2][6]
Sources
- [1] https://owasp.github.io/www-project-top-10-for-large-language-model-applications/2_0_vulns/LLM01_PromptInjection.html
- [2] https://owasp.github.io/www-project-top-10-for-large-language-model-applications/2_0_vulns/LLM06_ExcessiveAgency.html
- [3] https://developers.openai.com/api/docs/guides/agent-builder-safety
- [6] https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
Post a Comment