Governance

This is the product. Everything else is plumbing that makes it useful.

What happens when you ask an agent to do something

Three outcomes, not two. "Parked" is the one that makes neutron different: the work is neither done nor thrown away, it is waiting on a named human, and the waiting itself is recorded.

You ask. In chat, by mentioning the bot on a merge request, or from another program over the /mcp endpoint.
The agent chooses a tool. It decides it needs to write a file, call an API, open a merge request.
The rules are checked before the tool runs. Not after. The check considers the agent’s safety mode, the specific tool’s policy, and who you are.
Everything is written down — the request, the decision, who made it, and what it cost.

Layer one — safety modes

Every agent has one of three settings. It is the coarse dial, set by an operator, applying to the agent as a whole.

readonlyCan look at anythingit has been granted.Changes nothing, ever.

approval-gatedCan propose a change,then stops and waits.The default posture.

readwriteActs on its own,no pause.For work you have alreadydecided is safe.

less powermore poweron top of the mode, each tool can carry its own policy — a readwrite agent can still have one tool gated

The mode is the floor, not the ceiling. Per-tool policy can tighten any single ability without demoting the whole agent, which is how a useful agent stays useful while its one dangerous verb stays locked.

Layer two — you cannot approve yourself

This is the part that turns a convenience feature into a control. Approval is not “someone clicks yes”. It is “someone other than the requester clicks yes”, enforced by the permission engine rather than by etiquette.

The permission model is relationship-based. Instead of a flat list of who is an admin, it stores facts like Priya is an approver for deployments and answers questions like may Priya approve request 41? The separation rule lives in the policy itself, as a subtraction: the set of people who may approve, minus the person who asked.

the engine answers the question; nobody has to remember the etiquettethe same query run backwards lists exactly who to notify

Membership in the approvers group is not enough — the policy subtracts the requester from the answer set. Priya keeps her role and still cannot sign off her own request.

This permission engine was pulled out of neutron into a standalone open-source library so other applications can use the same rules. It is published as @neutroncore/authz, currently version 0.4.0, and neutron consumes it like any other dependency.

Layer three — what an agent can even reach

Before permission is a question, ability has to exist. An agent starts with nothing and is handed things one at a time.

Layer	Granted by	Plain meaning
Connectors	Instance config	Which broad abilities exist at all on this deployment — search, vault, schedules, peer control. Off by default.
Capabilities	Operator, per agent	Specific external tools and skills an operator added and vetted, then handed to a named agent. Aware of logins to third-party services.
Resources	Operator, per agent	The repositories and written guides an agent may see. A guide is injected into the agent’s instructions when the grant is made.
Workspace	Instance config	A cached copy of repositories, each agent working in its own isolated checkout so two agents cannot corrupt each other’s work.
Seats	Per actor	Who — human or agent — is licensed to act on this instance at all.

The interrupt governor

An agent that works on a schedule produces output nobody asked for at that moment. The interrupt governor decides whether that output interrupts you or waits quietly: proactive results land as inbox cards, and quiet hours plus a priority rule decide whether anything surfaces immediately.