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 server binds to 127.0.0.1 only. It does not listen on your local network, and nothing outside your Mac can reach it.
• There is no telemetry and no analytics of any kind. No usage reporting, no crash reporter, no third-party SDK.

The only network request the app makes on its own initiative is a once-daily check for a new version, against a single pinned host. You can turn that off in settings. Everything else on the wire is a service you configured: your mail server, your calendar server, your storage provider, your feeds, your APIs.

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 one of the app's tools 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; it isn't something you have to pay to get.

The dangerous things, and how they're gated

Three capabilities can do real damage, and each one is off until you deliberately turn it on.

• 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 CLI. Those jobs are ones you write yourself in the app, they run with your own user's permissions, and every run is logged with its output. Commands are executed as an argument list, never assembled into a shell string, so a filename with a space or a quote in it can't turn into an extra command.

Outbound web requests are checked before they're made, so an agent can't be talked into fetching internal addresses on your network: private and loopback ranges are refused unless you explicitly allow local network access. Archive extraction refuses entries that would write outside the target folder. Uploads and downloads are checked against the same folder allowlist as everything else.

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) can contain text trying to influence what it does next. That's a property of the AI client, not something this app can filter. It's the main reason per-key scoping exists, and the reason write access is off by default.
• 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