Security model
Each mechanism is product behavior with a way to check it. When something happens, answer in five minutes: who, when, on which machine, did what.
→The security boundary of an enterprise Agent OS should be made of mechanisms, not vendor promises. Six cards follow, each an independently verifiable fact.
Ordered from the outermost attack surface to the innermost, routing to data ownership.
The points under each card are assertions, not slogans: if any one fails, it is a bug in the repository. That is the difference between a security model and a whitepaper.
The mechanisms share another trait: none asks you to trust that MagicFrog keeps its word — routing is code, audit is records, encryption is whose hand holds the key. All verification material is on your side.
If you remember one line: in MagicFrog, every action answers which machine and who approved — the other five facts are its expansions.
01
Every browser, command, and file action names its target computerId. Wrong machine, offline, or not allowed — it fails explicitly and never silently switches to another machine.
02
Every action answers two questions: which machine it landed on, and who approved it. Audit records are written in the same transaction as the operation, not added afterwards.
03
Admin passwords are stored as argon2id in PHC form; plaintext never touches storage. Sensitive fields get field-level encryption. Model keys are BYOK — they belong to your company's own accounts and never ship inside the client build.
04
The agent reaches internal systems through a client egress you authorize. Dropped links, expiry, revocation, or a policy failure close the path — falling back to direct access is never allowed.
05
Existing computers and servers enroll with a single command. Unenrolling revokes access only — no shutdown, no reinstall, no touching the machine's own data.
06
Self-hosted deployments default to SQLite, with data files on your own server. This site itself carries zero third-party tracking — data ownership starts with not peeking yourself.
All six mechanisms share one design decision: explicit over implicit. Failures are explicit, authorization is explicit, audit is explicit — there is no black box to trust.
None of the six mechanisms is a configuration choice — they are defaults written into the product code. That is what line-by-line verifiable means.
From your instruction to the record on disk, every step has a name: who issued it, which machine, which egress, who approved, where the record lands.
Five stages of one browser operation, from instruction to record — any unmet stage fails the operation in place.
The flow diagram also answers a common doubt: would the agent casually touch another machine? Step two settles it — routing understands computerId, never habit.
Any explicit failure stops the operation in place: no retry storms, no silent rerouting, no reassignment after timeout. Failure is the most honest outcome this data flow produces.
Data flow · 01
You issue a task from the workbench; the instruction and context are written to the session record on your server.
Data flow · 02
The middleware enforces target discipline: no named target, no dispatch; a named target is checked for liveness, ownership, and capability.
Data flow · 03
Traffic leaves via direct or your authorized client tunnel; a dead tunnel breaks the path — never back to direct.
Data flow · 04
The target machine's daemon checks the method against declared capabilities and refuses anything beyond them.
Data flow · 05
Result and audit record commit together, naming the tool, the action, the target machine, and a millisecond timestamp.
No step in these five stages depends on trusting that the system behaves: each is a check, and failures surface explicitly where they occur.
What lives on your server — and what never enters it.
The trust boundary sits on the server line: every item inside is verifiable by you.
The test for the trust boundary is plain: unplug the WAN — does your MagicFrog still run? Yes — everything except model calls, which use your keys, closes locally.
After this boundary map, the next move is one real deployment to verify it.
Inside · your server
Outside · never enters
Everything inside the boundary can be backed up, migrated, and audited; nothing outside it is ever depended on. That is what self-hosting actually means.
Five follow-ups on encryption, audit, and isolation. For anything deeper, read the matching doc section.
Yes. The audit sink is pluggable — the default is one structured log line on stderr, and deployments can wire tool audits into their own collectors.
The encrypted columns are unrecoverable — deliberate fail-closed. Back the key up with the data directory; rotation runs a re-encryption migration with no plaintext window on disk.
Yes. The first-launch account is flagged must_change_password; until the change completes, every business endpoint answers 403 and the client shows only the change screen.
Each session is a separate browser instance: own process, own profile directory, own debugging port. Handles do not resolve across sessions or machines.
A model sees what that session sends, through your keys to your chosen provider. MagicFrog runs no hosted layer and never proxies your model traffic.
No — the route does not exist until you configure it, so there is zero exposure. To enable it, set the client id and secret in the admin console with strict redirect-URI validation and an email-domain allowlist; self-hosted accounts remain the primary channel.
Within five seconds: SIGTERM first, SIGKILL after a two-second grace, a hard five-second bound — and every connection through that proxy is actively terminated, not left to time out.
One last note: security is deployed, not purchased. Every mechanism here depends on deploying by the doc — generate your keys, complete the password change, authorize your egress. Do those three and every line on this page holds.
Deeper questions all have a doc section: self-hosting covers encryption and keys, routing covers the two-layer authorization, egress covers the fail-closed state machine.
