> For the complete documentation index, see [llms.txt](https://docs.kinesis.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kinesis.network/organizations/settings.md).

# Settings and audit log

Set organization controls and trace activity in the audit log.

Open **Settings** in the sidebar's **Organization** group. Admins can rename the organization and change its controls. Renaming leaves the URL slug unchanged. Other members can read the name, URL and switches.

## Compute and invitation controls

| Setting                                                      | Enabled                                                            | Disabled                                                                   |
| ------------------------------------------------------------ | ------------------------------------------------------------------ | -------------------------------------------------------------------------- |
| **Kinesis serverless capacity** (`serverlessEnabled`)        | Developers can run apps on Kinesis-managed serverless CPU capacity | Developers must target an accessible grid; admins can still use serverless |
| **Non-admin members can invite people** (`membersCanInvite`) | Developers can invite Developers and Viewers                       | Only admins can send new invitations                                       |

Both settings default to enabled. Disabling serverless capacity does not stop apps already running. It prevents developers from creating, starting, restarting or rebuilding serverless apps, and from changes that need new serverless machines. Select a grid in the app's Resources settings, or ask an admin.

Disabling developer invitations leaves invitations already sent valid. Review and revoke pending invitations separately when needed.

## Single sign-on

Contact support to connect your organization’s identity provider. Once enabled, this Settings section shows its verified domains and sign-in link. Admins choose the first-sign-in role, open the provider setup portal, refresh domains and optionally require SSO. The requirement uses a 24-hour browser sign-in window and does not revoke existing API keys or connected apps. Read the [SSO guide](/organizations/single-sign-on.md) for setup, recovery and offboarding.

Admins also register the organization's SSH public keys in Settings. Assignment depends on server eligibility; use the [server setup reference](/mcp/tools/server-setup.md).

Your personal profile, sign-in methods, API keys and connected apps are in [Account settings](https://portal.kinesis.network/dashboard/account), not organization Settings.

## Read the audit log

Admins open **Organization → Audit log** to see who changed the organization's members, settings, projects, apps, grids and servers. The log retains one year of activity, including recorded platform events. SSO setup, domain/default-role/requirement changes, SSO joins, owner recovery sign-ins and support access are recorded, as are resource moves between organizations. Expand a row with a recorded diff to inspect field changes.

The API returns entries in **latest-recorded-first** order. Follow `nextCursor` for older entries. Each entry includes:

| Field                      | Meaning                                                                      |
| -------------------------- | ---------------------------------------------------------------------------- |
| `actor`                    | Person who acted; null for the platform or an account that is gone           |
| `action`                   | Recorded operation, such as `memberInvite`, `appCreate` or `serverProvision` |
| `outcome`, `errorCode`     | Success or error, and a code for a failed action                             |
| `details`                  | Action-specific context                                                      |
| `changes`                  | Field paths, change kinds and before/after values where recorded             |
| `at`, `role`, `viaSupport` | Time, actor's role and whether support acted while signed in as the person   |

Secret changes are marked as redacted; their values are not retained in the diff.

## API and MCP

`GET /org?org=acme` / `get_org` reads settings, caller role and frozen state. `PATCH /org?org=acme` / `update_org` changes the name or compute/invitation switches and requires `org:write` plus an admin role. SSO controls are portal-managed and are not fields on this public operation.

`GET /org/audit?org=acme` / `list_audit_log` requires **`audit:read` specifically**, plus an admin role. `org:write` and `members:read` do not imply audit access. The audit log names members, so grant this scope deliberately.

In compact MCP mode these actions live under `account` and `account_write`. Older connected apps must be re-approved with the new scopes before they can use them. See [OAuth for MCP clients](/mcp/oauth.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.kinesis.network/organizations/settings.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.