The security model, in plain terms

This app is given access to your mail, your calendar, your files, and optionally a shell on another machine. That's a lot to hand to any program, and "trust me" isn't an answer. So here is what it actually does, what it deliberately doesn't do, and where the sharp edges are.

Where your data lives

On your Mac. There's no account to create, no server of mine in the path, and no copy of your mail or calendar anywhere but your own machine.

• Mail, calendar, contacts, and feed data sync into local databases and files in your own Application Support folder.
• Every credential (mail passwords, storage keys, API keys, your license key) is stored in the macOS Keychain, never in a config file or a plain text preference.
• The MCP and REST server binds to 127.0.0.1 by default. A Pro setting can instead admit peers on private networks or from specific IP ranges, after you confirm the change. API keys and their grants still apply.
• There is no telemetry and no analytics of any kind. No usage reporting, no crash reporter, no third-party SDK.

The app checks for updates once a day unless you turn that off. It also polls accounts, feeds, and monitors you configure. Calls to an AI provider, a connected MCP server, a storage provider, or one of your APIs go to the endpoint you chose for that service.

Why the App Sandbox is off

The App Sandbox is macOS's strongest per-app containment, and this app deliberately doesn't use it. That's a real trade-off, so here's the actual reason rather than a euphemism.

The scheduler's entire purpose is to run things on your behalf: the Claude CLI, git, your own shell commands. A sandboxed process cannot spawn those, and child processes inherit the sandbox, so there's no way to sandbox the app and still have the feature exist. Granting Full Disk Access doesn't change it either, because that waives a different restriction (TCC) and has no effect on the sandbox.

So the choice was an app with no scheduler, or an app without the sandbox. I chose the second and put other controls in its place. It also means the app is not on the Mac App Store, which requires sandboxing, and is distributed directly instead.

What's in place instead

Developer ID signing and notarization. The app is signed with an Apple-issued Developer ID certificate and notarized by Apple, which means Apple has scanned the exact binary you download and it hasn't been altered since. The Hardened Runtime is enabled, which blocks code injection and unsigned library loading. You can verify all of this yourself on the downloaded app before you ever open it:

• codesign -dv --verbose=4 /Applications/Klass\ Personal\ OS.app shows the signing identity and that the Hardened Runtime flag is set.
• spctl -a -vvv /Applications/Klass\ Personal\ OS.app confirms Gatekeeper accepts it.
• xcrun stapler validate /Applications/Klass\ Personal\ OS.app confirms the notarization ticket is attached.

Two entitlements, not a blanket grant. The app requests exactly two capability entitlements, for Calendar and for Contacts. It holds no others. Hardened Runtime requires those two even with the sandbox off, and they're the reason macOS prompts you.

Normal macOS permission prompts. Calendar, Contacts, Reminders, and notifications are all gated by the same system dialogs any app goes through, and you can revoke any of them in System Settings at any time. Nothing is silently assumed.

Resource-scoped API keys. Every client that connects gets its own key, and a key isn't all-or-nothing. Each grant on a key names a domain (mail, files, calendar, storage, and so on), the operations allowed within it (list, read, write, delete, and so on separately, never bundled), and which specific resources it applies to: one bucket, one mail folder, one named folder root. An agent that only needs to read one mail folder gets a key that can only read one mail folder. Revoking one key doesn't disturb the others.

Folder access by allowlist. File tools can only see folders you've explicitly added and named. Paths are resolved and checked component by component against the real filesystem, not by string prefix matching, so a symlink or a .. segment can't be used to escape a root. Any root can be marked read-only.

Per-tool kill switches. A settings pane lists every built-in tool and lets you disable any of them app-wide. A disabled tool disappears from what clients can see and is refused if called, for every key, regardless of grants. That control is available on the free tier.

Approval before sending. An outbound mail account can require a human decision on every send. The call waits while you approve or deny it from a notification or the Approvals screen; a denial or timeout sends nothing. This currently covers outbound email, not every write tool. Decisions are kept in an audit history.

Connected MCP servers. Third-party servers are configured in the app, but their discovered tools are not granted to any API key automatically, including the owner key. You choose each exposed tool in the Grants editor. A local stdio server is a process the app launches under your macOS permissions, so only add one you trust.

One authorization path for MCP and REST. The REST routes use the same API keys, tool enablement, license checks, and grants as MCP calls. Exporting an OpenAPI spec does not open another listener or relax a grant.

The dangerous things, and how they're gated

Several capabilities deserve an explicit choice before an agent uses them.

• Changing your mail. Every mail account starts read-only. Marking read, flagging, moving, deleting, and saving drafts all require switching that account to allow writes. Permanent deletion (rather than moving to Trash) is a second, separate opt-in on top of that, and you can list folders that must never be written to regardless.
• Running commands on another machine. SSH command execution is off for every server by default, has to be enabled per account, and is only available with a Pro license. It carries an explicit warning where you grant it, because it can do anything the SSH user can do on that host.
• Running things on this machine. The scheduler can run shell commands and the Claude or Codex CLI. A local stdio MCP server also launches a process you configure. They run with your macOS user's permissions. Use the app's key grants and the Codex write-folder setting to bound what an agent can request.

Outbound web requests are checked before they're made. The HTTP client refuses private and loopback destinations unless you explicitly allow local network access. Connected MCP servers have separate endpoint rules: HTTPS is the normal remote path; loopback HTTP is allowed, and cleartext access to a private-network address requires a per-server opt-in and uses no header or OAuth credentials. Archive extraction refuses entries outside the target folder. File uploads and downloads use the folder allowlist.

What this doesn't protect you from

Being straight about the limits is more useful than a longer list of features.

• An AI acting on a bad instruction. If you grant a key write access to your mail and your agent decides to delete something, the app will carry that out. Grants are the control here; give each agent the narrowest one that lets it do its job.
• Prompt injection. Content your agent reads (an email, a web page, a feed item, or a connected server's tool description) can contain text trying to influence what it does next. Per-key scoping and the optional outbound-mail approval step limit what such an instruction can cause, within the permissions you grant.
• Anything with your Mac's password. Someone sitting at your unlocked machine has your Keychain and your files regardless of this app.
• The AI client itself. Whatever you connect (Claude Code, Claude Desktop, something else) is a separate product with its own privacy terms and its own network behavior. This app hands it data locally; what the client does with that data is between you and its maker.

Reporting a problem

If you find a security issue, email me directly at info@coreyklass.com rather than posting it publicly, and I'll get back to you. It's a one-person product; there's no triage queue in front of me. I'd rather hear about a real problem early than read about it later.

Back to Klass Personal OS · License terms · Privacy policy