An AI assistant becomes a different kind of software when it can edit files or run commands. At that point, a permission prompt is not a cosmetic feature. It is part of the product’s safety model. Nerva is an upcoming local-first agent designed around this boundary: the model can suggest an action, but a separate permission layer decides whether the action may happen.

That separation matters because models can be wrong, tool output can be misleading, and repository files can contain instructions written by someone else. Nerva should make the proposed action, affected resources, and reason for approval visible before anything consequential runs.

This article describes the planned architecture, not a claim that every part is already shipped.

The short answer

Nerva should treat every tool call as a request that passes through a policy boundary.

  1. The model creates a structured proposal.
  2. The agent checks which resources the proposal would touch.
  3. A permission engine compares the request with the user’s policy.
  4. Safe read-only work can continue automatically when allowed.
  5. Writes, network calls, credentials, and destructive commands require a clear approval.
  6. The result is verified and recorded after execution.

The model should never be able to turn a sentence into an unrestricted shell command. It should produce an intent that the tool gateway can validate.

Why model output cannot be the permission system

A language model predicts useful text and structured actions from context. It does not have an independent reason to protect your repository, and it cannot reliably know whether a command is destructive just because the command looks familiar.

Consider a request to “clean up the old build files.” A model might propose deleting a directory that contains a local fixture, an uncommitted migration, or a file with a similar name. The proposal may sound reasonable while still being unsafe.

The permission engine should therefore receive facts such as:

Field Example Why it matters
Operation Write file A write changes user state
Target src/config.ts The exact path can be reviewed
Scope One file or repository Prevents accidental broad access
Network None Shows whether data leaves the device
Destructive No Separates edits from deletes or overwrites
Reason Apply approved TypeScript fix Makes the request understandable

The engine can then allow, deny, or ask. The model’s confidence should not override the policy.

A permission request should be structured

The UI should show a compact summary before approval instead of displaying a vague message such as “Nerva wants to continue.”

Proposed action: edit one file
Path: src/lib/router.ts
Changes: add a timeout check, no deletion
Network access: none
Credentials: none
Verification after action: npm test -- router

[Allow once] [Allow for this workspace] [Deny]

The three approval choices have different meanings. Allow once is useful for a single experiment. Workspace approval reduces repetition for a trusted operation. Deny should stop the action and return control to the user without trying a different command silently.

Read, write, execute, and network are different permissions

An agent should not collapse all computer access into one yes-or-no switch. Reading a selected Markdown file is not equivalent to reading an entire home directory. Running a unit test is not equivalent to running a downloaded binary. Sending a prompt to a cloud provider is not equivalent to using a local model.

Useful permission groups include:

  • Read: inspect named files or directories.
  • Write: create or modify named files.
  • Delete: remove files, branches, or generated output.
  • Execute: run an explicitly shown command in a controlled working directory.
  • Network: connect to a host or provider API.
  • Secrets: access environment variables, keychains, or credential stores.
  • External control: operate a browser or another application.

This granularity makes policies easier to understand and audit. It also lets a user say, “Run tests locally, but ask before any network request.”

The policy should be checked again at execution time

It is tempting to approve a plan once and assume every later step is covered. That creates a gap. A plan can change after a command returns an unexpected result, and a later tool call may touch a different resource.

Nerva’s planned control loop should check each consequential operation immediately before execution:

plan -> inspect requested resource -> policy decision
                                      |
                         allow / ask / deny
                                      |
                         execute -> observe -> verify

The check should use the actual path, command, host, and data selected for the call. A permission granted for src/ should not automatically cover /Users/name/Documents/. A request approved for api.example.com should not silently become a request to another host after a redirect.

What happens when a tool fails

Failure handling is also a permission concern. If a write fails because a file is read-only, the agent should not immediately try sudo, change ownership, or write to a different location. Those are new actions with new risks.

A safer response is:

  1. Show the original failure.
  2. Explain the smallest possible next action.
  3. Ask for permission if the next action changes scope.
  4. Keep the failed attempt in the task history.

This prevents a helpful-looking recovery loop from becoming an invisible escalation of access.

How this connects to real project work

For a backend project such as CryptoEx or SentinelFi, an agent may need to inspect code, run a test, and draft a patch. The useful experience is not just the generated code. It is the chain of evidence around the change:

  • Which files were read?
  • Which file was edited?
  • Which command was run?
  • Did the test pass, fail, or not run?
  • Did the agent verify the final diff?

That record helps a developer review the work and explain it later in a pull request or interview. It also makes it easier to find the exact point where an incorrect assumption entered the process.

What I would consider a good first version

The first useful version of Nerva does not need hundreds of policy settings. It needs a small set of predictable rules:

  • Default to read-only access.
  • Limit file access to a selected workspace.
  • Show exact commands before execution.
  • Ask before writes, deletes, network calls, and secrets.
  • Keep cloud model requests separate from local context.
  • Record decisions and verification results.
  • Make denial a normal, non-punishing outcome.

An agent earns trust when its boundaries are understandable under pressure. Nerva’s permission engine should make the safe path the obvious path, while still allowing a skilled developer to move quickly when the risk is clear.