Skip to main content
When an AI assistant has bearer-token access to your Hoard account, the question isn’t “is the assistant authenticated” — it’s “what’s this specific call about to do, and is that worth a human glance?” Asking Claude to “increase my sales” is fine; Claude responding by setting every multiplier to 0.001x is not. Hoard’s job is to make sure the second one can never happen, no matter how the conversation is framed. We do that with three layers, applied to every write action.

​
Layer 1: Permission grants

Permission grants are the policy for the assistant. Each kind of action has a mode: Defaults err on the side of asking. Edit a pricing rule? Default is ask_for_mutations. Run a sale? Default is always_ask. Change account settings? Default is always_ask. These modes are seeded for you when you first enable agent permissions, and for most sellers they’re the right call — let the assistant read freely, ask before changes. Editing individual modes per action from the UI isn’t available yet (it’s on the roadmap). For now, Settings → Assistants is a single Enable/Disable toggle plus a read-only view of the current grants. New Hoard accounts start with permission gating on. Connected assistants get read access first, and mutations go through the seeded permission modes. Existing accounts keep their prior setting until you change it.

​
Layer 2: Risk scoring (per call)

Even with a permission grant, every write call runs through a server-side risk scorer that classifies it as low, medium, high, or critical based on the actual parameters of the call. The scorer is user-relative: a 25% multiplier change is “high risk” for a Stay Competitive seller (whose pricing wizard set the per-card change cap at 20%) but “medium risk” for a Win the Buy Box seller (cap 30%). The system uses what you told the pricing wizard you were comfortable with as the calibration point. What pushes risk up:
  • Larger multiplier changes
  • Turning off “never go down” on rules that cover many cards
  • Changing the price source
  • Repricing across more cards
  • Aggregate projected drop in your listed inventory value
  • Lots of recent activity in the same session (cumulative escalation)
Even a proposed new rule can score medium for a broad sweep — 1000+ matched inventory cards with a multiplier more than 20% away from 1.0x. The older single-rule suggestion path lands as a disabled draft. A reviewed change set can explicitly create and enable the new rule in one approval, so its risk and projected impact are calculated as an active rule. When a pricing change needs your approval, the assistant returns a Hoard review link instead of committing. You click through while signed in, inspect the complete proposal, and choose Approve and apply or Reject. Approval applies the exact proposal on Hoard’s servers; no browser secret is passed back to the assistant.

​
Layer 3: Hard floors (unconditional)

These are server-side invariants every write must clear, no matter who’s calling — assistant, dashboard, API key, OAuth, anything. The assistant literally cannot construct a request that violates them. If it tries, the server returns a floor_violation error explaining which floor tripped and what to do about it. Active hard floors today: Absolute minimum: $0.01. No listed price can ever go below one cent. Server-side invariant, not user-tunable. Your per-card price floor. Defaults to $1.00 but customizable in your pricing preferences. No card lists below this regardless of what the rule says. Per-rule aggregate drop cap. Default 30%. A single rule application cannot drop your total listed inventory value by more than this percentage. Tunable per-user. The point: if you accidentally tell the assistant “discount everything by 40%,” the server stops it. Per-session aggregate drop cap. Default 20%, rolling 1-hour window. Cumulative across multiple calls in the same session — a series of “small” edits that together drop the store significantly will trip this even if no single edit was big enough on its own. Tunable per-user. Per-card clamps (inherited from your pricing rules). Your never_go_down setting, your change_cap_pct (max % move per sync), your hard_floor — these already gate every reprice your dashboard runs, and they continue to gate everything an assistant initiates. The agent doesn’t get to bypass anything you’ve configured for yourself.

​
The flow in practice

What it looks like end-to-end when you ask Claude to “raise my Rare/Mythic rule to 1.15x and add a 1.10x foil rule”:
  1. Claude sends both related actions as one pricing change set.
  2. The server checks the grant for every action in the set. A denied action blocks the proposal.
  3. The risk scorer derives the risk of each rule from current store data and uses the highest item risk for the proposal.
  4. Hard floors evaluate the combined projected effect. The assistant cannot lower the reported impact or supply its own safety evidence.
  5. Hoard stores an immutable, one-hour proposal and returns one review link.
  6. Claude summarizes the matrix and gives you the link.
  7. The page shows each recognizable rule, exact before/after settings, matched-card count, aggregate impact, and protected-card warnings.
  8. You click Approve and apply. Hoard re-checks current rule state and every floor, then applies the entire matrix in one database transaction.
  9. The proposal receives one shared checkpoint and audit entries for the overall change set and each rule. Claude can read the durable applied, rejected, stale, failed, or expired status afterward.
If one targeted rule changed while you were reviewing, the proposal becomes stale and nothing applies. If you reject it, optional feedback is saved and nothing applies. In either case, Claude can prepare a revised proposal without guessing what happened. The single-rule compatibility path can still auto-commit when you deliberately opt out of dry-run and your grant plus risk allow it. Assistant-authored matrices default to review so one approval is the clear sign-off boundary.

​
Recovering pending and recent proposals

If a chat disconnects after Hoard stores a proposal, your assistant can recover it without creating another one. Ask it to list pending pricing proposals; it can return the original review link plus a compact summary of each rule, intended setting changes, impact counts, and warning codes. Recent history can also be filtered by status or by the proposal’s parameter fingerprint. Proposal creation supports a caller-generated idempotency key. Repeating the same matrix with the same key returns the original proposal and its current proposed, applied, rejected, stale, failed, or expired state. Reusing that key for different settings is rejected. Hoard retains proposal records—and therefore their key reservations—until the cleanup window, currently seven days after expiry. A genuinely new proposal should use a new key. Unknown or old proposal IDs return recovery guidance rather than an empty error. The assistant should list recent proposals first; it should only prepare a replacement when the original is expired, stale, or failed and current rule state has been refreshed.

​
Audit log

Every committed change, every rejected-by-floor attempt, every expired plan that timed out without confirmation — they all go in your audit log. There’s no dashboard page for it yet; the log is available through the activity API, and the easiest way to read it is to just ask a connected assistant (“show me everything you changed in the last week”). The audit row includes: what action, what risk score, who committed it, what the before/after state was, and which floor tripped if any. Rejections at commit time — wrong confirmation token, the plan’s params changed between preview and commit, a floor that tightened mid-flight — are logged with their reason too, so a probing pattern shows up instead of vanishing silently.

​
Best practices

  • Get comfortable with the seeded defaults. Watch what gets asked. The defaults err toward asking before changes, which is the right starting point for most sellers. Per-action tuning (loosening one namespace to auto_low_risk, say) isn’t in the UI yet — it’s on the roadmap.
  • Set a per-card floor that reflects your actual minimum. The default is 1.00.Ifyou′dneverlistacardbelow1.00. If you'd never list a card below 0.25, leave it at 1.00—thecushionisyoursafetynet.Ifyougenuinelysellbulkcommonsat1.00 — the cushion is your safety net. If you genuinely sell bulk commons at 0.10, lower it.
  • If you run flash sales, expect more confirmations. Sales by their nature push risk up. The system will ask. That’s working as intended; click through.
  • Check the audit log when something feels off. It captures exactly what happened. If the assistant says it edited a rule and you can’t see the change, ask a connected assistant to read the log back — it’s the source of truth.

​
What’s NOT controlled by this

These are all outside the agent permissions system and have their own (older, stricter) controls:
  • Sync mode (autonomous vs confirm) — set via the pricing wizard or Settings
  • Pricing engine clamps (change_cap_pct, change_cap_mode) — set via the pricing wizard
  • Revoking a connected assistant — done from Settings → Assistants
These controls remain dashboard-only. An assistant cannot loosen them on its own.

​
Tutorials

Walk-throughs for the flows sellers actually run into: