---
title: "Approvals and signatures"
---

# Approvals and signatures

How to enrol your device, approve an action in the Editor, request a signed approval from other people, sign a request, and request a waiver, and how approval records travel with your repository.

When your organisation's policy says an action needs approval, you are asked before it runs. Some approvals you can give yourself; others need electronic signatures from other enrolled people. Signatures are files in your repository, so they travel through git, are reviewed in pull requests, and are verified by CI.

## Enrol your device

To sign approvals, your device key must be enrolled in your organisation's policy. Until it is, you hold no governance roles and your signatures count for nothing.

1. Open the **Governance** panel, Governance view.
2. Choose **Copy Key for Enrolment**. This device's public key and fingerprint are copied ("This device's public key was copied. Send it to your administrator to enrol it in the policy.").
3. Send it to your administrator, who adds it to your entry in the policy and signs a new policy.

Roles exist only in the signed policy; nothing on your device grants one. The view shows how the policy sees you under **You, as the Policy Sees You**, and whether your key is hardware backed or a software key.

## When an action needs approval

Agent actions and in-app actions (installing an extension, trusting a workspace, running a task, adding an MCP server, picking a model, keeping an agent's changes, changing a Neural Inverse setting) can come back as needs approval.

- **No approval rule and no control behind the decision**: the dialog shows the rule and the reason, and you, the person present, can approve that one action.
- **An approval rule or a control applies** (for example two reviewers for safety-classified code): you cannot approve it yourself. The dialog offers **Request Approval**. Once other enrolled approvers have signed, try again; governance then allows exactly that action, or exactly that content, and nothing else.
- **The policy names no approval rule** for an action that needs one: nobody can approve it ("The policy names no approval rule for this, so nobody can approve it. Ask your administrator.").
- **Nobody is present** (an unattended agent session or automation): needs approval is a refusal.

An approval never overrides a deny.

## Request an approval

1. In the Governance panel or the Command Palette, run **Request Approval...**.
2. Choose what to approve: a change set (the exact content of the files you pick) or a waiver.
3. For a change set, choose the **Files in the Change Set**, give a **Change Set Title**, and name the **Requirements** it addresses. The **Approval Rule**, the people who may sign and how many come from the policy; you do not choose them.
4. The request is written under `.neuralinverse/records/requests/` in the repository: "Approval request ... was created under rule .... Commit .neuralinverse/records and ask an approver to sign it in the Approvals view; then try again."
5. Commit `.neuralinverse/records` and push, so approvers see the request.

A request from an action dialog is created the same way, for exactly that action.

## The Approvals view

The Approvals view in the Governance panel has four sections:

| Section | Shows |
|---|---|
| Assigned to Me | Requests you may sign |
| Mine, Waiting on Others | Requests you made |
| History | Decided and expired requests |
| Problems | Records that do not verify, with the reason |

**Refresh Approvals** reads the records again.

## Sign a request

1. Open a request in the Approvals view, or run **Sign Approval Request...**, or open a sign link a colleague sent. You see the title, the kind, the content digest, the requester, the rule and the expiry.
2. Choose approve or reject, the meaning (review, approval, responsibility, authorship), and give a reason.
3. Re-authenticate: Touch ID on macOS, your Windows account password on Windows, or elsewhere your signing passphrase. You set the passphrase on first use; it must be at least 12 characters and is checked against a verifier kept only in the OS keychain.
4. The signature is made with your device key and written to `.neuralinverse/records/signatures/`. Commit it with the change.

You can sign from the Editor or the Agents app. The device key is held by whichever of the two started first; when you sign in the other, the prompt comes from the app that holds the key, and that app signs. If it cannot be reached (it is quitting or not responding), nothing is signed: try again in a moment.

### Who may sign

- You cannot approve your own change, a change an agent made at your prompt, or a request you made.
- One person counts once.
- A signature covers exactly the content you reviewed. If anything changes afterwards, the approval no longer counts and the gate says so.
- Requests expire after the time the rule sets.
- A rule can require signatures in order (for example a reviewer, then a quality manager).
- A qualifying rejection rejects the request.

Each signature records your printed name and principal, the time, the meaning, the reason, the request and content digests, your enrolled public key, and how and when you re-authenticated. Re-authentication must be no more than five minutes before signing.

## Request a waiver

A waiver lets a specific control not apply to specific paths for a time. Run **Request Approval...** and choose a waiver, then fill in **Waiver: Control**, **Waiver: Reason**, **Waiver: Duration** and **Waiver: Scope** (paths). The waiver applies once it is approved under the policy's waiver rule, and stops applying at expiry. Waivers in force are listed under **Active Waivers** in the Governance view.

## How approvals reach the gates

- A signed approval of exactly a change set satisfies the review controls (`ai-hunks-reviewed`, `reviewed`) at the commit and merge gates, when the rule is the one the policy names for those files, the commit's authors are enrolled, and none of them signed it.
- Under an organisation policy, the merge and release gates in CI verify every approval and signature record in the repository. A record that does not verify fails the gate.
- Approval records are left out of every change set digest, so committing a signature does not change what it signed.

See [Intent, projects and releases](https://neuralinverse.com/docs/editor/intent-and-projects/) for the gates.

## What a device signature shows

Each signature is bound to the exact content and request, carries the printed name, time and meaning, is verified at every use, and every request, signature and refusal is recorded in the tamper-evident activity record. This is evidence toward electronic-signature requirements such as 21 CFR Part 11 and EU GMP Annex 11, not a certification.

A device key proves which device signed and which person your organisation enrolled it for. Proving that the enrolled key belongs to the named person (identity verification at enrolment), organisation-wide account rules and password policy are your organisation's processes. Windows Hello biometrics are not supported; Windows uses the account password.