Start by removing execution authority from the workflow step that reads untrusted content. If the job can reach a shell, package manager, or arbitrary network destination, it has already crossed the boundary that prompt filtering cannot protect. Make the first step read-only, then add explicit approval or a separate privileged job for any state-changing action.
Why the first control move is to remove shell access from the read step
An AI workflow that can turn untrusted text into shell commands is no longer just doing text processing. The risky boundary is the moment the workflow can influence a shell, package manager, or arbitrary network call. Once that exists, prompt filtering is a weak secondary control, not the primary safety barrier.
The safer design choice is to make the first step read-only and keep any state-changing action in a separate, explicit approval path. That separation matters because the content reader and the privileged executor have different trust levels, and they should never share the same authority by default.
That same separation principle also applies to platform and agent design. If a workflow step can invoke tools or act with the privileges of a broader agent, the control objective is to narrow the step’s authority before you try to tune the prompts or model output. For a broader roadmap on securing AI systems by layer, the AI Security Maturity Model frames the progression from discovery to governance and controlled execution.
What the trust boundary looks like in practice
The question is not whether the model can be persuaded to emit a bad command. The question is whether the workflow can do damage if it does. If the step can reach a shell, install packages, write files, or call out to the network, then untrusted text has crossed from input handling into action execution.
That boundary should be treated as an authorization decision, not a prompt-quality problem. A read-only step can inspect, classify, extract, or summarise untrusted content safely. A separate privileged job can then handle changes, but only after a human or a policy engine approves the specific action that will be taken.
This is why teams should design for least authority around the workflow, not only around the model. If the step needs to process content, it should not also be able to mutate systems, trigger package installs, or exfiltrate data through outbound requests. Where agent tool use is involved, the Agentic AI Security Policy Template gives a useful policy structure for separating routine processing from high-impact actions.
How to structure the safe pattern and what to verify first
Start with a simple rule: the component that reads untrusted text must not have execution authority. Then split the workflow into two stages, a low-privilege inspection stage and a privileged execution stage, with an explicit handoff between them. That handoff can be approval, a signed job request, or a separate queue, but it should be visible and auditable.
What to verify first is the actual blast radius of the current workflow. Check whether the step has shell access, package install capability, direct filesystem write access, secrets exposure, or unrestricted outbound network access. If any of those are present, the workflow is already too powerful for untrusted input handling.
For teams building AI systems with shared infrastructure, the AI Infrastructure Workload Identity Guide is relevant because it focuses on the identities behind pipelines, notebooks, training jobs, and inference systems, where overbroad authority often hides. If you need a tool-selection view of the same problem, the AI Security Platform Buyer’s Guide helps evaluate controls that reduce over-permissioned AI operations.
Risk and Threat Considerations
The main risk is not only prompt injection, it is command execution through an over-privileged workflow step. Once untrusted text can influence a shell or package manager, an attacker can pivot from content manipulation to code execution, data access, or outbound exploitation. The same pattern can also create supply-chain exposure if the workflow can fetch or install dependencies.
Failure mechanism: A workflow that was supposed to interpret text still retains execution authority, so malicious content can be transformed into a command, package action, or network request before any meaningful human review occurs.
Impact: The result can be system compromise, secret exposure, unwanted software changes, data loss, or a wider foothold if the workflow runs with broad credentials or network reach.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The workflow's authority boundary is the central abuse point. |
| ASI02 — Tool Misuse | Shell, package, and network actions are tool-use failures. | |
| Recommendation — Constrain agent privileges so untrusted input cannot trigger privileged actions. Restrict tools to approved actions and separate read from execute. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The issue is overbroad execution authority for a content-reading step. |
| IA-9 — Service Identification and Authentication | Separate privileged jobs need controlled service-to-service trust. | |
| Recommendation — Limit the workflow step to the minimum permissions needed for reading only. Authenticate the privileged executor separately from the read-only workflow. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Workflow permissions must be reduced before untrusted input is processed. |
| Recommendation — Review and remove unnecessary execution privileges from the workflow. | ||
Practitioner Guidance
What to prioritise: Remove execution rights before you add smarter detection. The first remediation is architectural, not linguistic, because filtering text cannot reliably compensate for a workflow that is allowed to act.
What to verify: Confirm that the read step cannot spawn a shell, install packages, write to production paths, or call arbitrary external endpoints. If any of those are still possible, the workflow is not yet safely compartmentalised.
Decision rule: If the action changes state, make it a separate privileged job with explicit approval and logging. If it only reads or classifies content, keep it in a restricted execution zone with no ambient authority.
Practitioner takeaway: Treat untrusted text as data until it reaches a deliberately gated executor. The safest AI workflow is the one where reading and acting are separated by design, not by prompt wording.
Related resources from NHI Mgmt Group
- How should security teams govern machine identity credentials in agentic AI environments?
- How should security teams manage permissions for AI agents?
- How should security teams govern AI agents that use OAuth access?
- How should security teams limit the risk from AI agents that have access to production systems?