Argus

Everything runs under the platform's own user model: per-user API tokens, a built-in read-only role that the middleware uses to block writes, and a separately restricted credential for the workflow worker that can only reach three named routes. Authorization is otherwise flat: the default permission class is 'any authenticated user', so any non-readonly account can edit and run workflows, change skills and register MCP servers, and any account can read all tickets. By default self-registration is auto-approved with read access. One ticket-assistant endpoint forwards the caller's platform token to MCP endpoints the caller names, which is a token-passthrough pattern.

The assistant has no consequential tools, so it needs no approval step. The platform's consequential actions live in the workflow engine, and there is no approval node, confirmation step or per-run human gate anywhere in it. A human publishes a workflow once, after which runs triggered by tickets, webhooks, schedules or the API execute every step, including containment, email and generic HTTP calls, unattended. The generic HTTP action is also ungated.

The assistant's tools are narrow and read-only, with typed schemas and clamped result limits, and database access goes through the ORM. Validation is uneven elsewhere. The generic HTTP workflow action has a strong target policy (fixed host, admin allowlist, resolved-address checks, no redirects, capped response), but the containment, lookup and webhook actions accept any URL, the skill-reading tool's argument handling is not strict, and a registry-proxy endpoint fetches caller-supplied URLs. All workflow actions are registered by default, including write and network ones.

No model-reachable path interprets text as code. The workflow engine substitutes variables with a regular expression, conditions use a custom evaluator, database access uses the ORM, and the model has no shell, script or package-install tool. The only process-spawning and exec hits are a manual sample script and a docstring.

Untrusted content reaches the model in several places: ticket alert JSON, tool results, knowledge-base documents and skill text. Nothing distinguishes it from instructions, but the default assistant paths have only read-only tools, so a manipulated model can read tickets and assets and shape its answer, not change state or call out. One ticket endpoint lets the caller list MCP endpoints whose tools the model may select without approval. Separately, alert fields flow into workflow variables that choose containment targets, which is not model-mediated.

Persistent instruction text steers the assistant. Skill documents on disk are loaded silently into the system prompt for every user, and any non-readonly authenticated user can create or overwrite them through the API, with no validation, approval, versioning or audit record. Skill-name handling is not strict. Saved chat history is per ticket and is only replayed to the model if the client sends it back. Configuration files come from the deployment, not from a workspace the assistant operates on.

The platform loads no third-party code into its own process. MCP is used as a client to remote JSON-RPC endpoints that a user lists or registers; the endpoints, their tool lists and their tokens are not pinned or verified, tool lists are cached for three minutes, and there is no re-approval when definitions change. In the default chat paths the internal endpoint is forced, so registered servers are ignored, but the mention endpoint accepts caller-supplied endpoints and sends the caller's platform token to them.

Workflow credentials are handled well: sensitive fields are write-only, encrypted at rest with a rotatable key ring, bound to their target, decrypted only in the worker, and redacted from results and errors. Startup refuses a placeholder secret key or a missing workflow key outside debug mode. Gaps remain: MCP server tokens are stored in plaintext, request bodies can carry a model API key, and the handling of some stored and deployment credentials is not locked down. No telemetry SDK is present.

Assistant tool calls are recorded in a database table with tool name, arguments, status, endpoint and timing, and the ticket chat stores the trace. Workflow runs record step inputs, outputs and the user who started them. The record lacks the requesting user on tool calls, the general audit table only logs authentication events and read-only users' activity, and changes to skills, MCP servers and workflows are not audited. Some audit writes are wrapped so failures are swallowed.

The chat loop is capped at six iterations by default and each model call and MCP call has a timeout, but any authenticated caller can raise the iteration count and timeouts per request with no ceiling, and there are no token, cost or total wall-clock limits. The MCP streaming endpoint holds a worker thread open indefinitely. Workflows have a graph-loop guard, a bounded HTTP timeout and response size, and optional per-step timeouts, with cancel forwarded to the workflow engine but errors swallowed; there are no concurrency or rate limits beyond the generic request throttle.