What do teams get wrong when they let agents load files, models, or configuration from untrusted sources?

A common mistake is assuming the load step is harmless. With serialized objects, YAML, or similar formats, code can execute during deserialization before the agent even uses the content. Teams should prefer non-executable formats such as JSON or safetensors, and restrict any unavoidably dangerous loader with strict class and module allowlists.

Why the load step is the dangerous part

Teams often treat loading as a passive read, but many file formats are not passive. Deserialization, dynamic object construction, parser hooks, and embedded references can trigger code execution or dangerous side effects before the agent ever inspects the content. The real risk is not just bad data, it is giving an untrusted source a chance to shape the process that loads it.

That is why the safest default is to separate “content ingestion” from “execution-capable parsing.” Formats designed for data exchange, such as JSON, reduce the attack surface because they do not need object instantiation semantics. For model artifacts, safer container formats such as safetensors avoid the class of loader behaviour that can turn a model file into an execution path.

What makes agents especially exposed

Agents magnify the problem because they are often wired to fetch files, models, plugins, or configuration automatically, then act on them with broad runtime permissions. That turns a single untrusted download into a potential trust boundary break. If the agent can reach secrets, tools, or internal systems, a malicious file can become a foothold rather than just a corrupted input.

The practical mistake is assuming the source is “just configuration” or “just a model.” In agentic workflows, those inputs can steer tool choice, change permissions, alter prompts, or influence downstream actions. An apparently harmless loader can therefore become part of the agent’s control plane, which makes source trust and parser behaviour equally important.

For teams building or evaluating agent systems, AI Coding Agents Security Guide is useful for understanding how untrusted context, developer credentials, and sandbox boundaries interact in real agent workflows. The broader identity and delegation model is covered in Agentic AI Identity Guide, and the authority decisions that limit what an agent may do are detailed in AI Agent Authorisation Guide.

Safer patterns for files, models, and configuration

The strongest pattern is to treat untrusted inputs as data only, then validate them before any object reconstruction or privileged action. Prefer formats and libraries that are explicitly non-executable, keep parsing in a constrained runtime, and deny any loader features that can import classes, invoke constructors, or resolve external references.

Where a dangerous loader cannot be avoided, scope it tightly. Use strict allowlists for classes, modules, schemas, and paths, and make the allowlist narrow enough that a new type must be reviewed before it can be loaded. Keep this separate from generic input validation, because format validation alone does not stop execution during parse time.

Use non-executable formats where possible, especially for agent-consumed config and model artifacts.
Load untrusted content in a sandbox or minimal-privilege helper process.
Block arbitrary object creation, code loading, and reflective import behaviour.
Require explicit allowlists for every loader path that can reach privileged state.
Rotate or revoke any secrets that may have been exposed during a compromised load.

Risk and Threat Considerations

Untrusted loaders create a fast path from content ingestion to code execution, which can turn a malicious file into remote execution, credential theft, or hidden persistence. In agent environments, the impact is amplified because the same process may also hold tool access, API keys, or internal network reach.

Failure mechanism: A parser or deserializer instantiates attacker-controlled structures, triggers hooks, or follows embedded references before the agent has any chance to vet the content. If the loader runs with broad permissions, the attacker inherits those permissions at parse time.

Impact: The agent may execute unintended code, leak secrets, corrupt model behaviour, or perform actions on behalf of the attacker. In the worst case, one untrusted file becomes an execution primitive across the agent runtime, its tools, and any connected systems.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 define the specific risk controls and attack patterns relevant to this topic.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Untrusted loaders can expose credentials embedded in files or configs.
	NHI-06 — Insecure Cloud Deployment Configurations	Agent-loaded configuration can alter runtime trust and access boundaries.
	NHI-07 — Long-Lived Secrets	Files and configs often contain durable credentials that amplify loader compromise impact.
Recommendation — Keep secrets out of loadable artifacts and rotate anything exposed by parsing. Validate config sources and reject any untrusted deployment settings before activation. Replace durable credentials in loadable files with short-lived, scoped alternatives.
OWASP Agentic AI Top 10	ASI05 — Unexpected Code Execution	Deserialization and parser hooks can execute code before the agent uses the content.
	ASI02 — Tool Misuse	A compromised load step can steer an agent into unsafe tool or action selection.
	ASI03 — Identity & Privilege Abuse	Loaded content can abuse the agent's authority if parsing runs with excessive rights.
Recommendation — Prevent loaders from instantiating executable objects or invoking unsafe parser behaviour. Constrain agent inputs so untrusted content cannot influence tool selection or execution. Enforce least privilege around agent loaders and separate parsing from privileged actions.

Practitioner Guidance

What to verify: Confirm whether the loader can execute constructors, import modules, deserialize arbitrary objects, or resolve external references. If any of those are true, treat the format as execution-capable and require a tighter trust model than ordinary file validation.

Decision rule: If the content comes from outside your trust boundary, load it only through a non-executable format or a restricted parser with allowlists. If the loader cannot be constrained, move the parse step out of the privileged agent process and into a disposable, low-rights boundary.

Common mistake: Teams often secure the agent’s reasoning loop but forget the ingestion path. The first dangerous operation may happen before policy checks, tool gating, or human review ever run, so the load step itself must be considered part of the security boundary.

Practitioner takeaway: Assume every untrusted load path is a potential execution path until proven otherwise, and design the parser, runtime, and permissions so a hostile file cannot become a hostile action.