[Security] Arbitrary File Loading and Logical Hijacking via Unvalidated --path Parameter

Issue Summary
In the CLI entry script (run.py), the --path parameter lacks strict directory traversal checks and load-source whitelisting. This allows the application to load unauthorized YAML workflow configurations from arbitrary locations, potentially leading to the logical hijacking of the underlying agent framework.

Root Cause Analysis
Based on static code analysis, the vulnerability exploitation chain is as follows:

1. Unfiltered Parameter (run.py): In parse_arguments(), the --path argument accepts external input and converts it to a Path object without verifying if it resides within the expected directory (e.g., yaml_instance/). This permits path traversal payloads such as ../../../../tmp/evil.yaml.

2. Blind File Reading (check.py): The load_config() function receives the unvalidated config_path and reads the file directly using read_yaml(), introducing external, untrusted content into the application context.

3. Implicit Trust during Instantiation (graph_config.py & check.py): Once the configuration data passes a basic schema format check, it is passed directly into the from_dict() method. The system implicitly trusts this dictionary and instantiates the underlying GraphConfig and GraphDefinition objects, translating untrusted YAML directly into the framework's core execution logic.

Security Impact
If the framework is exposed in a multi-tenant environment, behind a Web API, or in any scenario where external users can control startup parameters, an attacker can specify a malicious YAML configuration. This allows them to inject untrusted instruction sets, alter agent workflows, or grant unauthorized tool execution permissions, ultimately hijacking the core logic of the application.

Steps to Reproduce (Static Analysis)

1. Create a syntactically valid malicious_workflow.yaml containing malicious node instructions in a non-standard directory (e.g., the system's /tmp/ directory).

2. Trigger the execution via the CLI using a path traversal payload:
   python run.py --path ../../../../../tmp/malicious_workflow.yaml

3. The framework will load the file, instantiate the graph configuration, and execute the attacker-controlled workflow.

Suggested Mitigation
Implement robust path validation in the loading logic of run.py or check.py:

-Path Normalization and Validation: Use Path.resolve() to resolve the absolute path, and then use is_relative_to() to ensure the target file strictly resides within the expected, trusted workflow directory (e.g., the project's yaml_instance/ folder).

-Extension Whitelisting: Explicitly verify that the loaded file ends with a .yaml or .yml extension.

Trace the CLI path from parse_arguments() in run.py through load_config() and read_yaml() in check.py to GraphConfig and GraphDefinition construction in graph_config.py. Confirm the trusted workflow directory and existing configuration-loading behavior first. Done means rejecting paths outside that directory and files without .yaml or .yml extensions while retaining valid workflow loading.