Instructions loaded from a referenced document or URL at runtime rather than from the reviewed skill package itself. They are risky because the linked content can change after review, turning a previously safe skill into a new behavior path without any change to the original file.
Runtime-loaded instructions and the trust boundary
Untrusted external instructions are risky because the instruction source is outside the reviewed package, so the behavior path depends on content that can change after review. That makes the effective control boundary the referenced document or URL, not just the original skill file.
This pattern matters most in systems that treat remote content as if it were part of the same trusted logic. A harmless-looking reference can later point to instructions that change intent, expand scope, or redirect the workflow without any update to the skill itself.
Why this changes security review
The key issue is not simply that the content is external, but that it is evaluated at runtime. If the referenced source can be edited independently, the security posture of the skill becomes time-dependent, and the original review no longer describes what the system will actually execute.
That creates a moving target for assurance. Reviewers may approve the package based on one version of the referenced material, while users later encounter instructions that were never examined during validation.
Common failure patterns
One common failure is assuming that a trusted repository or approved URL stays safe forever. Another is allowing remote instructions to override local safety rules, which lets the newest fetched content win over the intended behavior of the skill package.
Teams also miss the difference between a stable reference and a live dependency. If the referenced page, document, or prompt can be edited by a third party, then the instruction set can drift, be repurposed, or become a delivery point for malicious or simply incompatible behavior.
How to think about trust and control
Untrusted external instructions should be treated as mutable input, not as part of the immutable trusted core. When they are needed, the system should make clear whether it is consuming a fixed snapshot, a signed artifact, or live content that can change outside the release process.
That distinction determines whether the operator can reason about provenance, reproducibility, and reviewability. Without it, the skill’s behavior is only as stable as the remote page it references.
Risk and Threat Considerations
Runtime-loaded instructions widen the attack surface because an attacker, compromised publisher, or careless maintainer can alter the referenced content after approval. The resulting risk is behavior drift, where the system follows instructions that were never part of the original trust decision.
Failure mechanism: A referenced URL or document changes after review, or a dependency points to content that can be rewritten, causing the runtime instruction set to diverge from the approved one.
Impact: The skill may execute new, unsafe, or policy-violating behavior while appearing unchanged, which can undermine governance, validation, and incident traceability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP SAMM and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SA-9 — External System Services | Covers managing security dependencies on external sources used at runtime. |
| CM-3 — Configuration Change Control | Applies when referenced instructions can change after approval and alter behavior. | |
| SI-7 — Software, Firmware, and Information Integrity | Addresses integrity of content and inputs that can alter system behavior. | |
| Recommendation — Define and review controls for externally sourced instructions before allowing runtime use. Control and revalidate external instruction sources when their content changes. Verify the integrity of fetched instructions before treating them as trusted behavior. | ||
| OWASP SAMM | Software Governance | Supports governance of external dependencies that affect software behavior over time. |
| Recommendation — Track runtime-loaded instruction sources as governed dependencies in the SDLC. | ||
| SLSA | Supply chain integrity | Relevant when external content functions like a mutable supply-chain dependency for behavior. |
| Recommendation — Pin and verify instruction sources so behavior cannot drift silently after review. | ||
Practitioner Guidance
Why practitioners should care: This term is a governance signal, not just a documentation concern. If runtime instructions are allowed, teams need a clear rule for whether they are consuming immutable references, version-pinned snapshots, or live external content.
What to watch for: Any workflow that fetches instructions at execution time should be treated as a changing dependency, especially when the source can be updated without the skill package being re-reviewed. The practical question is whether the fetched content is part of the approved behavior or a separate, unbounded input.
Related resources from NHI Mgmt Group
- What breaks when an agent can read untrusted repository content as if it were instructions?
- How should security teams contain XML external entity risk in document processing pipelines that accept untrusted files?
- How should teams defend AI agents against prompt injection and hidden instructions in external content?
- What breaks in practice when untrusted text and trusted instructions are joined before the model sees them?
