Knox makes
agents ask first
A local approval authority for AI agents before money, credentials, email, and destructive actions.
Knox exists because useful agents eventually reach real-world authority. They can research, prepare, compare, fill forms, and wait. But when the next step is spend money, reveal a credential, send an email, or mutate something that matters, the agent should not be able to approve itself. Knox turns that moment into a specific human decision.
The problem
The old boundary for agents was simple: do not let them touch anything consequential. That kept people safe, but it also kept agents trapped in toy workflows. The useful version is harder. Let the agent do the boring middle, then stop at the moment the owner has to be accountable.
That moment shows up everywhere. Buying a domain. Sending a final email. Revealing a password. Booking a trip. Moving money. Filing a document. Clicking the button that changes the state of an account. In each case, the agent can prepare the work, but the human still owns the decision.
The normal answer is too weak: let the agent ask in chat and hope the transcript is enough. That makes the chat thread the approval system, the audit log, the risk review, and the permission boundary. It also puts approval inside the same conversational surface where the agent is trying to finish the task.
Knox separates those concerns. The agent requests permission. Knox owns the approval request, human prompt, short-lived authorization, and audit trail. The human still decides. The agent resumes only after Knox says that specific request was approved.
That is why this is an Eidos-shaped case study. The interesting move is not "add a security popup." The interesting move is making human approval a local, reusable primitive that every agent has to route through.
The approach
The current Knox v5 flow is deliberately narrow. It does not try to become a general password manager, bank app, or cloud identity provider. It does one high-leverage thing: it turns a human's six digit authenticator code into permission for one pending request.
What the agent provides
- Who is asking: agent and client hints.
- What it wants: provider, operation, scopes, and alias bindings.
- How long it needs access: a bounded TTL.
- Why it is risky: the readable request label and risk tier.
What Knox decides
- Whether the request is well-formed and policy-compatible.
- What fingerprint the human should review.
- Whether the TOTP approval is fresh and unused.
- Which short-lived scoped grant, if any, should be issued.
On the Mac, Knox's menu bar app watches the local state database and opens the approval view when a pending request appears. If Daniel is remote, the agent can use Knox's chat-relay approval channel: it shows the pending request label, alias, risk, expiry, and fingerprint, then accepts one six digit approval code for that visible request. Long-lived credentials and TOTP seeds stay out of chat.
agent asks Knox:
request_label: "buy the domain"
scopes: ["registrar:purchase_domain"]
ttl_minutes: 10
risk: "spend_money"
Knox shows Daniel:
who is asking
what it wants
which alias or provider it will touch
the short request fingerprint
Daniel enters:
six digit TOTP code
Knox returns:
short-lived scoped authorization
audit row with approval mode and strengthThe evidence
Knox has already been used as the boundary for real personal operations: selling a lot, filing tax documents, ordering gifts, registering a car, booking trips, buying domains, researching investments, restructuring retirement-account work, and buying things for kids. The common pattern is not that the agent becomes trusted. The pattern is that the agent does the legwork until the decision point, then Knox asks the human.
The local v5 implementation has hard technical evidence behind it. Provider secrets are stored in macOS Keychain, agents receive scoped grants rather than raw long-lived secrets, approval requests are persisted, audit rows record the approval mode and strength, and TOTP codes are replay-checked and rate-limited. A prior credential workflow also validated a practical edge case: when an alias already exists, Knox should ask the app for a decision instead of failing the agent immediately.
Local system
- Mac menu bar approval UI with setup, approval, and idle views.
- Long-lived daemon bridge for low-latency approval operations.
- SQLite state shared by the agent host and approval app.
- macOS Keychain for TOTP seed and provider secret storage.
Tested behavior
- End-to-end daemon plus MCP approval flow.
- Audit chain verification after setup and approval events.
- Replay rejection and rate limiting for TOTP approval.
- Credential reveal guarded by an app approval decision.
There is one important honesty boundary. Knox v5 proves the TOTP-gated approval machinery and desktop UX. Phone notification approval is the product direction for remote Mac users, but the v5 evidence today is desktop approval plus explicit remote chat-relay approval, not a shipped APNs-first mobile approval system.
What the screenshots show
The redacted screenshots below are the useful part of the evidence trail. They show the workflow as a system, not a slogan: the agent reaches a sensitive boundary, Knox turns that into a pending approval, credentials stay out of the agent's view, and the approval history remains inspectable after the fact.
Read them in order and the operating model is visible. First, the agent reaches a reveal boundary and stops. Second, credential intake makes clear that raw keys belong in Keychain rather than in chat. Third, stored credentials become named bindings instead of pasted secrets. Fourth, TOTP enrollment makes the human factor explicit. Fifth and sixth, the dashboard and calendar turn approval decisions into an audit surface. Finally, the transcript shows the agent doing exactly the right thing: preparing safe work and stopping before payment, MFA, or sensitive identity entry.
The last screenshot is the part that matters most. The agent is not being asked to become a bank, lawyer, authenticator, or owner. It is being asked to do the safe preparatory work, preserve a durable source of truth, and stop when it reaches payment, MFA, or sensitive identity boundaries. Knox exists so those stops can become fast, auditable approvals instead of ad hoc chat interruptions.
The graph
Before and after
- The agent asks in the same chat where it is trying to complete the task.
- Approval is a vague human sentence rather than a request-specific authorization event.
- Secrets, accounts, and browser state can leak into the transcript or tool logs.
- Later, there is no single authority to ask what was approved across all agents.
- The agent submits a structured request to a separate local approval authority.
- The human approves one visible request with a fresh six digit code.
- Knox issues a bounded grant or reveal receipt without exposing long-lived secrets.
- The approval record lives in one redacted audit trail instead of scattered chat history.
The result
Knox changed the operating model. Daniel can now ask agents to do consequential work and stay out of the repetitive middle, while still preserving the decisive human step. The estimated human-effort reduction is roughly 90 to 95 percent on workflows that used to require constant supervision: the agent researches, prepares, compares, fills, checks, and waits. Daniel reads the approval request and enters a code when the boundary is real.
The deeper result is architectural. Knox gives Eidos a single answer to a problem every useful agent eventually has: how does the system let agents act without teaching them to approve themselves? The answer is not more trust in the agent. The answer is a small, local, auditable authority whose whole job is to bind a request to a human decision: this request, this human, this code, this scope, this amount of time.
Named after Fort Knox, because the point is not secrecy for its own sake. The point is that when an agent reaches the vault door, it should have to ask.
