Safety Approval: Balancing AI Capability with Human Control

Imagine this scenario: you ask the AI to help clean up temporary files in a project directory. The AI understands your intent and generates a command -- but it gets the deletion path wrong, pointing it at your source code directory. If this command were executed directly, you could lose weeks of work in seconds.

This is not hypothetical. When AI has the ability to read/write files and execute commands, any single "hallucination" can turn into real loss. Tokeny's answer is: grant AI tool capabilities while keeping the final decision in the user's hands. This is our HITL safety approval mechanism.

HITL: Keeping Humans in the Decision Loop

HITL stands for Human-in-the-Loop. The concept originates from aerospace and industrial automation -- in critical systems, automation can assist decision-making, but the final confirmation must rest with humans.

In Tokeny, HITL manifests as follows: before executing any high-risk operation, the AI automatically pauses and presents an approval dialog showing the operation about to be performed. You can then approve, reject, or modify the operation before it executes. The AI will never perform any dangerous operation that you cannot see.

This design is consistent with our core philosophy of "collaboration, not delegation": the AI is responsible for thinking and suggesting, while humans are responsible for judging and confirming. Each plays its role, collaborating to complete the task.

What Requires Approval and What Doesn't

Not every operation requires approval -- that would make the experience extremely tedious. Our design principle is: read operations execute freely; write operations are graded by risk level.

Operations that require approval:

• Shell command execution: all Shell commands require your individual approval by default. Shell commands are not constrained by the workspace sandbox and can access any location on the system and perform any operation -- this is the fundamental reason they must be approved
• File deletion: whether deleting a single file or recursively removing a directory, the AI must obtain your consent first

Operations that do not require approval:

• Reading file contents -- the AI needs to read your files to understand context, and this is safe
• Creating and writing files -- new files do not destroy existing content, and file tool operations are restricted to the workspace sandbox
• Searching file contents (grep) -- read-only operations that do not modify any files
• Web searching and fetching web page information -- information retrieval does not affect local data
• Conversational interaction with you -- the AI can always ask you for clarification

The Complete Flow of an Approval

Let's walk through a concrete scenario: you ask the AI to help initialize a Node.js project.

1. 1The AI analyzes your requirements and decides to execute npm init -y to initialize the project
2. 2The system pauses execution and presents an approval dialog, clearly showing the command and working directory
3. 3You review and confirm the command is safe, then click "Approve"
4. 4The command executes, the AI receives the output, and continues to the next step
5. 5The AI then wants to execute npm install express -- another approval dialog appears
6. 6You confirm and approve, and the process continues

Throughout the entire process, you always know what the AI is doing, why it's doing it, and what command it's about to execute. There are no "black box" steps.

Three Options in the Approval Dialog

Each time an approval dialog appears, you have three options:

• Approve: confirm execution of this command. Note that this only approves the current command -- the next command still requires separate approval
• Auto-execute: enable auto-execution mode, which automatically runs subsequent commands using the current workspace directory. Suitable when you trust the current task and need to execute many commands in succession
• Reject: cancel execution of this command. The AI will not force execution; instead, it will adapt -- it may modify the command, choose an alternative approach, or simply ask what you'd like to do

Rejection does not mean "terminate the task." The AI is flexible enough to adjust its strategy based on your rejection. You can even provide a reason when rejecting, such as "Don't use rm, use mv to move to trash" -- the AI will modify its approach accordingly.

Intelligent Risk Assessment: More Than Just Blocking

Tokeny's security mechanism is not simply "block every command" -- that would just be a confirmation button with no real value. We've added an intelligent risk assessment system on top of the approval process.

The system automatically classifies each Shell command by risk level:

• Low risk (green): read-only or informational commands, such as ls, cat, echo, pwd
• Medium risk (yellow): commands with side effects but controllable impact, such as mkdir, cp, npm install
• High risk (red): commands that may cause irreversible damage, such as rm -rf, chmod 777, curl | bash, formatting disks

When a high-risk command is detected, the system triggers an additional AI security analysis -- a separate, independent AI model specifically analyzes the potential risks of the command and displays a detailed risk report in the approval dialog. This means you don't need to judge how dangerous chmod -R 777 / is yourself -- the system will tell you explicitly.

Workspace Sandbox: The File Tool Safety Boundary

Beyond HITL approval, Tokeny also establishes security boundaries at the file system level. The AI's file tools (reading, writing, creating, deleting files, etc.) are strictly confined to the workspace directory:

• Path traversal defense: the AI cannot use ../ or similar techniques to access directories outside the workspace
• Symbolic link detection: the system detects symbolic links pointing outside the workspace and blocks the operation
• Path whitelist: all file tool operation paths must be within the workspace scope; otherwise, the request is rejected outright

Even if the AI hallucinates a file path pointing to a system directory, the security validator will intercept it before execution. This is the second line of defense beyond HITL.

However, it must be clearly stated: Shell commands are not constrained by the sandbox. A Shell command can access any location in the file system and perform any system operation -- this is the fundamental nature of Shell, which cannot be restricted by a sandbox. This is precisely why Shell commands must go through HITL approval: where the sandbox cannot protect, you serve as the gatekeeper.

Auto-Execution Mode: Balancing Efficiency and Safety

Approving each command individually can reduce efficiency in certain scenarios -- for example, asking the AI to scaffold a project might require executing over 20 commands in succession. Having to manually confirm each one wouldn't be a great experience.

Therefore, Tokeny provides an "auto-execution" mode: when enabled, Shell commands run automatically using the current workspace directory as the working directory, skipping individual approval. But this mode has several important characteristics:

• You actively choose to enable it -- it's not the default behavior, but an explicit choice made in the approval dialog
• Working directory is fixed -- auto-execution uses the current workspace directory, though Shell commands themselves may still access paths outside the workspace
• Can be disabled at any time -- you can turn off auto-execution in settings to restore individual approval
• High-risk commands are still intercepted -- even with auto-execution enabled, commands identified as high-risk will still trigger an approval dialog

Our Thoughts on Safety

When designing the safety mechanism, we repeatedly considered a core question: must safety and efficiency be at odds?

Our conclusion is: they don't have to be. The key is placing security approvals at the right points. Reading files doesn't need approval -- that would just create noise. Executing Shell commands needs approval -- because the consequences may be irreversible. High-risk commands need additional analysis -- because even technical users can overlook certain risks.

This is the design philosophy of "secure by default + opt-in relaxation": for most users, the default security settings are already good enough. For advanced users, auto-execution mode provides room for efficiency. Different scenarios, different trust levels -- users can choose their own security strategy.