Nerva’s model may be written in a high-level language, but permission decisions should not depend on whether a model sounds confident. The planned Rust permission engine is meant to be an independent control point for actions that can change the machine or move data.

What the engine should decide

The permission layer can evaluate:

  • Which workspace or files are targeted.
  • Whether the operation reads, writes, deletes, executes, or uploads.
  • Which host receives a network request.
  • Whether secrets or private data are involved.
  • Whether the action is covered by a saved policy or needs approval.

The engine should return a small decision: allow, ask, or deny, plus a reason the UI can show. It should not generate a new command or negotiate with the model.

Why an independent boundary helps

If the model both proposes and authorizes an action, a prompt injection or a mistaken assumption can bypass the user’s intent. A separate engine can apply rules even when the proposal came from a local model, a cloud model, a repository file, or a recovery path.

For example, a command to run a test may be allowed inside the selected workspace. A later command that uses sudo, reads a keychain, or uploads a log is a different request. The engine should not treat it as automatically approved because it appeared in the same task.

Rust is useful, not magical

Rust can make the permission component explicit and robust, but it does not solve policy design by itself. Poor rules can still be unsafe, and a secure engine cannot help if the tool gateway passes it incomplete resource information.

The useful goal is a small, testable boundary with clear inputs and outputs. Nerva should show those decisions in its task history so a developer can understand why an action ran, paused, or stopped.

The useful design question

The useful question here is not whether an AI agent can produce an impressive demo. It is whether the workflow stays understandable when the task is incomplete, the repository is messy, or the model is wrong. For this part of Nerva, the focus is enforcing sensitive-action policy outside the model. That means each state should have a visible owner, a small input, and a result that another part of the system can inspect.

A concrete scenario

Consider requiring approval before a backend task can write files or use network credentials. A good Nerva run would first state the scope, identify the files or operation it needs, and show the next proposed step. It would keep the original request separate from model-generated instructions. If an action needs approval, the user would see what will happen before it happens. Afterward, the task history would retain the command, result, and verification status instead of reducing everything to a confident paragraph.

This approach also makes a failure useful. A denied permission, unavailable provider, missing package, or changed file is information about the task state. Nerva should preserve it and explain the smallest recovery option. It should not silently broaden the request, retry a side effect, or claim completion because a model supplied plausible-looking text.

What I would test first

For an early implementation, I would test three paths: a normal successful run, a denied action, and an interrupted run resumed after the workspace changes. The key test is which facts the permission decision must receive and record. In each path, the interface should make clear what Nerva knows, what it proposed, what actually ran, and what remains unverified.

Useful acceptance checks include:

  • the user can inspect the selected context before model execution;
  • sensitive paths and credentials are excluded or redacted;
  • every side effect has a narrow permission decision;
  • failures remain attached to the step that caused them;
  • a final answer links to evidence instead of implying that unrun work succeeded.

Nerva is still an upcoming project, so these are design and implementation goals rather than claims that a finished product already provides them. That distinction matters: a trustworthy agent should earn confidence through observable behavior, not through a feature list.

The boundary that matters in production

Permission checks should describe the action in user language and machine language. The preview might say “write src/worker.ts and run the focused test,” while the policy record stores the operation, paths, working directory, network access, and expiry. Approval should be scoped to that operation, not treated as a permanent permission for the whole application.

For the first vertical slice, keep the boundary small enough to explain in a code review. Define the input, the decision, the side effect, and the evidence for completion. Add a test for the denied path as well as the successful path. This is where a local-first design earns trust: the user can inspect the context and history on the device, see when a provider is involved, and stop before an action crosses the permission boundary. The design should remain honest about its limits. Nerva is planned software, not a claim that every workflow can be made safe automatically. A clear “cannot verify” state is more useful than a polished but unsupported success message.

A review of this design should use a small fixture repository and record both allowed and rejected outcomes. That keeps the discussion concrete: reviewers can compare the requested scope with the selected context, action, and evidence. It also prevents Nerva from being judged only by how persuasive its response sounds.

The design is informed by the boundaries I have had to think through in CryptoEx and SentinelFi: backend work becomes easier to review when context, permissions, side effects, and verification are explicit.