OpenOps

The assistant's OpenOps tools run with a service token minted from the logged-in user's session. It carries the same user and project, lives for 7 days by default, and is handed to a Python MCP subprocess. The optional AWS cost tools get a connection's raw long-lived access key and secret. The community build never checks the per-route permissions it declares, so the token holds the user's full project authority. The assistant can also rewrite the AWS connection that supplies its own cost-tool credentials, including its roles and endpoint.

The community build has no approval gate for the AI assistant. The function meant to wrap tools with approval returns the tools unchanged. So the assistant can re-run workflow runs, which may de-provision cloud resources or send messages, and can rewrite stored connections with no human confirming. The workflow engine has its own approval blocks, but they only apply where a workflow author placed them and never gate the assistant's own calls.

The assistant does not get a generic shell or HTTP tool. Its OpenOps tools come from a fixed allowlist of API paths and methods, every call is checked against the API's typed schemas and the user's project, and the table tools are limited to list operations. But the default set still includes two writes that the operator cannot turn off: re-running a workflow and patching a connection. Nothing restricts what a patched connection may contain, so endpoints, base URLs and roles can be set to any value.

Code steps run inside a V8 isolate (isolated-vm) with a memory limit and no host functions, which is a meaningful barrier. The main cloud-operations paths run as ordinary worker subprocesses with no sandbox: AWS/Azure/GCP CLI steps (which the assistant helps draft), bash-wrapped hcledit/yq steps, and npm installs of code-step dependencies with install scripts enabled. The engine process those paths run in holds the platform encryption key, the Redis password and decrypted cloud credentials, and has full network access. Execution-mode configuration is not tamper-resistant.

The assistant reads workflow run outputs, table rows and remote documentation search results. Those can carry text from webhooks, emails, chat messages, tickets and cloud tags, and they enter the conversation as ordinary tool results with no marking that they are untrusted. A hijacked assistant can re-run workflows without anyone approving. It can also patch stored connections, and that path is not locked down and can leak credentials with no human involved. The shipped content security policy blocks the common trick of leaking data through markdown images.

Chat history is stored in Redis per chat, user and project for 30 days, and it is fed back to the model on later turns, untrusted tool output included. Tools used earlier in a chat stay selected for later turns. The bigger issue is that the assistant can permanently change project-wide connection settings, such as endpoints, base URLs and roles, with no review. Every later workflow run, and every other user of the project, then inherits the change. System prompts are fetched at runtime from the vendor's GitHub main branch.

Users cannot add MCP servers or plugins from inside the product. The bundled OpenOps MCP server is pinned to a commit with a frozen lockfile, and the AWS cost servers are pinned to a release tag, though their Python dependencies are re-resolved from PyPI on each build. Code steps install the npm dependencies listed in their package.json at run time, and the assistant often writes that file. The install has no lockfile, no integrity check and install scripts left on, and it runs inside the engine process environment that holds the platform encryption key.

Stored connection secrets are encrypted at rest, masked in API responses (so the assistant sees them redacted), and masked in logs by default. But secret management in the shipped docker-compose defaults is not locked down. The engine environment also carries the encryption key into every process where workflow code runs. Usage telemetry is sent to the vendor by default, including AI chat error messages. And the patch-connection path can expose stored credentials.

There is no audit log. Assistant tool calls and results are kept only in chat history in Redis, which has no timestamps or approver fields, expires after 30 days, can be deleted by the user and is written only at the end of each turn. HTTP request logs record routes and timing but not arguments. Re-run workflows show up in the normal run history.

Each chat message is capped at 100 model steps, and closing the browser stream aborts the loop. There is no time, token or spend cap; token usage is only logged. Workflows the assistant re-runs execute separately, under the platform's 600-second flow timeout, and keep running after the chat stops.