# Aevah Authentication and Authorization

Status: Tenant-specific. This public document describes the enterprise authentication model without publishing tenant identifiers, credentials, private endpoints, or security-sensitive configuration.

Canonical documentation: https://www.aevah.com/developers/authentication

## Authentication versus authorization

Authentication establishes the identity of a person, workload, or service. Authorization determines which tenant, entities, definitions, workflows, agents, decisions, evidence, and actions that identity may access. A valid token does not by itself authorize every resource or action.

## Enterprise identity

Aevah supports enterprise identity patterns configured for each customer environment. OAuth 2.x, OpenID Connect, Microsoft Entra ID, service accounts, and API credentials are documented as tenant-specific patterns; exact availability and configuration must be confirmed during onboarding.

## Access tokens

- Send tenant-issued bearer tokens only to the Aevah hostname assigned to the tenant.
- Token issuer, audience, claims, lifetime, refresh behavior, and signing keys are tenant-specific.
- Clients should renew tokens before expiry and must not log or persist tokens in source code.
- Never send credentials to the example .invalid hostnames used by the preview OpenAPI document.

## Scopes and authorization

The preview contract uses the aevah.read scope for authorized reads and aevah.execute for authorized workflow or agent execution. Production scopes may be more granular. Authorization can also depend on tenant, role, data domain, resource, policy, purpose, and requested action.

## Service-to-service access

Machine identities should use a tenant-approved service account or workload identity, least-privilege scopes, short-lived credentials where possible, rotation, and an accountable owner. Interactive user tokens must not be reused as unattended service credentials.

## Enterprise SSO

Enterprise SSO is configured per customer identity environment. Microsoft Entra ID, OAuth 2.x, and OIDC settings—including redirect URIs, claims, groups, and conditional-access requirements—are exchanged through a controlled onboarding process rather than this public site.

## Tenant isolation

Every request is evaluated in tenant context. Identities must not infer access across tenants. A not-found response may be used instead of revealing that an unauthorized resource exists.

## Errors

- 401: authentication is missing, invalid, or expired. Obtain a valid token; do not retry the same token repeatedly.
- 403: the identity is authenticated but lacks permission. Request the correct role or scope through the tenant administrator.
- 429: a rate limit applies. Honor Retry-After and use exponential backoff with jitter.

## Security contact

For current production mechanisms and a tenant-specific security review, contact mailto:security@aevah.com.

## Agent identity and MCP authorization

Aevah remote MCP connections use Streamable HTTP with OAuth 2.1 bearer authorization. Aevah agents act with the identity of the person who triggered them, never beyond that person's permissions. Each MCP tool call is evaluated against the triggering identity, tenant, permission scope, resource policy, and requested action. Every call is classified and audited. A change creates a governed version rather than silently overwriting prior state.