BabyAGI (functionz)

BabyAGI keeps one global store of secret keys and injects every stored key into the scope of every function it executes, whatever that function declares it needs. Access control on the dashboard and REST API that run functions is not locked down. Registered tools can also add or overwrite stored keys and read them all back.

There is no approval step anywhere. Functions run directly from the HTTP API and from model tool calls in the chat, including the default function that adds new code to the system. Function code is versioned so a code overwrite can be rolled back, but anything the code does (package installs, external API calls, file writes) happens immediately.

The default tool set includes a function that stores arbitrary model-supplied Python code and imports, and every function can be called with any arguments; the only check is that required parameter names are present. In the chat, the user picks which functions the model sees, which is the one real narrowing, but the HTTP API can call any function directly.

All function code, including code a model writes through add_new_function or a caller pushes through the API, runs with Python exec() inside the server process, and any import it lists is pip-installed on the host. There is no sandbox on this path and every stored secret is in the executing scope. An optional E2B plugin can run code in a remote sandbox, but it is not loaded by default and only covers code explicitly passed to it.

Nothing separates untrusted content from instructions. Tool results go back to the model without marking, and the handling of chat input and rendered model output is not locked down. A hijacked model can call add_new_function to run arbitrary code or read all secrets if those functions are offered.

The framework's state, including all function code, triggers and keys, lives in a SQLite file and an encryption-key file resolved relative to the current working directory, shared by every user of the server. The model can write new persistent code through add_new_function, and that code runs in later sessions. A funztionz.db already present in the working directory is loaded as-is, and its functions and triggers run when default packs register on import.

Any import name stored with a function, including one supplied by the model through add_new_function, is pip-installed on the host at execution time if it isn't already importable, with no pinning, hash, or consent. Installed packages run in-process with every secret. The chat page also loads its Markdown renderer from a CDN without a pinned version.

Stored keys are Fernet-encrypted in the database, but the encryption key sits in a plaintext JSON file next to it, and secret material is exposed through further output paths. The default pack's get_all_secret_keys function returns every key in plaintext to its caller. The chat function turns on LiteLLM's verbose logging by default.

Every function execution goes through one executor that writes a structured log row (function name, parameters, output, timing, status, parent and trigger links) before the code runs. That is a usable trail of calls, but it has no record of who requested a call, lives in a database file in the working directory that executed code can modify, and does not record what happens inside a function.

The core has no step, time, or cost limits and no way to stop a running function. The default chat makes at most two model calls per request and trigger chains skip functions already run in the chain, which bounds those loops, but any function (including model-written ones) can run forever in the server process.