A common security misconfiguration in AutoGen deployments is the default use of code execution agents, such as `AssistantAgent` with `code_execution_config` enabled. This pattern, while convenient for prototyping, introduces an unacceptable risk profile for any operational workflow, as it grants the LLM the ability to run arbitrary Python code with the permissions of the host process.

The migration path involves replacing this open-ended execution with a strictly defined tool-calling interface. The core principle is to move from a model that says "execute any code you write" to one that says "you may only invoke these specific, reviewed functions." Below is a comparison of the default, unsafe pattern versus a restricted approach.

**Default, Unsafe Pattern:**
```python
from autogen import AssistantAgent, UserProxyAgent

user_proxy = UserProxyAgent(
name="UserProxy",
code_execution_config={"work_dir": "code"},
human_input_mode="NEVER"
)
# This agent can write and execute any code within the work_dir.
```

**Restricted Tool-Calling Pattern:**
```python
from autogen import AssistantAgent, UserProxyAgent, register_function

# 1. Define a secure, auditable tool.
def query_database(sql_query: str) -> str:
# Implement with parameterized queries, connection pooling, etc.
...

# 2. Explicitly register the tool for the agents.
register_function(
query_database,
caller=assistant, # The AssistantAgent that can request the tool
executor=user_proxy, # The UserProxyAgent that will execute it
name="query_database",
description="Runs a SELECT query against the reporting database."
)

# 3. Create agents with code execution DISABLED.
assistant = AssistantAgent(
name="Data_Assistant",
llm_config={"tools": [{"type": "function", "function": ...}]}, # Tool schema loaded here
code_execution_config=False
)
user_proxy = UserProxyAgent(
name="User_Proxy",
human_input_mode="NEVER",
max_consecutive_auto_reply=10,
code_execution_config=False # Critical: No arbitrary code execution.
)
```

Key migration steps:
* Conduct an inventory of all code execution agents in your workflow.
* For each required capability (file I/O, data query, API call), develop a dedicated Python function with strict input validation and sandboxing where applicable.
* Register these functions as tools, explicitly binding caller and executor agents.
* Disable `code_execution_config` on all agents. The workflow should now fail if the LLM attempts to generate arbitrary code, forcing all actions through the tool schema.
* Generate an SBOM for the final toolset dependencies to track third-party risk.

This pattern significantly reduces the attack surface, constraining the agent's actions to a known set of operations. The next layer of hardening involves signing the tool function artifacts and implementing principal-based permission checks within each tool, ensuring that even a compromised agent token cannot exceed its intended data access boundaries.