CyberStrikeAI

The platform has real multi-user authentication: a generated 24-character admin password on first start, per-user roles and permissions, resource-level scopes, a login rate limit, and a principal that is carried into the MCP tool-call authorizer. That governs which human may use the platform. The agent's tools, however, run as the server's OS user with the full inherited environment, so the authority the agent holds is ambient and broad. If the authorization layer fails, the process can reach everything that OS user can.

A per-call human approval gate exists (the HITL feature): it shows the tool name and exact arguments, supports reject, edit-before-run, and auto-rejects on timeout. It is off by default, so a fresh install runs every tool, including the shell and C2 task tools, with no approval. The shipped allowlist of approval-exempt tools also contains project-fact writes and some C2 helper tools. A wrongly approved or unapproved call can act irreversibly on real targets with no rollback.

Tool arguments are mostly passed straight through. The shell tool takes an arbitrary command string, and the only central validation is a configurable regex deny rule (government domains by default) applied to every tool call, which its own docs say is not an exhaustive authorization check. Engagement scope is given to the model as prompt text rather than enforced in code. About 78 tools, including shell, scanners, and C2 tools, are enabled in the default role.

Commands and scanner tools run as ordinary subprocesses of the server, under the server's OS user, with the full inherited environment. A process-guard layer adds cgroup or process-group containment, a process count limit, a memory ceiling, and kill-on-cancel, but that is lifecycle and resource control, not an isolation boundary, and there is no container, filesystem, user, or network separation. The shell tool accepts arbitrary command strings, so anything that reaches it is host-level execution.

Output from scanned targets, web pages, files, and external tools enters the model's context with the same standing as the user's instructions, and nothing in code tracks provenance or restricts tools after untrusted content is read. Combined with a shell, network tools, and C2 tools running ungated by default, a hijacked agent can both exfiltrate data and take irreversible actions without a human. This platform's core job is to read hostile content, so the exposure is built in.

The model can write persistent project facts and security-finding records, which are re-injected into later sessions as working context, and the shipped approval allowlist exempts fact writes from review. Project data is isolated per user through resource-assignment queries, but facts are not validated or expired, and automatic storage cleanup is off by default. Configuration and prompt files load only from the platform's own directories, not from a target workspace.

Third-party extensions are opt-in: the external MCP server list ships empty. An authenticated operator can add a stdio server by naming a command and arguments, and the platform launches it as a same-user process with no version pin, hash check, or re-approval when it changes. Skills and tool definitions are local files loaded from the platform directories. The gap is the absence of any verification, not automatic installation.

Secrets live in a plaintext config file created with owner-only permissions, and the settings API does not fully protect secrets. Platform audit records redact common secret-named fields, but full tool arguments and results are stored unredacted in the execution table and tool subprocesses inherit the whole environment. Telemetry is local-only by default. Long-lived provider keys are reachable by anything the shell can read.

Every tool call routed through the MCP server is saved with arguments, result, status, timestamps, owning user and conversation. Approval requests and decisions are stored with reviewer type and whether the system or a human decided, and platform actions (logins, config changes) have a separate audit log with actor and IP. Records sit in the same local SQLite database the server's shell could modify, and are not signed or exported by default.

Per-tool timeouts, a shell no-output timeout, concurrency caps and a circuit breaker for external servers, and a process-guard memory and process ceiling are enforced in code, and cancel kills the whole process group. There is no cost or wall-clock budget for a run, and the shipped example config sets the iteration limit to 12000 and the per-tool timeout to 60 minutes, so a runaway can continue for a very long time. Stopping works on in-flight commands, but batch task schedules can restart work.