They turn prompt or input handling into an execution path. If code execution, arbitrary requests, or similar features are left enabled, a crafted prompt can become server-side command execution, internal network access, or data exfiltration. The key failure is not the model itself but the framework’s willingness to treat untrusted text as trusted instruction.
Why Dangerous Framework Features Break Trust Boundaries
LLM frameworks fail at the point where convenience turns untrusted text into execution. Once code execution, shell access, file access, or unrestricted network requests are available, the framework is no longer just formatting model output, it is mediating real system actions. That changes the security boundary: the prompt becomes a control input, and the application must treat every model-generated action as potentially hostile or malformed.
Two things typically break together. First, the application’s assumption that model output is advisory rather than executable. Second, the containment model that should keep the framework from reaching sensitive files, internal services, or external endpoints. This is why request helpers, tool wrappers, and sandbox shortcuts are so dangerous when they are enabled by default or exposed to raw prompt content. In practice, many teams only discover the weakness after a harmless-looking prompt has already triggered a privileged side effect.
For broader agentic risk context, the OWASP OWASP Top 10 for Agentic Applications 2026 is useful because it maps the security failures that appear when model-driven actions escape proper control.
How It Works in Practice
The practical failure pattern is usually a chain, not a single bug. A framework exposes a helper for running code, fetching URLs, or reading local resources. The application passes model output, tool arguments, or prompt-derived text into that helper without a strict allowlist, a sandbox, or explicit user approval. The result is that the model can be induced to perform actions the developer did not intend to make reachable from arbitrary input.
Common manifestations include:
- server-side command execution through code runners, template hooks, or unsafe eval-like behavior;
- internal network access through request helpers that can reach metadata services, admin APIs, or private hosts;
- data exfiltration when the framework can read files, environment variables, or secrets and then transmit them out;
- unexpected escalation when tool use inherits more privilege than the prompt or user session should have.
The control problem is not limited to one language or one framework. Any system that lets model-generated content drive execution, retrieval, or transport needs strict separation between interpretation and action. That is why secure deployments usually add sandboxing, allowlisted destinations, bounded file access, explicit tool permissions, and auditing of every action path. If the framework can reach secrets or internal services, a crafted prompt can abuse those capabilities without ever needing to “break” the model itself.
NHIMG’s AI Agents: The New Attack Surface report is a strong indicator of how quickly autonomous systems exceed intended scope in real environments, with 80% of organisations reporting agent actions beyond scope and 31% reporting inappropriate sensitive-data sharing. These controls tend to break down when teams assume the framework’s default tool permissions are safe enough for production.
Common Variations and Edge Cases
Tighter execution controls often slow development and reduce flexibility, so teams have to balance developer convenience against blast-radius reduction. That tradeoff becomes sharper when the framework is used for internal automation, where broad permissions may seem efficient but create the easiest path to misuse.
One common edge case is “safe” request functionality that is only safe in appearance. URL fetchers, browser helpers, and retrieval plugins can still reach internal hosts, cloud metadata endpoints, or attacker-controlled destinations if destination validation is weak. Another is partial sandboxing, where code runs in a container but still inherits sensitive environment variables, mounted credentials, or outbound network access. In those cases, the sandbox exists, but the containment is incomplete.
Best practice is evolving toward explicit trust tiers: read-only model interaction by default, narrowly scoped tools for approved actions, and separate approval paths for anything that can execute code or access the network. Where the framework cannot enforce those boundaries cleanly, the safer pattern is to move the dangerous capability out of the model loop entirely and require a conventional application control path.
When the framework is used for internet-facing workflows, the edge case that matters most is not whether the prompt is malicious, but whether one malformed or injected instruction can cross from text handling into privileged execution before monitoring or review can intervene.
Risk and Threat Considerations
These features create a classic privilege and trust-abuse risk: untrusted input can become a command path, request path, or data-access path. That expands the attack surface from prompt manipulation to server-side compromise, internal reconnaissance, and secret exposure.
Failure mechanism: The attacker supplies text that the framework interprets as instructions for a tool, code runner, or fetch operation. If permissions are broad enough, the resulting action can access local files, call internal services, query metadata endpoints, or exfiltrate data to an external destination.
Impact: The application can suffer remote code execution, unauthorized network access, leakage of credentials or sensitive records, and loss of trust in any downstream action the framework performs on behalf of the model.
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 — Tool and Action Abuse | Covers model-driven tool use turning prompts into unsafe actions or execution paths. |
| A5 — Excessive Agency | Directly addresses frameworks that grant autonomous actions beyond intended scope. | |
| Recommendation — Restrict tool permissions and require explicit approval for actions that can execute code or reach networks. Constrain autonomous actions to the minimum privilege needed for each workflow. | ||
| CIS Controls v8 | 6 — Access Control Management | Applies to restricting execution paths, network reach, and privileged resource access. |
| 8 — Audit Log Management | Relevant because dangerous framework actions must be attributable and reviewable. | |
| Recommendation — Limit who and what can run code, access files, and call sensitive internal services. Log every tool invocation, request target, and execution result for detection and review. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Matches code execution paths exposed through unsafe framework features. |
| T1105 — Ingress Tool Transfer | Applies when frameworks can fetch payloads or send data over arbitrary requests. | |
| Recommendation — Detect and block scripted execution spawned from prompt- or tool-driven inputs. Monitor and restrict outbound request paths that can move data or payloads. | ||
Practitioner Guidance
What to prioritise: Treat any feature that executes code or makes arbitrary requests as a privileged capability, not as a convenience API. The first question is whether untrusted model output can reach it without an explicit policy gate, because that is where the boundary failure starts.
What to verify: Confirm that code runners are sandboxed, outbound requests are destination-allowlisted, local file access is tightly bounded, and secrets are not available in the same runtime context as the model tool chain. If any of those conditions are missing, assume the framework can be steered into unintended action.
Practitioner takeaway: The safest design is not “trust the model less,” it is “make dangerous capabilities unreachable by default and observable when they are allowed.”
Related resources from NHI Mgmt Group
- How should security teams reduce the risk of unauthenticated remote code execution in BI platforms that expose datasource and SQL preview features?
- What breaks when teams let two LLM frameworks control the same execution path?
- What is the difference between prompt injection and LLM remote code execution?
- What breaks when a web framework can be exploited for remote code execution?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
