Access credentials¶
Create and manage the credentials used for programmatic access to MOI at the account level. The console Access credentials page is the single place to obtain keys. Cards on the page separate personal access tokens from service accounts by usage; they are not two unrelated key-issuance systems.
Credentials belong to the account. They are not workspace member or role settings.
What this page is for¶
Obtain credentials for the API, SDK, or CLI.
View, rotate, disable, or delete credentials you already created.
Choose between access as yourself and access as an app or machine identity.
How to open it: in AI Studio or another product, select your user avatar in the top-right corner, then Access credentials. The page breadcrumb returns to Account management.
If the page reports that credential capabilities cannot be loaded, the current account or environment does not expose them. Follow the UI message; do not look for an undocumented alternate place to mint a primary key.
Choose a type¶
Select a card to switch type, then create or manage credentials under that type.
Your scenario |
Use |
|---|---|
Local development, scripts, BI direct connections, and other personal work where permissions should match your signed-in user |
Personal access token |
Long-running app or machine calls where permissions must be granted separately and must not follow a person |
Service account |
Both cards live on Access credentials. Confirm the correct card is selected before you choose Create token or the service-account create action.
If a card or create control is unavailable, that type is not enabled in the current environment. Do not hunt for “another primary key” on a different product page.
Quickstart¶
Example path with a personal access token:
Open Access credentials and select the Personal access token card.
Select + Create token (or Create token).
Enter a unique Name, choose an Expiration, and confirm.
In the success dialog, copy the full token value immediately and store it in an environment variable or secret manager.
After you close the dialog, the list shows only a masked value. The system does not keep plaintext; if the value is lost, use Update token to rotate.
Save example:
export MOI_ACCESS_TOKEN='<full token copied from Access credentials>'
Calling a product also requires that product’s address and request shape:
Genesis models: use the Base URL on the console Use page; see Call a Genesis model and Endpoints and authentication.
AI Studio workspace resources, automation, or agents: use the Endpoint and headers from the target resource call panel; see Product API quickstart.
Go or Python SDK: see Get started with Product SDK.
Product CLI: see MOI-CLI quickstart.
How the credential is sent follows the target capability doc or call panel. Do not use browser cookies or keys from other products as substitutes for credentials from this page.
What you can do¶
After you have a credential, open the guide that matches the task:
What you want to do |
Go here |
|---|---|
Send a Genesis model request |
|
Call an AI Studio resource that exposes call details |
|
Trigger an automation task |
|
Send a message to an agent |
|
Integrate with the Python or Go SDK |
|
Debug with |
|
Genesis model key policy and quotas |
|
Developer overview |
Who can enter a workspace and which console features they can use is controlled by members and roles, not by the HTTP credentials on this page. See User permissions.
Personal access tokens¶
What it is¶
A personal access token accesses MOI as you. Permissions match your account. Use it for local development, personal scripts, and BI direct connections.
When to use it¶
Use when |
Do not use when |
|---|---|
Calls may follow your personal permissions |
You need a long-lived machine identity decoupled from a person (use a service account) |
You are debugging the API, SDK, or CLI yourself |
You would embed the token in a frontend, mobile app, or public repository |
You need a quick token with a clear purpose name |
You expect to view the full plaintext again after closing the create dialog |
List columns¶
In personal-access-token mode, the table commonly includes:
Column |
Description |
|---|---|
Name |
Purpose note, such as “Local CLI” or “CI pipeline” |
Token |
Masked display; full value is shown only at create or update |
Created at |
Creation time |
Expiration |
Expiration date; after creation you cannot change expiration alone—use Update token to rotate and reset it |
Last used |
Most recent use, if any |
Status |
Active, disabled, expired, deleted, and similar |
Actions |
Edit, update token, disable / enable, delete |
Create¶
Select the Personal access token card.
Select + Create token.
Enter a Name and an Expiration (for example 30 / 60 / 90 / 365 days or a custom value within the UI limit).
Confirm, then copy and store the full value from the dialog.
Edit the name¶
Edit changes only the display name. It does not change the token value or expiration.
Update token (rotate)¶
Update token issues a new value and resets expiration. The old value becomes invalid immediately.
Name and permission semantics stay the same.
Expiration cannot be extended without rotating.
Whether updating an expired token restores access follows the UI result.
Deploy and verify the new value on every caller before you drop the old dependency.
Disable, enable, and delete¶
Disable: Calls using the token are rejected immediately; you can enable it again.
Enable: Restores access when the token is not expired or deleted.
Delete: Permanently invalidates the token. Confirm no script or integration still depends on it.
Service accounts¶
What it is¶
A service account is an independent identity for an app or machine. Permissions are granted separately and do not change automatically when a person joins or leaves. Use it for downstream applications and long-running production automation.
Two layers to keep straight¶
Concept |
Meaning |
|---|---|
Service account |
Who is calling: an identity separate from a person |
Key / API key under the account |
How to authenticate: the secret sent with requests |
Granted product permissions |
What it may access: model or product scope from the authorization setup |
Create and manage these materials on the Service account card of Access credentials. If the deployment also offers local issuance on the Genesis Keys page, see Manage API keys for that relationship; this page remains the primary place to obtain credentials.
Create and use¶
When the Service account card is available and exposes create actions:
Select the Service account card.
Create the service account and complete any required product authorization in the UI.
Issue or create a key, copy the full value from the dialog, and store it securely.
Inject the value through environment variables or a secret manager. Header names and Base URL follow the target product’s call instructions.
If the card or create control is unavailable, service accounts are not enabled in this environment. Do not bypass the UI with undocumented paths.
Manage¶
Within the actions the UI provides, view, rotate, disable, or delete the service account or its keys. After rotation, the old key is invalid; update every caller.
Security¶
Full credential values are usually shown only at create or update. After you close the dialog, plaintext cannot be retrieved.
Store values only in server-side environment variables or a secret manager. Do not put them in source code, images, logs, ticket screenshots, or client-side code.
Split credentials by purpose and name them clearly so you can rotate or revoke one path without touching others.
If you suspect a leak: disable or update / delete first, then review recent calls and business impact.
When people leave or a project ends, delete or rotate personal tokens still in force. Prefer service accounts for machine identity instead of personal tokens.
Use in the API and SDK¶
Copy the credential from this page into an environment variable (see Quickstart).
Open the target capability doc or console call panel and confirm:
Request URL (Base URL or full Endpoint)
Authentication header name and value shape
Minimal body or SDK client setup
Send one read-only or minimal write request and confirm the result before wiring business logic.
Genesis model Base URL and Bearer setup: Endpoints and authentication. Do not copy model-page examples onto workspace resources; use each resource call panel.