Secure access and API keys

People use authenticated web sessions. 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.

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.