FastGPT

FastGPT is a multi-tenant platform: each app runs inside its team, and a published app is bound to the list of knowledge bases and tools declared in its version, which the runtime checks before loading anything. Tools then act with whatever credentials the app designer stored for them, and the same credentials serve every user of the app, including anonymous visitors of a share link, who run as the app owner. The quick start documents a fixed default administrator password, and the shipped deployment's default access configuration is not locked down, so least privilege depends on the operator hardening the install. The platform-level credentials reach every tenant's data.

There is no approval step for tool calls. The tool-call and agent nodes execute whatever tool the model selects (HTTP requests, MCP tools, plugins, sub-apps, sandbox shell when enabled) without asking a person. Designers can place a user-choice or form step in a classic workflow, but it shows designer-written options rather than the exact call, and the tool-call and agent paths never pass through it. Consequential actions such as HTTP writes or messages sent through plugins cannot be undone.

Each app receives only the tools its designer selected, and the runtime refuses tools that are not declared in the published version. Outbound URLs from HTTP tools, MCP connections and file fetches go through a shared address check that always blocks loopback and cloud-metadata addresses and re-checks every redirect against a pinned DNS answer. Private-network addresses, including the deployment's own internal services, are only blocked when the operator turns on the internal-IP check, which is off by default. The HTTP tool itself stays general-purpose, with no host allowlists or quantity bounds.

The main application never executes code itself. Code nodes are sent to a separate code-sandbox service that runs each task in a fresh process inside a chroot, with a dropped user ID, no-new-privileges and a default-deny seccomp filter that blocks direct network access; outbound HTTP from code goes through a helper that blocks internal addresses and caps the number of requests. The optional Agent Sandbox, which gives the model a shell, runs in per-session containers created by OpenSandbox or Sealos with internal networks denied but public egress open by design. Turning off seccomp needs an explicit setting, and there is no fallback to running code on the host.

Nothing structural limits what a hijacked app can do. Knowledge-base quotes are wrapped in delimiter tags in the default prompt template and tool results arrive in the tool role, but web pages, uploaded files, MCP and HTTP results, and messages from public share-link visitors are not treated differently from instructions. In normal use an app reads untrusted content, holds team knowledge and tool credentials, and can send data out or change external systems through HTTP, MCP and plugin tools in the same run with no person involved.

The model has no long-term memory tool: knowledge bases are filled by people (uploads, imports, website and API sync), skills are saved and deployed as versions through an explicit action, and agent memory and variables live inside a single chat. Knowledge bases are team-scoped and chats are per user, enforced in queries. Imported knowledge-base content, including synced web pages, is not validated and has no expiry, and once in a knowledge base it is retrieved for every user of the app and can steer tool use.

Extensions come as system plugins served by a separate plugin service, team-installed plugins, and remote MCP servers. Plugin installs record the version, an etag and the permissions confirmed at install time, and team plugin installation is off unless the operator enables it; package verification itself happens in the plugin service, which is not part of this repository. MCP servers are remote URLs whose code and tool definitions are not pinned. No extension runs inside the main application process.

Credentials that designers attach to HTTP and MCP tools are encrypted at rest with AES-256-GCM, decrypted only when the request is sent, and left out of the recorded node responses, so they never reach the model. However, the shipped default configuration carries fixed secret values, including the key that protects those stored credentials, so the at-rest protection depends on the operator replacing them. Model provider keys and inter-service tokens are plain configuration values, logs have no redaction, and OpenTelemetry export is off unless configured.

Every node run, including tool calls, MCP and plugin tools and child apps, is stored as a structured row tied to the chat, which records the team member or share-link user. Team configuration changes go to a separate team audit log. Records live in the application database, are deleted together with chat history, and are written in batches; write failures are logged and the run continues.

Runs are bounded by a node-run budget (500 by default) that child apps draw from, by round caps in the agent loop (100) and tool-call node (50), by loop and parallelism caps, and by per-request timeouts. A stop request is polled every 100 ms and checked between nodes and model calls. There is no token or cost cap in the community setup (team AI-point budgets only apply with subscription plans), in-flight tool calls finish after a stop, and Agent Sandbox containers stay up until the inactivity timeout (60 minutes by default).