Fill it in, ask it questions.

Getting started

MunkiWho is a directory you fill in and read. There is nothing to install on anyone's machine and nothing is monitored: it records what exists, what belongs to what, and who is meant to have access to it. That is a deliberate choice, and it is what makes the directory worth something to compare a real system against.

Start with people, because everything else hangs off them. Import them from a CSV if you have one — a leavers-and-joiners export from HR, or the user list from your identity provider — and the import matches on email so running it twice updates rather than duplicates. Then add groups and put people in them, then folders, and give the folders their permissions in terms of the groups. Licences and assets can come later; they are assigned to people, so the people have to exist first.

The left-hand navigation is grouped the way the data is: Overview, then Directory (Users, Groups, Folders), Inventory (Licences, Assets), Tools (Checklists, Knowledge, MunkiKey), and Access, which is where accounts and settings live.

People and groups

A person is a record: name, email, title, department, manager, start and end dates, and free text. They can be marked as having left, which keeps everything they had on the record — that history is usually the thing an audit asks for. They can also carry aliases, so a person known to three systems by three addresses is one record here.

Groups carry a category, and the category is what tells a reader what kind of thing they are looking at:

Groups can nest. A person in a group that is in another group is a member of both, and everything that resolves membership — a folder's "who can access", the MCP server's get_group_members — follows the nesting rather than reporting only direct members.

A group can have owners as well as members, and a shared mailbox can record who is delegated to it. Neither changes anything in Microsoft 365 or Active Directory: MunkiWho does not sync to them, in either direction. It records what is meant to be, which is precisely why it can be checked against what is.

Folders and permissions

Folders are a tree, and each one records where it lives — a SharePoint site or a network file share — and who may do what to it. A permission entry names a person or a group, a level, and whether it is an allow or a deny.

This is the question the folder model exists for, and the one no permissions dialog answers well. Open a folder's access view and MunkiWho resolves every entry through group membership, including nested groups, and lists the people — each counted once, however many routes they have in, with the route shown.

Folders are not counted towards your band, however deep the tree, so there is no reason to model a share less completely than it really is.

Licences and assets

A software licence records what is held, how many seats, who they are assigned to, and when it expires. Licences carry a category so a list of forty can be read by kind. Seat counts against assignments are shown on the licence, so "6 of 6 seats assigned" is visible before a renewal rather than after somebody cannot log in.

An asset is a piece of hardware: a laptop, a workstation, a printer, a server. Each has a type, and you can define your own types beyond the defaults. An asset can be assigned to a person and carries a maintenance log — dated entries of what was done to it and by whom — so a machine's history travels with it when it changes hands.

People, groups and assets each count as one record towards your band. Licences do not.

Checklists

A checklist template is a list of steps — order the laptop, create the mailbox, add to the on-call rota — and a run is that template started for a particular person on a particular date. Onboarding and offboarding are the obvious ones; anything repeatable works the same way.

Steps are ticked off as they are done, and ticking is a deliberate act: a change to a run is staged and confirmed rather than saved on every click, so a checklist read aloud in a meeting does not end up with steps ticked by accident. A run shows how far it has got, and the MCP server's get_onboarding_status answers "what is still outstanding for Dana?" from the same data.

Templates and runs are not counted towards your band.

Knowledge base

Uploaded files, organised into folders. Runbooks, the wifi password policy, the diagram of which switch is which — the things that otherwise live in one person's head or a chat thread nobody can find again. It works like a file explorer: folders and files show as cards, clicking a folder opens it, and the breadcrumb takes you back out. Folders nest, and an empty folder is a real thing you can create first and fill later. Search looks across every folder at once.

It is a knowledge base rather than a drive, and three limits hold it to that. Each file may be up to 50 MB. Only documents and images are accepted — PDF, Word, Excel, PowerPoint, OpenDocument, text, Markdown, CSV and common image formats; archives, media and programs are refused. And the store has a size allowance that comes with your band, shown at the top of the page: 1 GB on 250 records, 2 GB on 750, 5 GB on 2,000 and 10 GB on 5,000.

Files are never counted towards your record band — a document is not a record. Reaching the storage allowance stops new uploads and nothing else: everything already there still opens and downloads, and deleting what you no longer need makes room immediately.

MunkiKey

MunkiKey generates passwords and, separately, sends them. The two halves are independent: you can generate without sending, and you can send a password you got from anywhere.

Three kinds. All of them are drawn from the browser's cryptographic random number generator, and nothing generated is saved or recorded anywhere — close the tab and it is gone.

The strength shown is an honest one: requiring at least one of each ticked kind slightly shrinks the space, and the figure accounts for that rather than quoting length × log₂(pool).

Paste the password to send, choose how many times the link may be opened (1 to 10, five by default) and how many days it lasts (1 to 14, seven by default), optionally set a PIN the recipient must also know, and add a note for your own records. You get a link. Send it whole.

Your recent links that are still open are listed under the form with how many openings remain, and any of them can be withdrawn. Withdrawing destroys the ciphertext rather than hiding it; a recipient who follows the link afterwards is told you withdrew it, not that it expired. Whichever runs out first — openings or days — ends a link, and the last opening destroys it in the same instant.

Pushing a password writes an audit entry: who, when, and your note. Never the password. Generating one writes nothing.

Accounts, roles and SSO

Logins are unlimited on every band. Every account carries one of four roles:

Any change to the directory goes through a second step — save, confirm, apply — before it is written. Nothing is modified on a single click.

There are two, and they answer different questions. Settings › History is the directory's own: every change ever made to a person, group, folder, licence, asset or checklist, by everybody, with who and when, filterable by type, action, person and date, and exportable as CSV. Owners and administrators only. Settings › Audit is the server's: sign-ins, role changes, API tokens, MCP, SSO and licence actions. On a workspace that also runs MunkiSee, it shows only what belongs to MunkiWho — device approvals and monitoring changes stay on the MunkiSee side.

The History button in the ribbon is a third thing and stays as it is: your own current session's changes, each with an undo beside it. Settings › History is the whole record and has no undo — it is what happened, not what can be taken back.

SSO is OpenID Connect. Microsoft Entra ID is configured with its directory (tenant) ID; Okta and any other OIDC provider are configured with their issuer URL. Paste the client ID, client secret and redirect URI into Access › SSO, test it against the provider, then switch it on. Accounts provisioned by SSO get a default role you choose, and their identity is the provider's — not their email, which a directory can reassign.

Multi-factor authentication is available on every local account and is enforced on hosted accounts. SSO-provisioned accounts leave MFA to the provider.

API tokens

Named tokens give scripts and integrations direct access. Each token is granted no access, read, or read and write to the directory, and anything it was not granted is refused — including endpoints added after the token was issued. Write includes read. A token can be revoked at any time and stops working immediately.

curl https://app.munkiwho.com/api/v1/munkiwho/records/UserProfile \
  -H "x-api-key: <token>"

Records are returned as JSON, one array per entity: UserProfile, Group, FolderItem, License, Asset, and the rest. Tokens work the same way on the hosted service and on a self-hosted install.

The address is your own workspace's: app.munkiwho.com if you bought MunkiWho on its own, app.munkisee.com if you added it to MunkiSee, and your own host if you self-host. The paths below it are identical on all three.

MCP server

The MCP server exposes the directory to an AI assistant as tools it can call, over the Model Context Protocol. It is included on every band. Enable it in Access › API and MCP, which also generates its own key — separate from any API token — and shows the configuration snippet for your assistant, filled in with your own address.

{
  "mcpServers": {
    "munkiwho": {
      "url": "https://app.munkiwho.com/api/v1/mcp",
      "headers": { "x-api-key": "<your MCP key>" }
    }
  }
}

The tool names are deliberately not MunkiSee's. list_users on a MunkiSee workspace means "people the fleet has seen at a machine", a different population from "people in the directory" — an assistant holding both must never have to guess which it called. A workspace with both products gets both sets from the same endpoint.

Import, export and the bin

Access › Data exports one CSV per section — people, groups, folders, licences and the rest — as they stand right now. It works on every band, at any time the workspace is active, and it is the whole answer to "can we get our data out": yes, all of it, whenever you like.

Bring people, groups or other records in from a CSV. Existing records are matched and updated rather than duplicated, so a re-import from HR is a refresh, not a second copy of everyone. Column headings are matched by name; the export format is the import format, so the simplest way to get the shape right is to export first.

Deleting a record moves it to the bin with a full snapshot, and it can be restored under its original identity so everything that referenced it reconnects. The bin keeps the hundred most recent deletions. Nothing in the bin counts towards your band.

Going over a band stops new records being added and nothing else — reads, edits, deletes and exports all continue. If a workspace lapses, it locks rather than losing anything, and everything is there again when a plan is back in place.

Self-hosting

A self-hosted MunkiWho server is a Windows installer, the same shape as self-hosted MunkiSee. It carries its own copy of Node and everything it depends on, registers itself as a Windows service, and serves the same interface hosted customers use from http://your-server:3001. Data lives in SQLite alongside the install; back it up by backing up the folder.

It is licensed by the same bands. Talk to sales for installers and a licence key, and see the MunkiSee self-hosting notes for the installer's answer file and service details, which are identical.

The obvious assumption is wrong: a self-hosted server does not need to be reachable from the internet to send password links. It creates a link with an outbound call to the licence server — the same direction, and the same credential, as the licence check it already makes — and the link points at our host, so a recipient never touches your network.

Customers who cannot let a secret leave their own infrastructure even encrypted can run the push store themselves; that is the one case that needs configuration, and sales can walk you through it.