> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tryhoard.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Going from cautious to confident

> A 4-week walkthrough for loosening your agent permission grants as you build trust. What to flip each week, what to watch for, and when to roll back if something goes sideways.

You connected an AI assistant to Hoard. You're sitting on the defaults. Every change asks for confirmation, and so far you've clicked yes to every reasonable request. The confirmations are starting to feel like ceremony.

That's the right moment to start loosening. This page is a 4-week plan for moving from defaults to a power-user configuration, one dial at a time. Each step is one week. If anything looks off, hold the current setting for another week or drop back one step.

<Note>
  Self-serve editing of permission grants isn't in the UI yet — it's on the roadmap. Today the modes are seeded when you enable assistant access. This plan is the intended progression for once per-action editing ships; until then, email [support@tryhoard.com](mailto:support@tryhoard.com) to move a grant, and use the weekly cadence below to decide what to ask for.
</Note>

The assistant is not perfect. The goal is to find the level of trust that matches its actual behavior on your account, not too tight (every click is noise), not too loose (you stop reading what it's doing).

## Week 1: live with the defaults

Don't change a thing. Just use Claude or ChatGPT through a normal workweek of store work. Approve reasonable requests. Reject anything that looks off.

What you're collecting: data on what the assistant tends to suggest. Most sellers find that the first week feels chatty, every preview asks. By the end of the week you have a feel for the pattern.

What to note as you go:

* Were any of the suggested changes obvious mistakes? (Should be rare.)
* Did the assistant suggest the same kind of change repeatedly? (Pricing rule edits are common.)
* Did you reject anything? Why?

At the end of the week, glance at your [activity log](/tutorials/reading-the-audit-log). Filter for `rejected_by_user`. If that count is high (>20% of confirmations), the assistant is suggesting things you don't want, fix that first before loosening anything. Tell it the constraint in plain English: "I never want you to change my price source automatically." Most assistants will hold onto that for the rest of the conversation.

## Week 2: trust low-risk quantity edits

The first real loosening is small and safe: move `inventory.update_quantity` from `ask_for_mutations` to `auto_low_risk`. (Until self-serve editing ships, email support to make this change — see the note above.)

What this does: the assistant can now silently adjust quantities on individual cards when the change is classified as low risk by the server. Marking a single card as out of stock after you found it bent in the binder, bumping a quantity from 2 to 3 after a restock, that kind of thing. Anything that moves a meaningful chunk of inventory at once still escalates to confirmation.

Why this is the right first step: quantity edits don't change a single price. The worst case from a bad auto-commit is that one card's listed quantity is wrong for a few minutes until your next sync, easy to spot in your activity log and trivial to undo. Price edits, by contrast, can cascade through your aggregate listed value. Earn trust on the low-stakes namespace first.

What to do this week:

* Use the assistant for normal inventory adjustments as you would.
* At the end of each day, scan your activity log for `inventory.update_quantity` rows with `outcome: committed`. Eyeball that each adjustment matches something you remember asking about.
* If anything committed that you didn't ask for, drop the setting back to `ask_for_mutations` and email support before going further.

End of week: a clean activity log of auto-committed quantity edits, all of which look right, means the throughput benefit is real and the safety net held. Time to extend the same posture to pricing.

## Week 3: trust low-risk price edits

This is the meaningful one: set `pricing.edit_rule` to `auto_low_risk`. (Same as Week 2 — email support to make the change until self-serve editing ships.)

What this does: the assistant can now silently commit rule edits classified as low risk by the server. A 1.10 → 1.15 multiplier bump on a Mythic rule. A small tweak to a never-go-down setting on a rule that covers 50 cards. Anything bigger, over your `change_cap_pct`, flipping the price source, affecting hundreds of cards, still escalates to confirmation.

Floors still gate. Risk scoring still runs. The only thing that changes is the per-call confirmation prompt for the smallest edits.

What to do this week:

* Use the assistant for pricing edits as you normally would.
* At the end of each day, scan your activity log for `pricing.edit_rule` rows with `outcome: committed`. These are the edits that committed (some after a click-through, some silently under the loosened grant). Make sure each one looks right.
* If anything committed that shouldn't have, hold this setting and ask the assistant why it made that call before reviewing further.

End of week: a clean activity log of auto-committed low-risk edits, all of which look right, means you're ready to keep going. Any false positives, edits you wouldn't have approved if asked, mean stay at this setting for another week, or drop `pricing.edit_rule` back to `ask_for_mutations`.

## Week 4: full trust except critical

If week 3 was clean, push further. Set both `pricing.edit_rule` and `pricing.mass_reprice` to `auto_unless_critical`.

Now almost everything commits in one round trip. Only critical-risk calls escalate. Critical risk is the bar where the system thinks "this could meaningfully damage the store", a multi-point multiplier swing, a rule edit that would push hundreds of cards through their floor, a mass reprice on a rule that covers thousands of cards.

Floors still gate. Server invariants are unchanged. The assistant still cannot violate your per-card floor, your per-rule aggregate cap, your per-session cap, or the absolute \$0.01 minimum.

What to do this week:

* Use the assistant the way a power user would. Ask for sweeping changes, ask for end-of-day audits, batch your work into the conversation.
* Review your activity log at the end of the day, not in real time. The point of this mode is throughput; you've delegated the per-call check.
* Watch the `rejected_by_floor` count. It should be very low. A handful per week is fine, those are the safety net working. A flood means the assistant is groping at the limits of what's allowed, which usually means the conversation is set up wrong; restart with clearer constraints.

## Where most sellers settle

The honest distribution we see:

* **About 40% stay at week 3** (`auto_low_risk` for pricing, defaults everywhere else). The week-3 level is most of the throughput benefit with most of the confirmation safety net.
* **About 30% push to week 4** (`auto_unless_critical`). Comfortable with audit-log review, want minimum friction.
* **About 20% roll back to ask\_for\_mutations everywhere** after experimenting. They like the confirmations and don't mind the clicks.
* **About 10% lock down even further** with `account.settings: deny` and some pricing namespaces denied. Read-only-plus configurations.

None of these is wrong. Pick the level that matches how you actually want to work.

## When to roll back

The signal that you've loosened too far:

* **Two false-positive commits in a week.** A false positive is a committed change you would not have approved if asked. One is a fluke; two is a pattern. Drop one tier (week 4 → week 3, or week 3 → defaults).
* **A `rejected_by_floor` cluster in one session.** If the assistant is probing the limits 5+ times in one conversation, either the conversation is set up wrong (start fresh with clearer constraints) or the assistant has been talked into bad ideas by something in its context. Tighten temporarily.
* **You stop reading the activity log.** This is the quiet failure mode. Audit-log-as-safety-net only works if somebody is reviewing the log. If a week goes by and you haven't looked at it, retighten one notch, get the confirmation prompts back as a forcing function until the habit comes back.

Rolling back is the same UI as loosening, just pick a stricter mode. There's no penalty.

## The thing the assistant is not

The assistant is not a replacement for your judgment. The trust progression is about reducing the per-call friction for routine work, not about handing the store over.

Even at week 4, you should be in your activity log at the end of the week. Even at week 4, the assistant will sometimes make calls you'd not have approved. The floors will catch the dangerous ones. You'll catch the merely-wrong ones on review.

If at any point that arrangement stops feeling right, retighten. The defaults are always there.

## Related reading

* [Agent permissions and safety](/agent-permissions), what each layer is doing as you loosen
* [Picking the right permission mode](/tutorials/picking-a-permission-mode), the per-persona version of this guide
* [Reading your agent activity log](/tutorials/reading-the-audit-log), the tool you lean on more as you loosen
* [Your first agent-driven price change](/tutorials/first-agent-price-change), what the default flow looks like
* [When the agent says 'I can't do that'](/tutorials/when-the-agent-says-no), what to do when a loosening exposes a floor