English | Español | Français | Deutsch
AI agents are a new kind of online shopper. With Trusteed, the network that connects businesses and agents, they can buy from your store on your terms.
- Set your business rules: who can buy, up to what amount, which categories you don't offer to agents, price limits, stock levels that protect you from fraudulent agents, and more.
- Get signed receipts. Every transaction produces a cryptographically signed, tamper-evident receipt you can use as evidence of the purchase if there's a dispute. Aligned with eIDAS (EU) and eSIGN (USA).
- See what agents do: how much they spend, what they buy and how often.
- Block agents that look dangerous or cause problems.
- Accept agent payments in digital currencies. The Trusteed network settles them over the x402 protocol. This module doesn't process those payments itself, so your Magento checkout stays as it is today. The payment rails are configured on the Trusteed side and reported back to the admin panel.
- Let agents buy from your store through the Trusteed network, which carries the identity, the rules and the receipt for each order. Payment still goes through your existing Magento payment methods.
| Dashboard | Agent Sales | Business Rules |
|---|---|---|
![]() |
![]() |
![]() |
| Agents | Rules & Toggles | Trust Receipts |
|---|---|---|
![]() |
![]() |
![]() |
| Setup Wizard | Setup Config |
|---|---|
![]() |
![]() |
| AI Sales: Automated receipts list |
|---|
![]() |
Every agent-originated order gets a signed trust receipt, listed under Trusteed → My sales → Recibos de venta with its verification status and receipt URI. From the list you can open a receipt's detail to read its fields and copy the raw JWS. Standalone public verification of an arbitrary JWS does not have a dedicated endpoint yet.
- MCP endpoint at
/.well-known/mcp.json, discovered automatically by AI agent platforms. - Webhook outbox: order, shipment and refund delivery to the Trusteed backend, with automatic retry and backoff.
- Agent token verification: the agent's identity is checked on every checkout request.
- Enforcement gate (HITL): when the backend's R043 rule fires, the order is held for human approval instead of being submitted.
- Trust receipts: every agent transaction produces a receipt signed with Ed25519.
- Admin dashboard: a single-page app showing agent sessions, sales, rules and health status.
- Audit log: every agent interaction is recorded with its identity and verdict.
- Installation Guide (ES): requirements, install, connect, verify, troubleshoot.
- User Guide (ES): day-to-day use of the admin panel and business rules.
- Reference Manual (ES): endpoints, config paths, CLI commands, data model.
| Magento version | PHP | Status |
|---|---|---|
| Open Source 2.4.7 | 8.2, 8.3 | ✅ Supported |
| Open Source 2.4.8 | 8.2, 8.3 | ✅ Supported |
| Adobe Commerce 2.4.7 | 8.2, 8.3 | ✅ Supported |
| Adobe Commerce 2.4.8 | 8.2, 8.3 | ✅ Supported |
- Magento Open Source or Adobe Commerce 2.4.7+
- PHP 8.2 or 8.3
- A Trusteed account (sign up free at trusteed.xyz)
This package is not published on Packagist yet, so Composer cannot resolve it by
name alone. First add the repository to the composer.json of your Magento project:
{
"repositories": [
{ "type": "vcs", "url": "https://github.com/Trusteedxyz/agentic-commerce-magento" }
]
}Then install it:
composer require trusteed/agentic-commerce-magento:^1.2
bin/magento module:enable Trusteed_AgenticCommerce
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush- Download the installable
.zipfrom the ⬇ latest GitHub Release The attached asset is namedtrusteed-agentic-commerce-magento-<version>.zip. All published versions are listed on the Releases page. - Extract to
app/code/Trusteed/AgenticCommerce/ - Run the
bin/magentocommands above from your Magento root
- Log in to your Magento Admin Panel
- Go to Trusteed → Configuración (the setup wizard)
- Click Conectar con Trusteed → and authorize your store in the popup that opens
- Select the store views you want to expose to AI agents
- Click Guardar
Navigate to Stores → Configuration → Trusteed → Agentic Commerce:
API Connection (trusteed_general/general):
| Setting | Description |
|---|---|
| API Base URL | Trusteed backend endpoint, e.g. https://api.trusteed.xyz |
| Merchant ID | Your merchant identifier |
| Integration Token | Encrypted. Authenticates this store against the Trusteed API |
| Webhook Secret | Encrypted. Verifies inbound webhook signatures |
| Internal HMAC Secret | Encrypted. Signs internal heartbeat/admin calls (X-Trusteed-Connection-Id, X-Trusteed-Timestamp and X-Trusteed-Signature headers, HMAC-SHA256); provisioned by Trusteed ops |
| Webhook Secret Version | Increment when rotating the webhook secret |
| Connection ID | Issued by Trusteed after the store is connected; identifies this store in webhook delivery |
Features (trusteed_general/features):
| Setting | Description |
|---|---|
| Enable WebMCP Bridge | Injects the storefront JavaScript bridge. Auto-disabled on Hyvä / PWA Studio themes |
| Enable Phase B (Embedded SPA) | Reserved for a future release. Leave off unless Trusteed support tells you otherwise |
Enforcement behaviour (including the R043 human-in-the-loop gate) is not configured here: it is
driven by the rules you set in Trusteed → Mis Reglas and by the signed rule snapshot the backend
serves. Agent tokens are accepted for a maximum age of 330 seconds (plus a 30-second tolerance on
exp); this window is fixed in the connector, not a setting.
After installation a Trusteed menu appears in the Magento admin sidebar:
| Page | Route | Description |
|---|---|---|
| Home | trusteed/dashboard |
Agent session and activity overview |
| How is my store doing? | trusteed/health |
Connection health and trust score |
| My sales | trusteed/ventas |
Agent-originated orders and their trust receipts |
| Who I'm selling to | trusteed/agentes |
Agent identities seen by your store |
| My Rules | trusteed/reglas |
Business rules applied at checkout |
| Payment Methods | trusteed/pagos |
Payment rails reported by Trusteed |
| Security | trusteed/seguridad |
Audit log and anomaly alerts |
| Settings | trusteed/ajustes |
Module configuration |
| Setup Wizard | trusteed/setup/wizard |
Setup wizard (connect / reconnect the store) |
Menu labels are sourced in English (etc/adminhtml/menu.xml) and translated per-locale via
i18n/{en_US,es_ES}.csv, so an English-locale admin now sees this table verbatim and a
Spanish-locale admin sees the Spanish column of that CSV. This was fixed on 2026-08-18: the
XML source strings used to be in Spanish, which broke translation for every locale
(Magento's CSV lookup is an exact match on the source string).
bin/magento module:disable Trusteed_AgenticCommerce
bin/magento setup:upgrade
composer remove trusteed/agentic-commerce-magentoTo remove database tables:
bin/magento setup:db-declaration:generate-whitelist --module-name=Trusteed_AgenticCommerce
# Then manually drop: trusteed_webhook_outbox
# And columns on sales_order: trusteed_receipt_uri, trusteed_receipt_statusCan agents find me? is a page inside your admin panel that answers one question: when an AI shopping agent visits your store, does it get what you think it gets?
It never shows a single score. Three columns, never averaged, because they answer different questions and can legitimately disagree:
| Column | What it is |
|---|---|
| What a third party says | The verdict of an external scanner, quoted verbatim and never converted to a scale of ours |
| Does what you say match what you do? | 16 checks that contrast what your store advertises against what it actually answers. This is the part no external scanner can do: it needs your credentials |
| What we have seen | Real agent traffic in the selected window: which agents arrived, which tools they used, how far they got, and where they failed |
A check that could not run is reported as not checked, with the reason. It is never silently dropped and never counted as a pass.
| Check | What it detects |
|---|---|
| C1 | You advertise tools your store does not serve |
| C2 | You advertise a checkout protocol whose endpoint does not answer |
| C3 | The catalogue price is not the price charged |
| C4 | Things are advertised as available when they are not |
| C5 | Your return policy says different things depending on where you look |
| C6 | You advertise as available something that is switched off |
| C7 | Rules switched on that cannot act for lack of data |
| C8 | Your rules observe but do not block |
| C9 | The identification method you advertise does not work |
| C10 | An agent can buy any amount without your confirmation |
| C11 | The point of sale is using expired rules |
| C12 | Operations with no signed receipt |
| C13 | Advertised addresses that do not work |
| C14 | Agents are seeing stale data from your store |
| C15 | Identity credentials about to expire |
| C16 | The delivery time you promise is not the one you meet |
Some checks need more than your settings to run, and the page says so instead of leaving a gap:
- C3, C4, C5 and C14 need your store connected. They compare against your real catalogue, and without credentials there is nothing to compare with.
- C16 needs delivered orders. It compares what you promise against what you actually met, and that cannot be done without history.
- Nothing to compare this time: for example, C12 has nothing to check until an agent has actually completed a purchase, and that is not a failure.
The checks run once a day and the page shows the result with its date, so nobody mistakes yesterday's verdict for today's.
We thank MD Rabbi Hossain (LinkedIn · X) for a responsible disclosure report against our identity provider, auth.trusteed.xyz.
The report's central claim is accurate: our OAuth dynamic client registration endpoint (/oidc/register, RFC 7591) accepts requests without a credential. That is deliberate — our MCP connectors, including Claude's, self-register through this endpoint before they can authorize at all, and requiring a credential there would break them. The access it enables is consent phishing, a property of any open dynamic-registration flow rather than unauthenticated access, and it does not reach checkout: our payment path requires a verified agent-identity claim that a token obtained this way does not carry.
Investigating the report surfaced something it did not flag: an OAuth scope (mcp:admin) was published across our discovery documents and offered on the consent screen, but no code enforced it — a token holding it carried the exact same privileges as mcp:read. That scope has been retired platform-wide. The fix lives in our private API and dashboard, not in this module, but we record the credit here as agreed with the reporter.
- Fixed: the connection guide sent merchants to a settings screen that doesn't exist (Dashboard → Settings → Integrations → Magento) to copy the Merchant ID, Integration Token, and Webhook Secret by hand. The real flow is a one-time popup token exchanged for the final credentials automatically; the guide now describes it, with a note not to hand-edit the webhook secret afterward, since that breaks the signature without saying so.
- New: an admin notice now appears when checkout enforcement is silently off because the store hasn't finished connecting yet (no installation ID). Previously the assistant answered "configuration saved successfully" while no rule was actually being evaluated on any checkout.
- New: a check that could not run now says why in one of four groups (nothing to do, needs configuration, waiting for data, or one of our own checks failed) instead of one flat list of unexplained grays.
- New: the panel now shows which of our servers answered your request, a short opaque label. Useful when comparing what you see here with what support sees; it never reveals a hostname or service name.
- New: Settings now lets you choose which tools your store serves to agents. If you never saved a list, the panel tells you that what you serve is the basic set the platform ships with, not a choice of yours.
- New: a button to re-run the readiness check without waiting for the daily sweep, and the panel remembers what changed since the previous run.
- Changed: our own outages no longer count as your store's mismatches. The panel keeps them separate, because there is nothing you can do about them.
- Fixed: the agent readiness page shipped without its stylesheet, so the panel rendered unstyled.
- Fixed: the panel could show its shell in one language and the diagnosis in another. The resolved language now travels with the texts instead of being detected twice.
- New: every finding carries a link to where it is fixed, and the merchant's own claims (the delivery promise and the rest) appear with the backing each one has.
- Changed: a store with no run yet reads as "checking" instead of "checked once a day": opening the panel already triggers the first run in the background.
- New: agent readiness dashboard. Can agents find me? now ships in the admin panel. It contrasts what your store advertises against what it actually answers, in 16 checks, and shows all sixteen, not only the ones that fail. A check that could not run says why (store not connected, no delivered orders yet, nothing to compare this time) instead of leaving a gap that reads like a fault. See "The agent readiness dashboard" above.
- Fixed: the diagnosis was written in Spanish inside the API and shown verbatim, so a merchant with the panel in English read English headings above Spanish findings. The checks now emit language-neutral codes and the text is composed when served, in the language you are using.
- Fixed: check C1 ("you advertise tools your store does not serve") counted the full public catalogue as served when no tool list was configured, reporting 46 of 48 answering when the server actually serves 12. The error favoured the store.
- Fixed: check C6 ("you advertise as available something that is switched off") reported a capability as off whenever its flag was unset, even for flags that are on by default. It was a false alarm on every store.
-
Fixed:
bin/magento trusteed:check-webserveralways reportedFAIL, even against a perfectly served manifest. It accepted the response only if it carried a top-levelmcpVersionkey; the manifest this module emits has never had one (the version key isschema_version), so the check could not pass. Merchants following the installation guide were told their webserver was misconfigured when it was not. -
Fixed (documentation): the README advertised two configuration fields that do not exist ("HITL enforcement mode" and "HITL amount threshold", although R043 has no configurable amount threshold), omitted seven that do, and gave the agent-token window as 300 seconds instead of 330. The admin page table listed six pages under invented English names; there are nine, and the menu is in Spanish. The trust-receipt paragraph pointed at
receipts.trusteed.xyz, a host that does not resolve, and described pasting a JWS into a verifier tool that does not exist. The x402 and peer-to-peer bullets promised capabilities this module does not implement. The manuals underdocs/were not linked from anywhere, and their reference sections described a manifest shape, webhook routes, retry policy, CLI command and frontend route that did not match the code. -
Fixed: the admin panel bundle (
view/adminhtml/web/js/admin-spa.js) shipped unminified: 869 KB / 25,064 lines instead of the 490 KB / 41 lines the documented build command actually produces. Provenance could not be verified. Rebuilt from source. -
Fixed: the R047 (minimum contribution amount) rule had no form field in the admin panel; its parameters existed in the schema but could only be set via the API. Also: displaying a merchant category name printed the anti-injection delimiters (
<<<MERCHANT_CONTENT_START>>> … <<<MERCHANT_CONTENT_END>>>) around it instead of stripping them for display. -
Fixed (documentation):
USER_GUIDE.md/USER_GUIDE_ES.mddescribed five of the six rows in the merchant rule-configuration table with the wrong rule: told the merchant to configureR007to restrict categories (R007 actually blocks cross-merchant abuse signals) andR005as an amount cap (R005 actually blocks revoked agents). Corrected against the real rule definitions;R030/R032/R035/R042added so the guide answers what merchants actually ask. Also removed the false claim that R001/R007 are "always evaluated locally" (the offline evaluator resolves nine different rules, none of them R001 or R007) and the false claim that R007 controls catalog visibility via atrusteed_agentic_visibleattribute (the real attribute isis_agentic_visible, unrelated to any CEL rule).
- Security fix: the agent token verifier treated
exp,iatandnonceas optional. Both time checks hung off> 0, so a token that simply omitted the claim skipped expiry and max-age entirely: it was valid forever. All three claims are now mandatory (nonce16–64 chars), matching the canonical token schema and the other platform connectors. - Security fix: the enforcement snapshot's signed freshness window (
validUntil) was ignored. A snapshot past its window, whether served by the API or by any intermediary that cached it, was applied as if current. Magento was the only connector that did not check this. An expired snapshot is now treated as absent, so the merchant's fallback policy applies.validUntiltravels inside the signed payload, so it cannot be stretched by an attacker; a missing or unparseable value is not treated as expired, since degrading on an unexpected format would block legitimate checkouts. - Fix: trust scores with a decimal were displayed as "no score". The Health tab parsed the score with
is_int(), and the scoring engine rounds to one decimal, whichjson_decodemaps to a PHP float, sois_int(81.4)wasfalseand the score silently becamenull. Only whole numbers survived. Measured across production stores on 2026-07-27: scores of 44.7, 52.7, 55.7, 61.5 and 81.4 all rendered as "no score". Now normalised through a singleScoreNodeNormalizer, and rendered with the decimal intact (81.4, not81) so it matches every other admin surface. - Fix: rule R036 (max line-item value) read its cap from a parameter named
maxCents; the canonical name ismaxCentsPerLine, and it is the only one the merchant panel's strict schema accepts. With the wrong key the rule could never fire. - Added: the connector now reports which cart signals this installation can project (
POST /api/v1/enforcement/capabilities, HMAC-signed, sent once per capability-set version). Without it, a rule whose signal never arrives returnsNO_SIGNALon every checkout: it passes silently, and the merchant sees a rule in ENFORCE that blocks nothing. With the report, the panel can warn at the moment the rule is switched on. Magento projects 31 signals, more than double any other platform, because it also projects agent history, which elsewhere the server resolves.
- Fix: the "My Sales → Ventas" page mounted a static placeholder (Dashboard block +
ventas.phtml) that never reached the actual TrustReceipt list. It now mounts the real admin SPA in the "Mis Ventas" section, same as Rules and Agents. - Admin SPA bundle rebuilt.
- Fix: checkout enforcement was skipped entirely for organic (non-agent) checkouts. Merchant rules such as maximum order amount, blocked countries, and business-hours restrictions never ran unless an agent DID was present. These rules now apply to every checkout regardless of agent presence.
- Added: an offline safety-valve evaluator that enforces the same universal merchant rules locally when the remote rules-evaluation API is unreachable, instead of only falling back to a blanket allow/block policy.
- Security fix: the enforcement snapshot fetched from the Trusteed backend is now cryptographically verified (Ed25519 signature check against the published JWKS) before it is trusted, instead of being decoded without verification.
- Security fix:
EnforcementClientno longer fabricates a placeholderdev-bypasssignature when the HMAC secret is not yet configured. Requests now fail safely open (ALLOW, matching the existing "unconfigured connector never blocks" posture), with a distinct log line so ops can tell an installation mid-setup apart from a fully unconfigured one. - Fixed the support "Send diagnostics" endpoint calling the wrong backend path (
/api/v1/embed/support/report→/v1/embed/support/report).
- Initial release
- MCP manifest endpoint
- Webhook outbox with retry/backoff
- Agent token verification (Ed25519)
- HITL enforcement gate
- Admin SPA dashboard
- Support email: support@trusteed.xyz
- GitHub issues: github.com/Trusteedxyz/agentic-commerce-magento/issues
Open Software License 3.0 (OSL-3.0). See LICENSE for full text.








