Credentials

Three separate things, needed at different times.

Model keys — only for agents

Agents spend your model account, never the operator's. A tenant run resolves your tenant's model credential with no fallback, so with none configured an agent launch does not degrade — it fails, naming the variable it wanted.

Ordinary pipelines that build, test and lint need none of this. That is why the credentials step sits after your first green run rather than before it: nothing about CI is blocked on it.

Register a key per account rather than one key everywhere, so a single exhausted balance cannot stop every agent at once.

Two provider details that catch people:

• cursor wants a subscription session token, not a dashboard API key.
• kimi-coding and xai are OAuth-brokered, and the registry refuses an api_key for them — because the agent runtime prefers a key over OAuth when both exist, so accepting one would quietly disable the working path.

Pipeline secrets

Values your steps need as environment variables. Hive seals them at rest and never reads one back — the list shows a fingerprint, not the value. If you lose one, you replace it; you do not recover it.

1Password service accounts

If your instance has credential brokering enabled, you can store a 1Password service-account token and Hive will resolve op:// references on your behalf, server-side. An agent launched onto your machine then gets its credentials with no interactive prompt.

This is per user, not per tenant — it is your account doing the resolving, so a colleague's agent does not inherit it. Each person who wants the behaviour stores their own token.

What is available here

Not every instance configures all three. Check /api/v1/config:

• llm_credentials_enabled — model key registry
• stored_secrets_enabled — sealed pipeline secrets
• agent_credentials_enabled — per-user 1Password brokering

A false means the routes are not mounted, not that you did something wrong. Pipelines still run.