Secrets stay on the machine. Boundaries are enforced.
Having agents do work means giving them authority. Remyral decides at every step where that authority is used, who approved it and within which limits — and puts it on the record.
Layered security
The sealed vault at the core, the audit chain on the outside. Each layer is designed to cover what the one before it cannot.
- 01
Sealed vault worker key
Secrets are sealed with the key of the machine that will use them. The control plane (master) cannot open a value; only that machine can. A key pasted into the chat goes straight into the vault.
- 02
Sandbox isolation
Every job runs in an explicitly scoped workspace: a container on Linux, the runtime sandbox, or a restricted account on the machine. On Windows, parallel jobs each get their own account with process, memory and CPU limits.
- 03
Network policy egress
Per project: off, allow-list or web. Local network and cloud metadata addresses are always blocked.
- 04
Signed releases ed25519
Worker updates are signed and roll out gradually. Control-plane releases come as a signed bundle too; the installer verifies every file and pulls images by digest.
- 05
Audit chain hash chain
Every privileged action and state change is written to a hash-chained log. You verify the chain from the panel and export the log.
You choose how much freedom it gets.
The three presets are three readings of the same rules. Separately, you pick event by event which actions require an authenticator code — and how long a code stays valid.
- Serbest (free)Approvals, merges and deploys pass without asking. For closed teams.
- Dengeli (balanced)Risky actions are asked according to rules; a code is required for the events you pick.
- Sıkı (strict)Every sensitive action needs a person’s approval and a code. For regulated teams.
Per-event verification: choose which actions require an authenticator code.
- Machine management, force-push and security-setting changes are asked in every mode.
- Pushing or merging to a protected branch, deploys, deleting outside the workspace, reading a secret, raising a budget and vault operations are never left to the agent; they always go through the master’s policy check.
- Jobs from untrusted sources (fork PRs, outside contributions) are never auto-approved and never run with full machine access.
- Automatic decisions are logged as “approved by policy”.
Full machine access (unconfined) only opens when both the machine and the project explicitly allow it, with a fresh authenticator code; owners are notified. A machine can forbid it locally altogether.
The agent never sees the credential.
Short-lived git identity
Git credentials are minted per job, at the moment of use — a short-lived token per push. The platform does the commit and push.
Encrypted integration keys
GitHub, GitLab and Bitbucket keys are stored encrypted on the server, never shown again and never sent to the model.
The assistant acts as you
The chat assistant runs on a worker you choose, not on the server. It has no shell or file access; it only uses the panel’s tools, with your permissions.
Approved machine pairing
A new machine isn’t trusted until you compare its pairing code and fingerprint and approve with a code. The install commands in the panel carry no secrets.
Owner account
The first sign-in connects an authenticator app and issues 10 recovery codes.
Untrusted content is data
Instructions in repositories, pages read and READMEs are never treated as authorisation for sensitive actions — only as data.
No inbound ports.
- Outbound only. Workers connect to the control plane themselves; no inbound ports on your machines, no static IP needed.
- One entry point. On the control plane, only the reverse proxy’s HTTPS ports are published.
- No calls to internal addresses. Outgoing webhooks are never sent to local-network, loopback or metadata addresses; only an owner can allow-list an internal target, with a code.
- Workflow requests run on workers. HTTP and code nodes run on a worker under the project’s allow-list and cannot reach private network addresses.
Audit log: every privileged action on one line, with chain verification and JSON Lines export.
Every door to the outside has its own rule.
- API tokens
- Read, job write, approvals, deploy and admin scopes; expiring, optionally limited to IP ranges. A token can never do more than its account’s role, and actions that need a code are refused for tokens by default.
- Outgoing webhooks
- Every delivery is signed with HMAC-SHA256 and carries a timestamp; retries of the same delivery share one id. Bodies contain no prompts, logs or secrets.
- MCP servers
- Off by default per project; allow / ask / block per tool. Tokens stay in the vault and never appear on a command line. Every tool call is audited (name, duration, result).
- Skills
- Imports go through a preview and a code-confirmed approval and are signed with the panel key; the machine verifies the signature again. A project can accept offline-signed skills only.
Problems show up before they grow.
Key and certificate expiry
API keys, integration tokens, the TLS certificate and signing keys in one list; reminders 30, 14, 7 and 1 day ahead.
Rollout circuit breaker
If updated machines fail, or their jobs fail noticeably more often, the rollout stops on its own; resuming or rolling back needs a code.
Cost brake
Daily and monthly caps on API-billed spend; warn only, or hold non-urgent jobs.
Rate limits
Adjustable read and write limits per person, per API token and for the chat.
Masked logs
Tokens and passwords are masked in log search; the support report excludes passwords, tokens, keys and job outputs.
Backups
A nightly database backup with a restore drill; optionally the backups also carry the key files, encrypted to your own age key.
Found a security issue?
Please email us the details, ideally with the steps to reproduce the issue.