The security boundary, in plain language

Agent Master Key's promise is simple: give your agent access, not your keys — kill it in one step. This page explains exactly what that promise covers, where the boundary sits, and what sits outside it. No security product should make you guess.

What Agent Master Key protects

• Your real provider keys never leave the vault. They live in an AES-256-GCM encrypted vault on your Mac and are used only by a local broker on 127.0.0.1. They are not uploaded to us, and they are never handed to an agent.
• Each agent gets a scoped, revocable key instead. The amk_live_ key an agent receives works only through the broker on your Mac — it is useless off the machine and limited to the connectors and actions you granted. Other standard macOS accounts cannot read it; an administrator using root privileges can — as with every file on the Mac.
• Every use is attributed and reversible. Actions taken through the broker land in a local, redacted audit trail, and any grant can be undone: revoke one key, or hit the kill switch to pause every agent at once.
• Risky actions wait for you. Safe reads proceed inside the granted scope; risky writes require your explicit approval before the broker will act.

Where the boundary sits — and what is outside it

Here is the honest version, because this is where most tools in this space go quiet: Agent Master Key mediates access per user, not per agent process. The approval prompts, scopes, and audit trail control what happens on your macOS login — they are not a wall between two programs that are both already running as you.

That has three concrete consequences:

• Any process on your macOS login is inside the trust boundary. A program running under your user account can, in principle, read what your account can read. That includes the scoped key you handed an agent. This is a macOS ceiling, not an AMK bug — the operating system gives a local app no reliable way to prove which local program is calling it.
• Agents on the same account can pose as one another. Popular agents are Electron or Node processes; at the OS level, one local program can present itself the way another does. So we make no promise of separation between two agents running under the same login, and we treat any claim of one from a local tool with suspicion — you should too.
• Malware running as you defeats every local tool, including this one. If a malicious program is already on your Mac with your privileges, no application-level product can honestly protect you. Keeping your Mac clean is the foundation everything else builds on.

The only kernel-enforced wall between agents today is a separate macOS user account per agent. macOS user-account protection is real: a scoped key issued on your login cannot be read from another standard account (an administrator using root privileges can read any file on the Mac). If you need hard separation between two agents, run them under different macOS accounts — AMK works fine that way.

So what does the scoped key buy you inside the boundary? Exactly what we claim and no more: your real provider key stays out of every agent config file on disk, the blast radius of any one agent is limited to the scope you granted, every action is attributed and logged, and one click ends it. That is the promise — access, not keys, killable in one step — and it holds without pretending your Mac is something it isn't. Every local tool that brokers agent access on a single macOS account shares this same ceiling; the difference is whether it is stated plainly.

Local custody

When you connect a provider, you bring an API key. It is encrypted with AES-256-GCM and stored on your Mac — there is no cloud vault in the loop, and secrets are not uploaded to Agent Master Key. The broker injects the provider key into the outbound provider request itself, refuses to replay it to redirects, and scrubs credential-shaped values from provider responses before an agent sees them. Full detail, including what we never see, is on the trust & custody page.

Update trust

A key-custody tool is only as trustworthy as its update channel, so ours is verifiable end to end:

• Distribution proof is release-specific. A published hash identifies an artifact; signing, notarization, stapling, and Gatekeeper acceptance are claimed only when the matching release evidence is current.
• In-app updates use the Sparkle framework with a pinned signing key. The app fetches our appcast over HTTPS and verifies each update against an EdDSA public key embedded in the app itself. An update that does not carry a valid signature from our private key will not install — a swapped download or tampered feed fails the check.

How revocation works

An agent's access is one scoped key, honored only by the broker on your Mac. Revocation is therefore local and immediate:

• Revoke one agent: the broker stops honoring that key the moment you revoke it; the agent's next request fails. Your provider credential is untouched — nothing to rotate, no other agent affected.
• Kill switch: one control pauses every connected agent at once. Reconnect them individually when you're satisfied.
• The honest edge case: revocation controls access through the broker. If you believe your Mac itself was compromised, also rotate the affected provider keys at the provider — that scenario is outside AMK's boundary, and we'd rather tell you that here than have you learn it later.

Reporting a vulnerability

Email suspected vulnerabilities to security@agentmasterkey.com. Agent Master Key is newly launched; an independent third-party security review is on our roadmap, and we will only make stronger claims once that review supports them. The trust & custody page remains the canonical statement of what we store and what we never see.