Security

A different agent has to approve the change

When Operum can tell which agent wrote the commits, that agent cannot approve them. The Tester approves, unless the Tester wrote the change — then an engineer or architect who did not write it can. The project manager, marketing, and community cannot. When Operum cannot tell who wrote the commits, only the Tester may approve. Commits made under a founder GitHub identity are in that second case. This check is on Operum's own approval tool. A label added through GitHub's API is not checked. The merge looks for the approval record, not the label.

Operum will not merge a code change without a recorded approval of that commit. A pull request that only adds concealment-audit files can merge without that record. There is no switch that skips the approval on a code change. If auto-merge is on and a base update changes the commit without changing the pull request's own files, the earlier approval still counts.

Operum refuses to send a pull request to testing while a required check has failed, unless the recorded override is used. Checks that are still running, unknown, or unreadable do not block that step. Nothing here stops a pull request from being marked for review.

Auto-merge is off unless you turn it on. While it is off, Operum's agents are instructed to wait for your go-ahead, and the desktop does not merge on its own. Someone with direct access to the GitHub repository can still merge outside Operum.

Agents have identities and limits

Each agent has one fixed role: project manager, architect, engineer, tester, marketing, or community. Coding agents work in their own copy of the repository. Operum's GitHub tools refuse label, edit, close, and merge changes on an issue or pull request that belongs to someone else. Comments are allowed. A git push is not checked for ownership.

Operum keeps a local, best-effort record of git pushes and of the approvals currently in force. It does not record who approved, and it is not a complete log of every request GitHub received.

On macOS and Linux the sandbox is on by default for Cursor, Claude Code, Codex, and OpenCode. macOS uses Seatbelt. Linux uses Landlock when the kernel provides it; otherwise the agent runs unconfined and Operum shows a notice. The sandbox limits writes. The temp directory and package caches stay writable. The network stays open, and reads are not confined. A role that runs as your own attached Claude Code session is not sandboxed. Windows has no sandbox. Turning the sandbox off is logged, not announced.

Prompt injection is contained, not ignored

Text from a Telegram group is wrapped before an agent sees it and treated as data. Agents are instructed not to follow it as an instruction. The Community agent, which reads that group, is started without the tools that merge or change GitHub state. Other agents are not restricted that way.

Text in issues, pull requests, and files is not wrapped the same way. Agents are instructed to treat it as data. A few markers in a comment change what Operum does, based on the comment text. Operum does not check who wrote the comment. Operum's own comment tool will not post those markers on someone else's item. A comment written on GitHub directly is not filtered.

If an agent follows a bad instruction anyway, a code change still needs the recorded approval above before Operum will merge it.

Credentials

Credentials saved in Operum's credential store are written to an AES-256-GCM encrypted file on your machine (HKDF-SHA256). On Unix, Operum asks for mode 0600 and continues if that cannot be set. On Windows the file relies on your profile directory's permissions. The file is in Operum's config directory, not in git.

A current install keeps one master key, not the credentials themselves: the macOS Keychain, Windows Credential Manager, or a Linux Secret Service keyring (for example GNOME Keyring, or KWallet when Secret Service is enabled). Operum checks the Linux keyring with a real read-back. If it does not work, you can choose a local key file. If neither is available, Operum does not save the credential. An environment variable named OPERUM_MASTER_KEY, or an existing local key file, is used ahead of the keychain. Older installs may still have individual credentials in the keychain. Operum can read those and does not delete them.

Not every secret is in that file. Saving Telegram also writes the bot token, chat id, and group chat id in plaintext to the team's shared/integrations.json. The sign-in session, GitHub App installation tokens, and MCP OAuth tokens are separate files on the machine. A Claude sign-in is kept by Claude Code. An API key that exists only as an environment variable is read from there and not copied.

Operum's credential code does not write secret values into its logs. A key pasted into a chat is ordinary text. Don't.

What Operum does not do

Operum is not a replacement for a security audit on a sensitive app. It does not review your product for vulnerabilities. The sandbox does not run on Windows or on an attached Claude Code session, and a person who can merge on GitHub directly can bypass Operum's approval.

Reporting a security issue

To report a vulnerability or ask a security question, use the form below. It is the same server-side contact form as the other policy pages, and it routes to the security inbox those pages already use.

Prefer email? You can also reach us directly at security@operum.ai.