Skip to main content
These Governance sections are available on every plan, on Luno OS Cloud and self-hosted: Audit logs, the permission groups under Roles, Budgets, Identity & auth (opened from 2FA), Hosted MCPs and Organization knowledge. Each still needs its permission (owners and admins by default, or a permission group). Plans differ in quotas and credits only (see Billing).

​
Audit logs

Governance → Audit logs is an append-only record of security-relevant activity: sign-ins (including failed sign-ins and sign-outs), member invitations, acceptances, role changes and removals, API keys, credentials, managed services, projects (create, settings, deploy started / completed / activated, members), billing changes, Brain access changes, agent and workflow runs (including runs started over MCP or A2A, with their source) and workflow restarts, tool-call approval decisions (from the web app, CLI, API, Slack or Teams) and approver changes, messages sent into agent sessions, chat channel connections and Slack channel creation, Teams tenant link requests, confirmations, rejections and disputes, agent memory deletion, eval uploads, and every change made on the pages below. Each entry records who did it, what it targeted, when, and the source IP when available. Secrets and tokens are never recorded. Filter by event group or search by actor and target, then export the current filter as CSV (GET /api/audit-logs/export, or ?format=json). Entries survive deleted users and resources.

​
Integrity

Entries cannot be edited or deleted: the database rejects UPDATE, DELETE and TRUNCATE on the log. This guards against accidental and application-level deletes, not against the database owner or a superuser, who can disable the guard; the hash chain is what makes such changes detectable. Each organization’s entries also form a hash chain — entry n stores seq = n, the previous entry’s hash, and
where the first entry chains from 64 zeros and canonical_json is JSON with keys sorted at every depth and no whitespace over v: 1, id, organizationId, seq, actorUserId, actorLabel, action, targetType, targetId, targetLabel, ip, metadata and createdAt (ISO-8601 UTC with milliseconds). GET /api/audit-logs/verify (SDK: enterprise.audit.verify()) recomputes the chain and returns the first broken link (seq_gap, prev_hash_mismatch or hash_mismatch), so an edited, removed or reordered entry is detected. Entries recorded before chaining was enabled are reported as unchainedCount and are not covered. Retention and organization deletion remove a prefix of the chain through one database function, which leaves a checkpoint (the last removed hash) so the remaining entries still verify. The chain detects changes inside the log; to also detect removal of the newest entries, keep a copy of the latest head hash outside Luno.

​
Permission groups

Permission groups live in Governance → Roles, next to the organization roles (rename those, edit their permissions or add custom roles). Permission groups add capabilities on top of a member’s organization role. Create a group, tick the capabilities it grants (for example View audit logs or Manage billing), and assign members. Groups are additive: they never remove a role’s grants. You can only add a capability to a group if you hold it yourself, and you cannot assign a group that grants more than you hold.

​
Budgets

Governance → Budgets sets monthly caps (UTC calendar month) on: When several budgets apply, the tightest one wins. Each budget has:
  • Heads-up: thresholds (70, 80 and/or 90%) and the members who hear about them (nobody picked = the organization’s owners and admins). Reaching the cap always notifies. Heads-ups arrive in Notifications and by email, once per threshold and month.
  • At 100%: Pause rejects new runs with 402 and a message naming the budget until next month or until the limit is raised; Wait for approval holds new workflow runs (agent prompts are turned away, see below) and asks the budget’s heads-up recipients (Notifications and email) to approve extra budget for the rest of the month or reject the request, from the budget’s page; Keep running only notifies; Switch to a cheaper model keeps runs going with the gateway model you pick for their agents, including the sub-workflows and agent tools they start (LLM budgets only).
  • Approvals (Wait for approval): an approval adds the amount you enter to this month’s cap; once that is used up too, a new request goes out. A rejection keeps new runs rejected for the month; saving the budget again (for example with a higher limit) starts over.
  • Held runs (Wait for approval): a workflow run the budget blocks (started from the dashboard, the API, a project app, a form, MCP, a trigger or a schedule) is kept with its input in the Waiting for budget approval state, shown in Runs, the workflow’s runs and the run detail with the people who can approve (the heads-up recipients, else the organization’s owners and admins). It starts by itself once someone approves (or the limit is raised or the budget removed), going through the budget check again, so it waits again if the approved amount is already used up. It fails with the reason when the request is rejected or when the month ends first. A schedule keeps only one held run while it waits: later ticks are skipped (recorded as canceled runs with the reason) instead of all starting together on approval. A run started by a trigger, a subscription or a person keeps acting as that person however long it waited; if they left the organization (or turned off their subscription) in the meantime, it fails with that reason instead of starting. You can cancel a held run.
  • Agent prompts (Wait for approval): a message to an agent, Luno or the Luno Builder is not held. The chat shows that it is waiting for budget approval and puts the message back in the composer, the API answers 402 with code: "budget_approval_pending", and the person gets a notification once someone approves or rejects the request, so they can send it again.
  • Forecast: spend so far ÷ days elapsed × days in the month, with the day the pace reaches the cap.
Caps are checked when an agent prompt, public form submission, Luno Builder prompt, hosted MCP call or dashboard workflow run is accepted, and again before a hosted worker dispatches a run (which covers trigger and schedule runs). An app budget covers runs started from that project app (its workflow runs and agent prompts, not the sub-workflows or sub-agents they start) and is checked when the app starts a run. Click a budget for its detail page: daily LLM spend and its breakdown by model, person, workflow, agent and app. A person’s own cap is set from their page (Governance → People → a person → Edit cap) as a monthly LLM spend budget in US dollars (for example $400/month). The page shows this month’s spend against the cap, and the daily spend bars turn red on the days spent at or over it. It is an ordinary member budget, so it is enforced like any other (Pause by default).

​
Identity & auth

Open it from Governance → 2FA (Identity provider → Manage). Connect a SAML 2.0 or OpenID Connect identity provider (Okta, Entra ID, Google Workspace, and others):
  1. Add identity provider. Enter the issuer, the email domain(s) it serves, and the OIDC client or SAML SSO URL and signing certificate. Copy the redirect URI (OIDC) or ACS URL / SP metadata URL (SAML) into your IdP.
  2. Verify the domain. Publish the shown DNS TXT record and select Verify domain. A provider cannot sign anyone in until its domain is verified, and a verified domain belongs to one organization.
  3. Sign-in policy. Require IdP sign-in blocks password, magic-link and social sign-ins for members whose email is on a verified domain. Organization owners keep those methods as break-glass access so a misconfigured provider cannot lock the organization out. Just-in-time provisioning adds first-time SSO users to the organization with the default role.
  4. SCIM provisioning. Generate a SCIM token and give your IdP the SCIM base URL (/api/auth/scim/v2) and the token. Activating a user provisions an organization member; deactivating suspends them. Regenerating the token revokes the previous one. SCIM requires a Postgres deployment.
People sign in with SSO through Continue with SSO on the login page, which finds the provider from the email domain.

​
Hosted MCPs

A hosted MCP is an endpoint that exposes selected workflows as tools to external MCP clients such as Cursor or Claude. Create one, choose its workflows and whether it is private (only you) or visible to the organization, and copy its URL (/v1/mcp/hosted/<organization>/<slug>). Authenticate with MCP OAuth or with an organization API key as the bearer token. Each tool takes the workflow’s input schema. A call starts a run as the calling user and waits up to about 55 seconds for the output; longer runs return their run id. Tool calls are written to the audit log.

​
Organization knowledge

Governance → Organization knowledge shares a Brain with every project in the organization, including projects created later, either read-only or read and write. Agents and workflows still reference the Brain by slug. Revoke the sharing at any time; per-project grants are managed from the Brain itself.