# Latest features: the agentic storefront > Customers can now shop your store through their own AI assistant — headless, over MCP, with per-customer pricing, standards-based OAuth 2.1 consent, and a revoke button the customer controls. Source: CBX documentation, version 3.x (released). Canonical page: https://docs.configbox.at/docs/features/latest/agentic-storefront. Last updated 2026-08-26. --- **Your customers' AI assistants can now shop your store.** Not a chatbot bolted onto the page — a **headless** surface where the assistant a customer already uses browses your catalog, configures a product through its real rules, watches the price move, and fills their cart. Over the **Model Context Protocol**, with no browser and no rendered page anywhere in the loop. It is one endpoint. A customer points their assistant at `https://your-store/cbx-api/mcp`, signs in once in their own browser, approves what the assistant may do, and from then on they can say *"find me a linear luminaire for a 24-foot run, 4000K, and put it in my cart."* ← [Back to Latest features](https://docs.configbox.at/docs/features/latest/) --- ## Why this is different from a chatbot CBX already has an [AI advisor beside the configurator](https://docs.configbox.at/docs/features/latest/ai-assistant) — a panel on your storefront, your model, your prompt, your bill. That is a feature of *your* store. This is the other direction. The customer brings their own assistant, in whatever surface they already work in, and your store is one of the tools it can reach. You pay for no inference. You prompt no model. **Your store is the thing being used, not the thing doing the using** — which is exactly why the guarantees below sit in the data and the permission layer rather than in a prompt. | | The chat advisor | The agentic storefront | |---|---|---| | Where it runs | your storefront page | the customer's own assistant | | Who pays for the model | you | the customer | | Who controls the prompt | you | not you — so nothing may depend on it | | What it is | a feature of your store | your store as a **capability** of theirs | --- ## What an assistant can actually do Fifteen typed tools — not an API a model has to be *described* in prose, but real tools with real schemas it can call: - **Browse** the configurable catalog, with prices as *that customer's group* sees them. - **Configure** a product: start it, answer questions, get the running price, and ask *why* an option is unavailable — the rule taken apart into its conditions and what would satisfy them. - **Preview** a choice before committing: what the price would become and which questions would open or close, changing nothing. - **Work the cart**: add, change quantity, copy a line ("the same again but in blue"), reopen one for editing, remove, save the cart for later — and hand the customer a **URL** to open it in your shop. Checkout is deliberately not in this set. The assistant takes the customer to the point of paying and gives them the link; addresses, delivery and payment stay on your pages. - [The storefront MCP server, in full](https://docs.configbox.at/docs/technical/storefront_mcp) - [Admin Guide: let customers use their own AI assistant](https://docs.configbox.at/docs/admin-guide/ai-assistant/let-customers-use-their-own-assistant) --- ## The part that matters: it configures *correctly* A product configurator is not a catalog with a shopping cart. Answers interact — choosing a direct luminaire makes every indirect lumen output, colour temperature and lens impossible — and an assistant that does not keep up will confidently offer a customer something the rules already ruled out. CBX solves this in the surface itself, not in prompt advice: **The rules run for real.** Every selection goes through the same engine, the same validation and the same recalculation the browser storefront uses. There is no second implementation to drift. **Availability is re-readable cheaply.** After each selection an assistant can ask what is still selectable and get back just that — the answers that remain, and the ones that no longer do. On a real 21-question product that costs **9.5 kB** where re-reading the product structure costs **100.8 kB**. That ten-fold difference is the whole feature: a re-read that expensive is one an assistant will skip, and skipping it is precisely how it ends up offering the impossible. **When something is refused, the refusal explains itself.** Not "invalid selection" — the governing rule, which of its conditions currently fail, and the selections that would satisfy them. An assistant can course-correct without a human in the loop. --- ## Pricing stays yours Pricing in CBX is a **customer-group** property, and the agentic surface inherits it whole. Every tool call runs *as one specific customer*, so their group's pricing simply applies: - A customer whose group may not see prices gets the same tools with the **price keys absent** — not zeroed, absent. There is nothing to leak and nothing to argue a model out of. - Per-product price switches (show the total but not what each option adds) are honoured identically. - B2B net-price mode is honoured identically. This is a **data** guarantee, not a prompt guarantee. That distinction is the point: a rule in a prompt is a suggestion a determined visitor can talk a model out of. A figure that was never sent cannot be leaked, whatever anyone says to the model. - [Where prices come from](https://docs.configbox.at/docs/admin-guide/pricing/where-prices-come-from) --- ## Consent, and the customer's off switch Access is **OAuth 2.1** — the standard the MCP authorization spec names, implemented properly rather than approximated: - The store hosts its own **authorization server**, because CBX is platform-neutral and none of its hosts ships one to borrow. Clients discover it: the `401` names the metadata document, which names the server, which names the endpoints. - **PKCE is mandatory** (S256), redirect URIs are matched **exactly** (no open redirect), `state` is round-tripped, and a per-request nonce guards the consent step against CSRF. - Access tokens are short-lived; refresh tokens **rotate** on use. Both are opaque and stored server-side, so revocation is immediate rather than eventual. - Tokens are **audience-restricted** to your MCP endpoint and the server checks it — an agent cannot bring a token minted for somebody else's store. - Clients register themselves (RFC 7591). **The assistant never sees the customer's password**: they sign in and consent in their own browser. And then the half that customers actually feel — on their account page: - **Connected assistants**: which agents hold access, and since when. - **Recent activity**, in their words, not the tool's: *"Chose an option"*, *"Added a configuration to the cart"*. Reads are logged too — "it looked at my prices" is exactly the kind of thing a person may want to see. - **Turn off**, which bites on that assistant's very next call. --- ## Why you can trust it with a customer's account A standing credential that acts as one customer is a serious thing to hand out, and the design treats it that way. **Isolation is bidirectional and absolute.** A shopping token holds storefront scopes **or** back-office scopes — never both, enforced when the token is minted. A customer's assistant is never even *offered* the tools that read your catalog internals, your other customers, or your settings; and a back-office token never sees the shopping tools. Neither is a subset of the other. Without this rule a token acting as one customer could read every customer's data — the classic confused-deputy hole, foreclosed by construction rather than patched. **Ownership is re-checked on every single call.** A cart or configuration belonging to someone else is refused, not merely hidden. **And it has been driven hard, not just written.** The guarantees above are pinned by an automated suite, and several of them exist *because* driving the surface as a real client broke it first: - Nine different cross-customer attacks — reading, writing, saving, removing, copying, reopening and re-pricing another customer's things — all refused. - The price gate walked across **eleven** tools, reads and writes alike, and **mutation-verified**: deliberately breaking the gate makes the test fail. A leak test that has never failed proves nothing. - Two statefulness bugs found and fixed — both of which *reported success* while doing nothing, the worst shape a bug can take. Their tests now read back in a later request, because a spec that trusted the write's own response passed against the broken build. - A tool result that came back empty is now reported as an error rather than as a success, because an assistant reads "success with nothing" as "it worked" and builds on it. That record is offered deliberately. Anyone can list features; what should persuade you is that the surface was attacked, measured and corrected before it was documented. --- ## Getting started 1. **It is already there.** The endpoint ships with CBX; there is nothing to install. 2. **Give a customer the URL** — `https://your-store/cbx-api/mcp` — and their assistant does the rest. 3. **For your own integrations**, mint a token directly: `configbox:token:mint "Concierge bot" --scope=storefront:write --for-customer=1234`. - [Admin Guide: let customers use their own AI assistant](https://docs.configbox.at/docs/admin-guide/ai-assistant/let-customers-use-their-own-assistant) - [The full technical reference](https://docs.configbox.at/docs/technical/storefront_mcp) - [API tokens and scopes](https://docs.configbox.at/docs/technical/api_tokens_and_scopes)