Authentication versus authorization
Authentication establishes the identity of a person, workload, or service. Authorization determines which tenant, data, tools, workflows, agents, and actions that identity may access.
A valid access token does not authorize every resource or operation. Tenant, role, scope, policy, data domain, purpose, and requested action may all participate in authorization.
Enterprise identity patterns
OAuth 2.x, OpenID Connect, Microsoft Entra ID, service accounts, and API credentials are tenant-specific enterprise patterns. Exact production availability, endpoints, claims, scopes, and token lifetimes are confirmed during onboarding.
- Use short-lived, least-privilege credentials where possible.
- Keep credentials out of source code, logs, URLs, and public issue trackers.
- Use workload identities or tenant-approved service accounts for unattended processes.
- Do not reuse interactive user tokens for services.
Access tokens and tenant isolation
Send tokens only to the tenant hostname supplied by Aevah. Token issuer, audience, signing keys, refresh behavior, and expiration are customer-specific.
Every request is evaluated in tenant context. Aevah may return not found rather than reveal a resource that the caller is not authorized to see.
Agent identity and MCP authorization
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. Every change creates a governed version rather than silently overwriting prior state.
Authentication errors
- 401: obtain a valid token; do not repeatedly retry an expired or invalid credential.
- 403: request the required role or scope through the tenant administrator.
- 429: honor Retry-After and use exponential backoff with jitter.