Usage, Identity & Security | Alephant Documentation

Usage, identity, and security controls are deployment or configuration-dependent. Review what the current deployment exposes before promising a capability or relying on it for a governance process.

Capability map

Capability	Use it when available	Verify before relying on it
Usage	Review available usage information for the intended organization scope.	Confirm the displayed scope and refresh behavior.
Query History	Investigate available query records when the deployment enables them.	Confirm the viewer’s permission and the retained results.
Tracing	Inspect request traces when tracing is configured.	Confirm that traces are enabled and visible only to authorized people.
Spending Limits	Apply available limits to control approved spending.	Confirm the limit’s scope and behavior with an approved test.
SSO and SCIM	Connect identity management when the deployment supports the required configuration.	Confirm sign-in, provisioning, and deprovisioning with a test account.
Security and appearance	Configure available hardening, localization, and appearance settings.	Confirm that the setting is present and has the intended effect.

Usage and query history

Use Usage and Query History only when the deployment exposes those controls and the viewer has the required access. Check the applicable organization, time range, and result scope before interpreting a value or record.

Query History is not a substitute for an access review. Limit who can view query content according to the deployment’s data-handling policy, and do not assume that every deployment retains or exposes the same records.

Tracing and spending limits

Tracing and Spending Limits are conditional capabilities. When configured, use tracing to investigate an approved request path and use spending limits to set the intended control boundary. Test both with representative authorized activity before treating them as operational controls.

If either control is absent, disabled, or unavailable to the current role, review deployment configuration and administrator settings rather than documenting it as enabled.

SSO and SCIM

SSO and SCIM require identity-provider and deployment configuration. Configure them only when the deployment provides the relevant controls and the identity team has approved the connection.

For SCIM, generate a token through the available deployment control and store it only in the approved identity-provider secret store. Use a placeholder in documentation and examples: <generated-token>. Test provisioning and deprovisioning with non-production accounts before relying on the connection.

Security hardening

Use the security controls that the deployment makes available to apply least privilege, protect credentials, and review who can administer sensitive settings. Keep credentials out of chat messages, Agent instructions, source control, and shared documents.

Revisit access after personnel, role, or integration changes. Security controls and their visible menus can vary with server configuration and administrator settings.

Appearance and localization

Appearance and localization controls are available only when the deployment exposes and enables them. Use them to present the supported user experience for the intended audience, then verify the result with that audience’s language and access context.

Do not treat a documented appearance or localization option as a guarantee that it is enabled in every deployment.

Deployment conditions

Capability availability is determined by deployment mode, server configuration, enabled services, identity setup, and administrator settings. Confirm these conditions in the current deployment before assigning a governance workflow to a team.

Users, Groups & Roles explains role and resource-sharing boundaries.
Deployment Modes explains why controls can differ by deployment.
Enterprise Integrations explains the conditional integration controls.