Tutorial 17

Manage your Credentials

Why this matters

Your agents and integrations need to talk to other systems — GitHub, Stripe, your CRM, Slack, Notion, your internal API. Every one of those systems requires a secret to authenticate: an API key, a token, an OAuth grant. Those secrets need a home that’s not “in a Slack DM I sent myself,” not “hardcoded in the script,” and not “in three different places nobody can find later.”

That home is Settings → Credentials.

A credential in Auxot is one stored secret with a name (the env-var name your agents will reference), a value (the actual secret — encrypted at rest, never shown again after creation), and a scope. The page’s helper text frames it well: “This is where you keep API keys and similar secrets that your agents use while they work.”

Credentials are not the same as API Keys (Tutorials 02 and 11 — those are for outside services calling INTO Auxot) and not the same as Tool Connector Keys (Tutorial 08 — those authenticate tool workers). Credentials are for Auxot calling OUT — the secrets agents and MCP servers use when they need to act on your behalf in someone else’s system.

Today, store one credential at the right scope, encrypted and ready to use. Tomorrow, the agents and integrations that need it pick it up automatically — no copy-pasting, no leaks, no surprises when someone leaves.

A credential is a stored secret your agents and integrations use to authenticate to external systems. It has a name (an env-var-style name like GITHUB_TOKEN), a value (encrypted, never shown again), and a scope (org-wide, team-wide, or just yours). Auxot injects the value at runtime; the agent calling the external service never sees the raw secret.

Quick start

1. Sign in — open Auxot in your browser and log in.
2. Open Credentials — click Settings in the left menu, then Credentials.
3. Click Add Credential — pick a scope (org / team / personal), give the credential a name (something like “GITHUB_TOKEN”), pick a source (manual paste or OAuth), enter the value or pick the OAuth provider, save.
4. Use it — when an agent or MCP server is configured to read an env var with that name, Auxot injects the encrypted value at runtime. The agent never sees the raw secret.
5. Rotate when needed — when a secret needs to change (someone left, the key was leaked, you’re on a quarterly rotation), click Edit on the credential, paste the new value, save. The new value takes effect immediately for everything that uses the credential.

Done? That secret now lives in one place — and changes there are reflected everywhere it’s used.

The agent can do that?

The Admin Agent has the tools to list credentials and OAuth providers (list_credentials, delete_credential, list_oauth_providers) — meaning he can audit what you’ve stored, recommend changes, and walk you through cleanups. Three prompts.

1. Audit which credentials you have stored

Open chat with the Admin Agent and ask:

List every credential currently stored in my account — name, scope (org / team / user), source (manual or OAuth), and last-used date. Flag anything with a vague name, anything that hasn't been used in a long time, anything that looks duplicated, and anything where the scope seems wrong for the agents using it.

Why it’s non-obvious: Credentials accumulate quietly. Someone needs a one-off token, adds it as org-scope, forgets about it. Six months later you have fifteen org-scope credentials nobody can identify. The Admin Agent reads the same data the page shows but can call out the patterns — vague names, unused entries, scope mismatches — that a human eye glazes past. Quarterly cleanup that takes two minutes instead of two hours.

2. Recommend the right scope for a credential you’re about to add

Before adding a new credential, ask:

I'm about to add a credential called "[name]" for [describe what it's for — e.g., "the OpenAI API key our research agent uses to run summaries"]. Which scope should it be — org, team, or personal? Walk me through the trade-offs based on what this credential does and which agents will use it.

Why it’s non-obvious: The “which scope?” question seems simple but trips most people up. Default-to-org is convenient but leaks access too widely. Default-to-personal forces every user to set their own token. The Admin Agent reads which agents would use the credential, what the agents do, who uses each agent — and recommends the right scope with reasoning. Less faceplant on the security review later.

3. Walk through a clean credential rotation

When a credential needs to be rotated (someone left, the key leaked, quarterly policy):

I need to rotate the credential called "[name]." Walk me through the safe sequence: who's using it currently, what services depend on it externally (so I know where to generate the new key), how to swap it without breaking running work, and how to confirm everything's working on the new value before I trust it.

Why it’s non-obvious: Rotation is one of those tasks that’s technically simple but routinely breaks production because someone forgets a step. The Admin Agent reads which agents reference the credential, which integrations rely on it, what would break if the rotation went wrong — and gives you a walk-through specific to your account. The CLI version of “how do I rotate this without an outage.”

Go deeper

Walkthrough

Step 1: Sign in

Open Auxot in your browser and sign in.

Step 2: Open Credentials

Click Settings in the left menu, then Credentials. The page has up to three sections, depending on your role and tier:

• My Credentials — everyone sees this. Personal secrets and personal overrides.
• Team Credentials — visible if you’re a Team Owner or Admin on a Business/Enterprise account. Secrets shared across one team’s agents.
• Organization Credentials — visible to org admins. Secrets shared across the whole organization.

The scope guidance line near the top tells you what your tier supports:

• Free plan: credentials run in one shared workspace, and you can set your personal value.
• Team plan: share credentials in one default team, and let each person set a personal value.
• Business / Enterprise: share credentials organization-wide or by team, and let each person set a personal value.

Step 3: Decide which scope your credential needs

The single most important choice. Three options:

a. Organization (Org) scope

Use for secrets the whole organization uses. Examples:

• “Our company GitHub token used by the GitHub MCP server” — every agent that uses the GitHub server pulls from this one secret.
• “Our company Stripe API key used by the billing dashboard agent” — same idea.
• “Our SaaS provider’s webhook secret” — used by an integration that’s wired account-wide.

Org admins create these. They apply to all agents in the org by default.

b. Team scope (Business and Enterprise only)

Use for secrets that should only be available to one team’s agents. Examples:

• “The Sales team’s Salesforce token” — Engineering team agents shouldn’t have access to it.
• “The Engineering team’s GitHub deploy key” — only their agents should hold it.
• “The Customer Support team’s Zendesk credential” — scoped to support agents.

Team Owners and Admins create these. They’re invisible to agents outside the team.

c. Personal (My) scope

Use when you want to use a secret that’s just yours, separate from any org or team secret. Two main cases:

• An agent is set to use a credential called GITHUB_TOKEN, but you want your sessions with that agent to use your GitHub token (so the agent operates with your access, not the company default). Setting a personal value for GITHUB_TOKEN overrides the org/team value just for your sessions.
• The agent doesn’t have an org or team value set, but you want one for yourself. You set a personal value and the agent uses yours when you’re the one running it.

Anyone can create personal credentials. They’re invisible to other users.

Tip: Default to the broadest scope that’s still safe. Org-wide if everyone should use the same key; team if only one team should; personal if only you should. Going too narrow (“everyone needs to set their own personal token”) creates onboarding friction. Going too broad (“everyone uses the same key”) creates security risk. Pick the level where the trust boundary actually lives.

Step 4: Click Add Credential

In whichever scope section you picked, click Add Credential. A modal opens with the title “Add Credential” and a context line: “Add a [scope] credential. The name is the env var agents receive (e.g. GITHUB_TOKEN).”

a. Name

The name is the env-var name your agents will reference. Examples:

• GITHUB_TOKEN
• STRIPE_API_KEY
• SLACK_WEBHOOK_URL
• OPENAI_API_KEY (if you want a credential to use within an MCP server, separate from your provider connection in Tutorial 09)

Use the convention your other systems already use — uppercase, underscores between words. The name shown in the credentials list is exactly the env var your agents will see.

b. Description (optional)

A short note about what this credential is for. “GitHub personal access token for repo access,” “Stripe live key — production only,” etc. Helps you (and other admins) remember what each credential is doing.

c. Source — Manual or OAuth

Two ways to provide the secret:

• Manual — paste a fixed string (an API key, a token, a webhook secret). Auxot encrypts it and never shows the raw value again. Best when the external service gives you a pre-generated token you’ll keep using.
• OAuth — link to an OAuth Provider (configured separately in Settings → OAuth Providers). When the agent needs the credential, Auxot uses the OAuth provider to fetch a fresh token. Best when the external service uses OAuth and you want per-user delegation.

If you pick Manual, paste the secret value into the Secret field.

If you pick OAuth, pick a configured OAuth Provider from the dropdown. (If the dropdown is empty, an org admin needs to add an OAuth Provider first — see Go deeper → OAuth Providers below.)

d. Save

Click Add Credential. The credential appears in the list. The raw value is gone forever — you can update it, but you can’t view it again. (That’s what “Secret values are encrypted at rest and never shown again after creation” in the modal helper means.)

Step 5: How agents and MCP servers actually use the credential

You don’t directly hand a credential to an agent. Instead:

• An MCP server configuration (Tutorial 18, when it’s drafted) references credentials by env-var name. “This MCP server needs GITHUB_TOKEN to authenticate.“
• An integration (like the Slack bot from Tutorial 16) stores its bot token as a credential under the hood.
• Your agent’s tool config can reference credentials similarly.

This is what “credential injection” means in practice. You store once; the system injects when needed; the secret stays out of every place it shouldn’t be.

Tip: When something says “Set my value” in the My Credentials list, it means there’s an org or team credential with that name, but you can override it for your own sessions. Click Set my value if you want your sessions to use a personal token instead. This is how an agent runs as you (with your access) rather than as a generic org account.

Step 6: Rotating, editing, and deleting

Click any credential row to Edit (update the description and the secret value) or Delete (remove the credential entirely).

• Editing the secret value is how you rotate. New value takes effect immediately for every agent and integration that uses the credential.
• Deleting a credential removes it for everyone. Any agent or integration referencing the credential by name will fail to authenticate until you re-create it (with the same name) or update the agent to use a different credential. The page warns: “Any agents referencing this credential will lose access to it.”

For OAuth-sourced credentials, the credential itself is just a binding to the OAuth provider. The actual live token is managed by the OAuth flow — you connect once via the Connect button on the personal credential row, and Auxot handles refreshes from there.

What’s next

• → Tutorial 18: Add an MCP server — credentials are most useful when MCP servers reference them. Tutorial 18 covers wiring an MCP server to use your stored credentials.
• → Tutorial 16: Connect Slack to your agents — the Slack bot token you set up there is one example of a credential; the same management story applies.
• → Tutorial 11: Create a shared Team API Key — that tutorial is for things calling into Auxot; this one is for Auxot calling out.

Reference

• Pages in Auxot: Settings → Credentials, Settings → OAuth Providers
• Three scopes: organization (org admins create, applies org-wide) | team (Business/Enterprise, team Owners/Admins create) | personal (any user)
• Two sources: manual (paste a secret) | OAuth (link an OAuth Provider)
• Resolution order: personal value (if set) → team value (if set, on B/E) → org value
• Encryption: values encrypted at rest, never shown after creation, never seen by agents directly
• Permissions: org admins / Team Owners + Admins / any user (depending on scope)
• Tier: all tiers (Free has no team scope, Team has one default team, Business/Enterprise have full multi-team)
• Distinct from API Keys (Tutorials 02, 11) and Tool Connector Keys (Tutorial 08)
• See also: Tutorial 18: Add an MCP server, Tutorial 11: Create a shared Team API Key, Tutorial 16: Connect Slack to your agents