Skip to content

Authentication & authorization

Alquimia Platform supports multiple authentication mechanisms so you can match the control to the caller: service-to-service requests, end-user sessions, and workload identity for agents themselves.

MethodBest for
API tokenService accounts and internal clients
JWT / OIDCEnd users authenticated through Keycloak or another identity provider
SPIFFE/SPIREWorkload identity for agents and runtime pods in Kubernetes

API tokens are long-lived credentials issued to trusted services. They are validated by the runtime on protected endpoints. Tokens should be stored in Vault or a Kubernetes secret, not committed to source control.

Use API tokens for backend services that call Alquimia Platform without an interactive user context.

The runtime can validate JWTs from a Keycloak realm or any OIDC-compatible provider. Claims in the token are mapped to user identity and can be used for agentspace-level authorization.

Use JWT or OIDC when end users interact with agents directly through a web or mobile application.

In Kubernetes, runtime services and agents can authenticate using SPIFFE identities issued by SPIRE. This allows Vault to issue short-lived, identity-bound credentials instead of shared tokens.

Workload identity reduces the risk of credential theft and makes it easier to attribute every secret fetch to a specific workload.

Authorization is enforced at three levels:

  • Endpoint access — which callers can invoke inference, registry, or state endpoints.
  • Agent role tier — each agent is assigned a capability tier: reader, editor, or operator. The tier is an identity-plane ceiling, not a permission list.
  • Tool and knowledge policy — the ToolAuthzPolicy and KnowledgeAuthzPolicy decide, per operation and per topic, whether a tool runs, requires human approval, or is denied outright.

In production, set DefaultToolAuthzPolicy(default_deny=True) and DefaultKnowledgeAuthzPolicy(default_deny=True) so that unclassified tools and unregistered knowledge topics are denied by default. See Authorization policies for the full policy model, per-operation classification, and topic access control.

An agentspace is the primary authorization boundary. Users and services can be granted access to one or more agentspaces, and secrets are scoped within them. Design agentspaces to match your organizational or environmental boundaries.

DeploymentRecommended model
Local developmentAPI token or static credentials
Internal servicesAPI token with network controls
User-facing applicationsJWT/OIDC through your identity provider
Kubernetes productionSPIFFE workload identity + Vault dynamic credentials