"Skipping dangerous attribute" logger level

[piotrgoral]

Logs issue

I've wrapped smolagents.CodeAgent in a FastAPI app and noticed that when running the generated code with imports, thousands of INFO-level logs are produced by LocalPythonInterpreter, such as:

2025-02-15 19:16:23,417 - INFO - Skipping dangerous attribute pandas.io.formats.printing.Any
2025-02-15 19:16:23,418 - INFO - Skipping dangerous attribute pandas.io.formats.printing.Callable

Full log from single run in the attached app.log.

Would it be possible to adjust the logger level for these messages to DEBUG? This would help reduce log clutter during regular FastAPI execution.

Here's minimal example:

import os
import logging

from fastapi import FastAPI

from smolagents import CodeAgent, LiteLLMModel, LogLevel

OPENAI_API_KEY = os.getenv("OPENAI_API_KEY")

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s - %(levelname)s - %(message)s",
)

logger = logging.getLogger(__name__)

model = LiteLLMModel(
    model_id="openai/gpt-4o-mini",
    api_key=OPENAI_API_KEY,
    seed=42,
)

agent = CodeAgent(
    model=model,
    tools=[],
    add_base_tools=True,
    additional_authorized_imports=["pandas"],
    verbosity_level=LogLevel.DEBUG,
)

app = FastAPI()


@app.get("/execute")
async def execute():
    logger.info("Executing agent")

    prompt = """Write code to import pandas and print version
    Return final_answer(code)
    """

    response = agent.run(prompt)

    return response


if __name__ == "__main__":
    import uvicorn

    uvicorn.run(
        app,
        host="0.0.0.0",
        port=8000,
        log_level="info",
    )

Run it locally

• Terminal 1: uvicorn minimal_example_agent:app --reload
• Terminal 2: curl -X 'GET' 'http://0.0.0.0:8000/execute'

Additional question

Lastly, I’m curious about how dangerous_patterns are applied at any levels. As seen in the logs, modules like pandas.io.formats.printing.Any are being excluded simply because their path contains 'io', even though they don’t actually use the io library.
Would it be possible to modify the logic to check only the top-level module against dangerous_patterns, rather than filtering based on any part of the path?

[albertvillanova]

Hi @piotrek-grl, thanks for opening this issue.

I would say that precisely logging these messages as INFO instead of DEBUG allows users to notice that the handling of dangerous_patterns could be definitely improved in this case... 😅

I agree current implementation to exclude dangerous patterns is too simplistic. Any idea how to improve it for this case? CC: @aymeric-roucher

• pandas.io.formats.printing.Any

Related corresponding PR, where we excluded io also in non-root package levels:

• Fix subpackage import vulnerability #238