Personal vs shared credentials

Every credential AiHummer holds — an API key, a token, a webhook secret — has a scope that decides whose secret a tool call runs with. There are two scopes: shared and personal. Understanding the difference, and the resolution order between them, is the key to giving each agent and each user exactly the access they should have and no more.

The two scopes

Scope	Belongs to	Used when
Shared	The workspace	An action should run under one common account regardless of who triggered it
Personal	An individual user	An action must be attributed to, and limited by, a specific person’s own authorization

Both kinds live in the same encrypted vault (envelope encryption, AES-256-GCM, per-tenant key under a master key); the difference is purely who a secret resolves to, not how it is stored or protected.

Resolution by the acting user, with a workspace fallback

At turn time, when a tool needs a credential, AiHummer resolves it by the acting user — the person on whose behalf the turn is running — and falls back to the workspace (shared) credential when the user has no personal one:

need credential ─▶ personal credential for the acting user?
                     ├─ yes ─▶ use the personal credential
                     └─ no  ─▶ fall back to the shared (workspace) credential

This single rule gives you flexible behaviour: provide only a shared credential and everyone uses it; let individuals add their own and they automatically take precedence for that person, while everyone else keeps using the shared one.

[!NOTE] Personal always wins over shared for the same user. The workspace credential is a fallback, not an override — a user who has connected their own account acts with their own authorization.

When to use shared

Choose a shared credential when:

The action represents the organisation, not an individual (a company mailbox, a single CRM service account, a billing key).
You want consistent behaviour no matter who triggered the agent.
Issuing and rotating one secret centrally is simpler than per-user setup.

When to use personal

Choose a personal credential when:

The action must be attributed to a specific human and constrained by what that human is allowed to do.
Different users should see different data through the same agent and tool.
You need per-user revocation and audit, independent of everyone else.

Personal credentials are typically the individual accounts an employee connects themselves through Connections. Out of the box these include, for example, Gmail, Google Calendar, Google Drive, Google Tasks, YouTube, Outlook Mail, Outlook Calendar, OneDrive, Microsoft To Do, Todoist, Asana, Jira Cloud, ClickUp, GitLab, Fitbit, Oura Ring, Spotify and Samsung SmartThings — each user acts under their own authorization. A shared credential, by contrast, is one workspace-wide account (for example a company mailbox or a CRM service account) that everyone uses.

How it interacts with Connections and the vault

Connections are the most common way a personal credential comes into being: the user completes an OAuth2 authorization-code flow, the issued token is sealed in the vault, and from then on it is exactly the personal credential the resolver picks for that user. A shared credential, by contrast, is typically a secret an operator stores once at the workspace level.

In all cases the secret stays in the encrypted vault and never enters the model context, the prompt or the logs — the scope only controls which vault entry the acting user resolves to.

Where to next

Connections (per-user OAuth2) — how personal credentials are authorized.
BYOK & LLM providers — per-tenant model keys.
Marketplace overview & tiers — Tier-2 skills can use personal credentials.