Know what Actfor protects and where it stops

What Actfor protects

• Your admin keys for Spaceship, Cloudflare, Resend, Vercel, Convex and GitHub control DNS, email, hosting and deploy settings, so Actfor treats them as the most valuable items in the vault.
• App secrets and the scoped keys Actfor creates each give access to one product.
• Two keys in your macOS Keychain seal the vault and compute fingerprints.
• The audit log has to show what really happened.

Who we plan for

• You sit at your Mac and approve sensitive actions with Touch ID.
• Coding agents run as your macOS user. A prompt injection in a file, a web page or a tool result can turn an agent against you.
• Malicious code, such as a compromised npm package, can run as your user.
• Remote attackers can obtain a credential somewhere else.

What Actfor stops

• An agent cannot read a value through Actfor. No method returns one, Actfor redacts responses, and the MCP server has no reveal or capture tool.
• An agent cannot send an admin key to a host it picks. Actfor sends brokered requests only to the hosts and paths in that key's rules.
• An agent cannot push a value to a target it picks. Actfor pushes only to the key's allowed targets, and adding a target needs Touch ID.
• An agent cannot quietly replace a production value. An overwrite at a production target needs Touch ID, unless you marked that exact key and target as unattended.
• An agent cannot approve its own request. Only a helper that the Actfor daemon starts can approve, and that helper shows the system Touch ID dialog.
• Nobody can quietly rewrite the history. Actfor chains the audit log with hashes, so an edit to an old line breaks the chain.

What Actfor does not stop

• Code running as your user can attack Actfor itself. It can read the memory of unsigned or debuggable processes, replace binaries it can write to, or rebuild and re-sign Actfor with a signing identity that never prompts. We plan to sign release builds with Developer ID and the hardened runtime, and to install them in /Applications outside any repository. The daemon also checks the approval helper's code signature before it starts the helper.
• Actfor cannot protect a value after you reveal it. Once you paste a value somewhere, it is out of Actfor's hands.
• Actfor cannot stop a compromise at the provider. If a provider loses a key that Actfordelivered correctly, you rotate it.
• An agent can still misuse an admin API inside the hosts you allowed. Narrow each key with path rules, set destructive methods to ask, and check the audit log.

How approvals work

When your policy says ask, the Actfor daemon starts its approval helper. The daemon passes it the session name, the requesting program, the action, the key, the target and a one-line reason.

The helper shows the macOS Touch ID dialog and falls back to your device password. If nobody answers within 120 seconds, Actfor treats the request as declined. A client cannot send an approval, and it can only wait for one.

Some actions always ask, whatever your policy says. They are revealing a value, adding a target or host, changing the policy and deleting a key.

Where your keys live

Actfor stores keys in a SQLite vault in your Library folder, and only your user can open that folder. Actforseals each value with XChaCha20-Poly1305 under a master key that stays in the macOS Keychain.

Logs and agents see a fingerprint instead of a value. The fingerprint is the first 16 hex characters of an HMAC-SHA256 that Actfor computes with a second Keychain key, so nobody can test guesses of a short secret against it.

Who can see a value

You can see a value after Touch ID, from the menu bar app or with actfor reveal. Actfor copies the value to your clipboard and never prints it.