# Organisations and accounts · Neural Inverse Govern

> Organisations of accounts with organisational units, guardrail policies that member accounts cannot lift, delegated administration, consolidated billing and service quotas with increase requests.

Source: https://neuralinverse.com/govern/organizations/

---

![](/photos/team.jpg)

[Neural Inverse Govern / Organisations and accounts](https://neuralinverse.com/govern/)

# Every account in your organisation under one structure, one set of guardrails and one bill.

Organisations of accounts with organisational units, guardrail policies that member accounts cannot lift, delegated administration, consolidated billing and service quotas with increase requests.

Structure

Management account, units, member accounts

Units

Up to five levels deep

Policies

Service control policies and agent guardrails

Policy changes

Two-person approval by default

Quotas

Enforced on the server, with increase requests

Overview

An organisation groups the accounts of a company under one management account. Accounts are arranged in organisational units, and the policies attached to the root, a unit or an account limit what every person, key and agent in the accounts below may do, including the account's own root user. The management account pays for every member and sees each account's share, and service quotas show every limit with its use and let administrators ask for more.

[What it does ↓](https://neuralinverse.com/#capabilities)[How it works ↓](https://neuralinverse.com/#workflow)[Enforced and recorded ↓](https://neuralinverse.com/#enforcement)[Where it runs ↓](https://neuralinverse.com/#where)[Get started ↓](https://neuralinverse.com/#get-started)

What it does

## What organisations and accounts cover.

Structure, guardrails, delegation, billing and limits for a group of accounts.

- **Organisations of accounts:** Create an organisation with your account as its management account, with all features or consolidated billing only. Moving to all features takes a handshake that every member account accepts.
- **Create member accounts:** The management account creates new member accounts with their own account ID. A creation runs in the background, is counted against its quotas at once and is released if it fails.
- **Invite existing accounts:** Invite an account by its account ID or root email. Invitations expire after 15 days. An email is stored only as a keyed hash, and an address that matches no account gets the same answer as one that does.
- **Organisational units:** A tree of units under the root, up to five levels deep. Accounts move between units, and every new unit and account receives the policies that apply to its place in the tree.
- **Removal, leaving and closing:** Remove a member, let a member leave after a minimum time, or close a member account. Only the management account's root user, signed in as root, can close a member, and closing revokes every session, refresh token and access key.
- **Tags and contacts:** Tag accounts, units, the root and policies, and keep contacts for member accounts from the management account.
- **Service control policies:** Policies attached to the root, units and accounts set the most any principal of a member account may do, its root user included. A policy that cannot be loaded or read denies the request.
- **Agent guardrail policies:** Guardrails for AI agents attached over the same tree, with an effective view that shows the policies at every level and the merged result for an account.
- **Two-person policy changes:** Creating, changing, attaching or detaching a policy is a change request by default. It is checked in full when proposed, approved by a second person, and checked again when it applies.
- **Delegated administrators:** Register a member account as the delegated administrator of a service and turn on trusted access per service. A delegate cannot change any policy that binds itself or the management account.
- **Consolidated billing:** The management account is the payer for every member. A joining account moves to consolidated billing and a leaving one to free only, each with a billing history entry.
- **Cost per account:** The management account sees charges per member account for the time each was a member. Today the breakdown is built from priced model usage, and says so.
- **Service quotas:** Every quota with its applied value, default and current use. Quotas are enforced inside the change that would exceed them, and the server refuses to start if a registered quota has no enforcement point.
- **Quota increase requests:** Ask for a higher value from the console or the API. Requests within a self-service ceiling are approved at once; larger ones go to an operator queue where the reviewer cannot be the requester.
- **Projects and project policies:** Projects and sub-projects inside an account, with the resources linked to each. Model allowlists, residency and budget policies per project run in enforce or shadow mode, and a governance map lists every control that applies.
- **AI spend and licences:** Breakdowns, trends, forecasts, top spenders and export of AI spend, and a register of third-party AI tool licences with seats, use and renewal dates.

How it works

## How a guardrail policy change reaches every member account.

One person proposes; another approves; the change applies once and is recorded in both places.

1.  Propose
    
    An administrator of the management account writes or attaches a policy.
    
2.  Check
    
    The change is applied in a trial transaction and rolled back; one that cannot apply is refused now.
    
3.  Approve
    
    A second person with approval rights in the management account approves it. The proposer cannot vote.
    
4.  Apply
    
    It is checked again and applied; every account below the target sees it on its next request.
    
5.  Record
    
    The proposal, the votes and the change are in the audit log.
    

Who uses it

## Built for every role that answers for AI.

- **Platform and cloud teams:** Build the account structure, create and invite accounts, and arrange units.
- **Security teams:** Write service control policies and agent guardrails, and approve each other's changes.
- **Finance:** Read the cost per account and AI spend, and request quota increases with a billing role.
- **Account owners:** Accept or decline invitations, see the policies that apply to their account and leave when allowed.

Enforced and recorded

## Limits a member account cannot lift.

Policies, quotas and the actions that change who pays or ends an account are decided on the server.

Enforced

- **Policies:** Service control policies apply to every principal of a member account, the root user included, and never to the management account. A read or parse error denies.
- **Reserved actions:** Creating or deleting an organisation, leaving, accepting an invitation, removing and closing accounts need a standing Owner grant.
- **Delegation:** A delegated administrator acts only within the delegation policy and cannot detach, weaken or delete what binds itself.
- **Quotas:** A change that would exceed a quota is refused with the quota code, its value and the current use.

Recorded

- **Structure changes:** Account creations, invitations, moves, removals and closures, in the management account and in the member account.
- **Policy changes:** Every policy change request, vote and outcome, and every delegated administrator's change in both accounts.
- **Membership history:** Each account's time in the organisation is kept and never deleted, so costs and evidence follow the right owner.

Where it runs

## On the hosted service.

[Deployment options](https://neuralinverse.com/deployment/)

- **Hosted by us:** Organisations of accounts, consolidated billing and quota increase requests are part of the hosted service.
- **Self-hosted:** A self-hosted installation has projects, project policies and each service's quota limits on your own infrastructure. Organisations of accounts and billing are not part of it.
- **One region:** An organisation and its accounts live in one region of the hosted service, under that region's data residency.

Get started

## Set it up with the documentation.

-   [Govern concepts](https://neuralinverse.com/docs/govern/)
-   [Roles and permissions](https://neuralinverse.com/docs/govern/roles/)
-   [Access guardrails](https://neuralinverse.com/docs/govern/access-guardrails/)
-   [Budgets and rate limits](https://neuralinverse.com/docs/govern/budgets-rate-limits/)

What's next

## Being built now.

These are in development and not part of the product today.

- **More policy types:** Tag, backup, AI services opt-out, notification and declarative policies over the organisation tree.
- **Organisation-wide monitoring and trail:** A monitoring account that reads every member's metrics, logs and alarms, and one audit trail for the whole organisation.
- **Showback and chargeback:** Allocating cloud costs to teams and cost centres with your own rates and reports.
- **Invoice-based cost breakdown:** The per-account breakdown read from invoice lines for every service, not only priced model usage.
- **Budget rollup across the hierarchy:** Budgets that roll up from people and teams to departments and the organisation.

Related

[Identity and access →

Single sign-on, provisioning, least-privilege roles, just-in-time access and reviews.](https://neuralinverse.com/govern/identity/)[Audit and evidence →

A hash-chained audit log you can verify offline, and evidence toward your frameworks.](https://neuralinverse.com/govern/audit/)[Platform operations →

Self-healing, admission control, health probes, status page, SLA tracking, feature flags and signed alerts.](https://neuralinverse.com/govern/operations/)

![](/photos/team.jpg)

## Talk to our team.

Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation.

[Request access](https://neuralinverse.com/contact/?topic=access)[Contact us](https://neuralinverse.com/contact/)
