Auxot
Tutorials Docs Pricing Login

Wire your first tool with least privilege

Walk one first-week path: store outbound secrets in **Settings → Credentials**, assemble the smallest **tool policy** (**Settings → Tool Connector Keys** / tool policies), and clip it to a single agent so optional tools stay optional.

Plus: three Admin Agent prompts: smallest belt for one job, credential scope decision before Save, and MCP OAuth versus stored credential for a named vendor.

Audience Admins · Developers
Time ~12 min
Prerequisites Org admin (tool policies and org-scope credentials require it). At least one custom agent ([Create an agent from scratch](/tutorials/create-an-agent-from-scratch)). You can find **Settings** ([Find the right screen for your next question](/tutorials/find-the-right-screen-for-your-next-question)). Helpful first pass on vocabulary: [Understand Credentials, OAuth, and API keys in Auxot](/tutorials/understand-credentials-oauth-and-api-keys-in-auxot).
You'll end up with One outbound secret saved at the narrow scope that fits the job, one tool policy with only the connectors that job needs, that policy attached to exactly one agent, and a Chat smoke test that proves the belt matches the work.

When a tutorial shows italic text in quotation marks, it usually mirrors a label or helper string inside Auxot. Product copy changes between releases — if something reads differently in your workspace, trust what you see on screen.

Callouts with a Worth knowing gold accent are meant as must-read context before you move on. Blockquotes that open with Tip are lighter, optional depth.

Why this matters

Agents look reckless when everything is toggled on and every secret is org-wide by default. Least privilege is boring on purpose: one external capability, one stored secret (or OAuth handshake) at the smallest scope that still works, one tool policy wired to one agent, then prove it in Chat with a prompt that needs that capability.

API keys let callers hit Auxot (Generate your first API key). Credentials hold secrets Auxot uses when agents call out (Manage your Credentials). Tool policies bundle which connectors an agent may invoke (Define a tool policy). Mixing those drawers is how GitHub tokens land in the wrong screen (Understand Credentials, OAuth, and API keys in Auxot).

This lesson is the sequenced path: decide the job, store the outbound secret intentionally, build the smallest belt, clip it, prompt once. Deep dives stay in the tutorials linked above.

The next time someone asks for just Slack, you are not handing them search, billing APIs, and three stale org credentials because “we might need them later.”

Least privilege here means smallest scope plus smallest tool surface that still completes one real prompt.

Quick start

  1. Pick one agent and one outcome: name the custom agent and the single external action it must perform (for example “post an update to our team Slack when asked”).
  2. Place the outbound secret: open Settings → Credentials and add only what that outcome requires at org, team, or personal scope (Manage your Credentials). Prefer narrow scope unless multiple teams truly share the same secret.
  3. Open Tool Policies: Settings → Tool Connector Keys (same concept as “tool policies” in docs). Create a new key, give it a job-specific name.
  4. Toggle the minimum: enable built-in tools or MCP entries that match the outcome; leave everything else off (Define a tool policy).
  5. Attach and smoke test: Settings → Agents → your agent → add this tool policy → Chat → send a prompt that requires the tool (not a generic hello).

Done? The agent completes the outcome using stored secrets you scoped on purpose, without extra connectors peeking out.

The agent can do that?

You are deciding trust boundaries before anyone clicks Save. Paste intent first; implement toggles yourself in Settings.

1. Smallest belt for one job

Agent "[name]" should only ever [one outcome. Example: read public GitHub issues for repo X]. List which built-in tools and MCP servers belong on its tool policy, which tools must stay off, and what to name the policy so nobody “just adds web_search later.” Cap at eight bullets.

Why it’s non-obvious: belt creep happens when policies stay unnamed or vague. Naming the outcome in what you paste keeps Admin Agent advice tied to your workload.

2. Credential scope before Add Credential

I'm storing [GITHUB_TOKEN / Stripe secret / internal API key] for [agent job]. Should this credential be org, team, or personal? Name blast radius if someone rotates it next quarter.

Why it’s non-obvious: org-wide feels convenient until half the company inherits access they never needed.

3. OAuth row versus credential row

Vendor: [GitHub / Google Workspace / Slack MCP]. Should this integration lean on **Settings → OAuth** ([Connect OAuth for MCP tools](/tutorials/connect-oauth-for-mcp-tools)), **Settings → Credentials**, or both? Name the first screen to open and whether humans must click *Allow* before agents can act.

Why it’s non-obvious: OAuth delegation and stored secrets solve different trust problems; picking the wrong one wastes an afternoon on why doesn’t MCP see my account.

Go deeper

Directions of trust

Tool policy attachment

Policies are reusable belts. Multiple agents may share one belt later; for this tutorial you clip one belt to one agent so mistakes stay contained.

MCP servers add another drawer

If your outcome needs a custom MCP server, configure it (Add an MCP server), reference credentials by env name in that config, then expose MCP through the tool policy toggles. Do not paste raw secrets into MCP JSON.

Walkthrough

Step 1: Write the outcome sentence

One sentence: what outside Auxot must happen when a human prompts this agent? If you cannot name it, stop and tighten the agent’s job description (Give your agent its job description).

Step 2: Store credentials before belts

Open Settings → Credentials. Create only the secrets the outbound call needs. Match env names to what MCP configs or built-in connectors expect (GITHUB_TOKEN, vendor docs, or your operator convention). Pick personal when only you should rotate it, team when a squad owns the workload on Business or Enterprise, org when every admin-approved agent may need it.

Step 3: Create the tool policy shell

Settings → Tool Connector Keys → + Add Key. Name it after the outcome (“Support Slack notifier”), not after your company slogan.

Step 4: Toggle least surface area

Open the key → enable connectors that map to the outcome. Leave experimental toggles off. If MCP appears, ensure OAuth or credential references line up with Step 2.

Step 5: Clip to the agent

Settings → Agents → pick your agent → Tool Policies → attach the key you just built. Remove broader belts if this agent inherited legacy policies you no longer want.

Step 6: Chat proof

Open Chat, select this agent, issue a prompt that cannot succeed without the external action (fetch a real issue, send a real dry-run message to a test channel). Confirm the tool calls succeed and that no other tools were touched.

What’s next

Reference

Browse all tutorials