Security: YAML agent config allows importing arbitrary stdlib modules via importlib

[KevinZhao]

🔴 Required Information

Describe the Bug:

The YAML agent configuration system uses importlib.import_module() to resolve code references (in fields like model_code, agent_class, callbacks, tools, and sub_agents) without any restriction on which modules can be imported. This allows referencing dangerous standard library modules such as os, subprocess, or pickle from YAML config files.

When YAML configs can originate from untrusted sources — such as the unauthenticated /builder/save endpoint exposed by adk web — this becomes an arbitrary code execution vector.

Steps to Reproduce:

1. Create a YAML agent config file with a stdlib reference:

   name: test_agent
   model: gemini-2.0-flash
   instruction: "test"
   before_model_callbacks:
     - name: os.system
       args:
         - value: "id"

2. Load the config via from_config() or through the web UI builder
3. The os module is imported and os.system("id") is executed

Expected Behavior:

YAML config code references should only resolve project-level and third-party modules. Standard library modules like os, subprocess, pickle should be rejected.

Observed Behavior:

Any Python module (including dangerous stdlib modules) can be imported and executed via YAML config fields.

Environment Details:

• ADK Library Version: 1.29.0 (latest)
• Desktop OS: Linux
• Python Version: 3.10+

Model Information:

• Are you using LiteLLM: No
• Which model is being used: N/A (issue is in config loading, not model interaction)

---

🟡 Optional Information

Affected code:

src/google/adk/agents/config_agent_utils.py — three importlib.import_module() calls:

• resolve_fully_qualified_name() (line 110)
• _resolve_agent_code_reference() (line 162)
• resolve_code_reference() (line 191)

How often has this issue occurred?:

• Always (100%)

[surajksharma07]

@KevinZhao The gap is in all three importlib.import_module() calls inside config_agent_utils.py (lines 110, 162, and 191) — none of them have any guard against stdlib modules being passed in.

A workaround worth trying: before each import, check sys.stdlib_module_names (Python 3.10+) against the top-level module name and raise a ValueError if it matches.
That should block os, subprocess, pickle, and the rest of stdlib uniformly without needing a manual blocklist.

Could you verify if that approach resolves it on your end and run it through a few edge cases before moving ahead with the PR?