OpenSRE (Tracer)

OpenSRE acts with whatever credentials the operator's machine already holds. The generic AWS tool builds boto3 clients from the default credential chain, the Kubernetes integration loads the user's kubeconfig, and the default shell tool runs every command with the full process environment, so cloud keys, tokens and ~/.aws or ~/.kube files are all within reach. There is no per-request authorization layer; a few integrations (EKS AssumeRole, the scrubbed environment of the Python tool) narrow authority on their own paths only. If the agent is steered wrongly it can do anything the operator's credentials allow, often production-level access.

By default nothing asks a human before acting. The REPL ships at autonomy level High, which the code labels 'allow all', and the shell policy allows every command including sudo, pipes and command substitution. Lower levels (/auto med or off) add a per-call prompt, but only for the REPL's own action types such as shell commands; registered integration tools such as github_cli (any gh command, including gh api and merges) and Slack/Telegram send tools never reach that prompt. The headless 'opensre ask' mode is the exception: it blocks every mutating or unknown tool unless explicitly allowed.

The two most capable default tools are raw passthroughs: shell_run takes any shell string and github_cli takes any gh argument list including gh api. Many integration tools are narrow, fixed read queries, and the generic AWS tool filters operation names with regex allow and block lists, but that is pattern filtering rather than a boundary (get_secret_value still passes). Everything, including shell execution and GitHub writes, is enabled by default.

Model-written shell commands run directly on the host through /bin/sh with the operator's full environment; there is no container, OS sandbox or separate user. The Python execution tool runs code in a subprocess with a scrubbed environment and monkeypatched open/subprocess/socket, which is filtering rather than isolation, and it is a minor path next to the unrestricted shell. If a command misbehaves it has everything the user's account has, including cloud and cluster credentials.

OpenSRE's job is to read logs, alerts, traces, issues and chat messages that other people and systems wrote, then act with production credentials. Nothing in the default REPL limits what a hijacked session can do: tool results enter the context as ordinary data, there is no taint tracking, and egress (curl via shell, Slack/Telegram sends, gh) and irreversible actions are all unattended. The only spotlighting is a delimiter wrapper for headless 'ask --file' inputs and for task text handed to delegated coding agents. A successful injection can therefore both leak secrets and take destructive actions with no human involved.

Long-term memory is on by default: the model can write any fact with memory_remember, an LLM pass extracts 'durable facts' from transcripts after every turn, and the stored memories are injected into every later turn as facts to plan with. The only check on writes is a secret-pattern scan; nothing validates or marks content that came from untrusted sources, so an injection can persist across sessions and steer later tool use. Memories are markdown files under ~/.opensre/memory that the user can inspect and delete. Separately, one integration's configuration loading is not integrity-protected.

Third-party extensions are MCP servers (Sentry, PostHog, X, GitHub) and local coding-agent CLIs, configured by the operator through settings or environment variables; nothing third-party is enabled out of the box, though one integration's configuration loading is not integrity-protected. MCP stdio servers are launched from operator-supplied commands with no version pin or integrity check (the docs' examples use @latest), and they inherit the agent's entire environment, including every credential. First-party skill releases are auto-updated but are ECDSA-signed and verified against keys compiled into the binary.

Stored credentials live in an owner-only (0600) plaintext JSON file rather than an OS keychain, and regex redaction of common token shapes is applied to prompt history, the prompt log, analytics properties and decision traces. However, product telemetry is on by default and ships each turn's prompt, response and up to 48k characters of model context (including tool output) to PostHog, protected only by that regex redaction. Identifier masking and configurable guardrails exist but are off unless enabled. The shell tool inherits every secret in the environment, so the model can read long-lived keys at will.

Every tool call in the action loop is written to a per-session JSONL file under ~/.opensre/sessions: an intent record with the tool name and arguments is fsynced before the tool runs, and a commit record with the result follows. This gives a replayable local record outside the workspace. It does not attribute actions to a requesting principal or approver, approval decisions go only to analytics, the file is writable by the same user the shell tool runs as, and recording failures are silently swallowed so the action proceeds anyway.

Each turn is capped at 64 tool-calling iterations, shell commands time out after 240 seconds, and cancelling (Ctrl+C/ESC) kills the shell command's whole process group. There is no wall-clock or token/cost ceiling. The model can also extend its own run: session_goal_set accepts an arbitrary max_turns, and the every-10-turns human checkpoint applies only to goals without a turn budget, so a model-chosen large budget skips it.