One clarification: the gateway intentionally does not execute arbitrary commands or expose the filesystem. All supported actions are explicitly allow-listed and still go through macOS TCC prompts. The goal is to keep the agent sandboxed while making OS interactions predictable and auditable.
I’ve been experimenting with running AI agents fully sandboxed (Linux containers / VMs), specifically while configuring and testing OpenClaw (Clawdbot). One issue I kept hitting is that many existing skills for macOS apps like Reminders or Messages assume the agent runs directly on the host and are very permissive in what they allow.
That felt like the wrong security model.
So last weekend I built Mac Agent Gateway, a small open-source project that acts as a local macOS gateway for agents.
The approach is:
- agents stay sandboxed (Linux, VM, container, or remote host)
- a small service runs locally on macOS
- the service exposes a tightly scoped HTTP API that agents access via skills
This allows sandboxed agents to safely interact with Apple apps that are normally restricted to macOS, without giving the agent shell access or broad system permissions.
Current support includes Reminders and Messages. One concrete example: a sandboxed agent can review the last 1–2 weeks of messages, identify what’s important or unanswered, and create follow-up reminders with full context using a reasoning model.
Security-wise, the design is intentionally conservative:
- local-only HTTP interface
- explicitly allow-listed actions
- no shell access
- no filesystem access
- macOS TCC permissions remain enforced
I’ve tested this so far with OpenClaw and Claude, but the design should work with any agent framework that supports a SKILLS.md-style integration.
I’ve been experimenting with running AI agents fully sandboxed (Linux containers / VMs), specifically while configuring and testing OpenClaw (Clawdbot). One issue I kept hitting is that many existing skills for macOS apps like Reminders or Messages assume the agent runs directly on the host and are very permissive in what they allow.
That felt like the wrong security model.
So last weekend I built Mac Agent Gateway, a small open-source project that acts as a local macOS gateway for agents.
The approach is:
- agents stay sandboxed (Linux, VM, container, or remote host)
- a small service runs locally on macOS
- the service exposes a tightly scoped HTTP API that agents access via skills
This allows sandboxed agents to safely interact with Apple apps that are normally restricted to macOS, without giving the agent shell access or broad system permissions.
Current support includes Reminders and Messages. One concrete example: a sandboxed agent can review the last 1–2 weeks of messages, identify what’s important or unanswered, and create follow-up reminders with full context using a reasoning model.
Security-wise, the design is intentionally conservative:
- local-only HTTP interface
- explicitly allow-listed actions
- no shell access
- no filesystem access
- macOS TCC permissions remain enforced
I’ve tested this so far with OpenClaw and Claude, but the design should work with any agent framework that supports a SKILLS.md-style integration.
Repo: https://github.com/ericblue/mac-agent-gateway
I’m especially interested in feedback on:
- whether the security model and threat boundaries feel appropriate
- what macOS capabilities would actually be useful next
- how others are handling safe OS access for agents
Happy to answer questions.