Secure access and API keys

People use authenticated web sessions. The CLI exchanges that sign-in for a revocable, plan-aware CLI session. Unattended applications and agents use organization-scoped API keys. Keep those identities separate so every action has a clear owner and permission boundary.

Web access

After sign-in, Sernixa uses the active organization and your role to determine which product areas you may view or change. If you belong to multiple organizations, confirm the active workspace before reviewing evidence or making an administrative change.

Use named user accounts. Do not share a human login between operators or use a browser session as an application credential.

Sign in to the CLI

sernixa auth login
sernixa auth status

The CLI displays a short code and opens the Sernixa approval page. Confirm the same code while signed into the intended organization. auth status reports the principal, organization, role, plan, and credential type without printing the token. sernixa auth logout revokes the session.

CLI palette visibility follows the authenticated plan for convenience, while the backend rechecks every protected command. Use API-key stdin only for CI or another explicitly unattended workflow.

Create an application key

An organization security administrator can:

1. open Dev;
2. select Generate key;
3. use a name that includes the application and environment;
4. choose only the roles the application needs; and
5. choose an expiry that matches the team's rotation policy.

The raw key is shown once. Copy it directly into an approved secret manager, confirm storage, and close the reveal dialog.

Configure and validate

Provide the key at runtime:

export SERNIXA_BASE_URL=https://api.sernixa.com
export SERNIXA_API_KEY="<your-organization-api-key>"

Validate the identity before the first governed action:

import { Client } from '@sernixa/sdk'

const client = new Client()
const identity = await client.whoami()

console.log({
  organization: identity.organization_id,
  key: identity.key_id,
  roles: identity.roles,
  permissions: identity.permissions,
})

Stop if the organization or permissions are unexpected.

Scope and store keys

• Create a separate key for each application and environment.
• Grant the minimum roles needed for that integration.
• Keep production keys out of developer laptops and local configuration files.
• Use a secret manager with access logs and controlled delivery.
• Restrict who can generate, read, rotate, and revoke credentials.
• Set an owner and expiry for every key.

Rotate without downtime

1. Create a replacement key with the same or narrower access.
2. Store and deliver it through the approved secret path.
3. Update one application instance or canary.
4. Run whoami() and one controlled governed action.
5. Roll out the replacement to the remaining instances.
6. Revoke the old key.
7. Confirm no caller continues to use it and investigate later failures.

Revoke after exposure or retirement

Revoke a key immediately when it is exposed, its application is retired, or its owner and purpose can no longer be established. Then remove it from every secret store and deployment path, review recent use, and replace any related credentials that may also be at risk.

Troubleshoot authentication

Authentication failures are setup failures, not policy blocks. Repair the credential path before retrying the governed action.

Next step

Follow Integrate an agent to use the key, then govern your first action.