Desktop assistants become genuinely useful when they can do more than answer questions. The same transition also creates most of the risk. Reading a selected method is different from reading an entire repository. Preparing a change is different from writing it. Running a harmless formatter is different from executing an unknown script.
AEDA’s permission system starts from a simple rule: capabilities should be separated, scoped to the current task, and visible at the moment they are used.
Permission is a sequence, not a pop-up
The intended action flow has six stages:
- Observe: read only the context the user selected or explicitly allowed.
- Propose: describe the intended action and affected resources.
- Review: show a dry run, diff, command, or other preview.
- Apply: perform only the approved operation.
- Validate: check whether the change produced the expected result.
- Rollback: restore the previous state when validation fails or the user changes their mind.
The safest action is not merely one that asked for permission. It is one whose scope, result, and recovery path remain understandable.
Separate capabilities
A single “workspace access” switch is too broad. The permission broker should distinguish among reading files, searching paths, creating files, editing existing content, launching processes, using the network, accessing the clipboard, capturing a screenshot, and interacting with another application.
Each request should carry a scope. A selected-file edit should not silently become repository-wide write access. A command approved for one project should not become permanent terminal access everywhere.
Targeted edits and visible diffs
For code changes, the proposal should identify the selected context and the intended edit target. AEDA’s current direction uses scoped, reviewable patch proposals so a request about one method cannot casually rewrite unrelated files.
Before application, the user should see a unified diff or an equivalent structured preview. The assistant can explain the change, but the preview must remain available independently of the explanation. An incorrect explanation should not hide an incorrect edit.
Dry run and validation
A dry run answers “what would happen?” without changing the workspace. The exact form depends on the tool: a file diff, a list of shell commands, a simulated configuration change, or a rendered output snapshot.
After approval, validation checks whether the operation worked. For code, that may include compilation, tests, formatting, or a targeted static check. For a website, it may include a rendered preview and broken-link scan. For a configuration edit, it may be a syntax check before the service is restarted.
Rollback must be prepared first
Rollback is often treated as something to figure out after a failure. AEDA should prepare the recovery plan before applying the change. For files, that can be the original content or a patch. For a service configuration, it can be a backup plus the exact command needed to restore and validate it.
The user should know whether an operation is fully reversible, partially reversible, or irreversible before approval.
Model-independent safety
The permission system should not depend on one model behaving perfectly. Models can misunderstand context, overestimate confidence, or choose an unnecessarily broad action. The broker therefore belongs outside the model: the model requests a capability, while the application enforces scope and approval.
This architecture also allows AEDA to use different local and cloud backends without redefining its safety rules for every provider.
What remains difficult
Not every consequence can be predicted from a command or file diff. Tool descriptions can be incomplete, external systems can change, and a valid edit can still be the wrong product decision. Human review does not eliminate those problems, but a visible, staged workflow makes them easier to catch and easier to recover from.
The next engineering work is to make this supervised path feel fast enough for everyday use. Safety that creates constant friction will be bypassed; convenience that removes visibility defeats the purpose. The design challenge is to make the safe path the easiest path.