Skip to content

About

Enable AI agents to make purchases in your Magento store securely. Set rules, block bad agents, get tamper-proof receipts (in the line of eIDAS/eSIGN). X402 digital currencies & agent-to-agent supported. Agentic readiness panel which monitors in real time the beahavior of the agents and the problems they report to shop in the store.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Repository files navigation

English | Español | Français | Deutsch

Trusteed Agentic Commerce for Magento 2

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.

Screenshots

Dashboard Agent Sales Business Rules
Dashboard Sales Rules
Agents Rules & Toggles Trust Receipts
Agents Rules Detail Trust Receipts
Setup Wizard Setup Config
Setup Config
AI Sales: Automated receipts list
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.

Features

  • 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.

Documentation

Compatibility

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

Requirements

Installation

Via Composer (from GitHub, no Packagist listing yet)

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

Manual upload

  1. Download the installable .zip from the ⬇ latest GitHub Release The attached asset is named trusteed-agentic-commerce-magento-<version>.zip. All published versions are listed on the Releases page.
  2. Extract to app/code/Trusteed/AgenticCommerce/
  3. Run the bin/magento commands above from your Magento root

Configuration

  1. Log in to your Magento Admin Panel
  2. Go to Trusteed → Configuración (the setup wizard)
  3. Click Conectar con Trusteed → and authorize your store in the popup that opens
  4. Select the store views you want to expose to AI agents
  5. Click Guardar

Advanced settings

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.

Admin pages

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).

Uninstallation

bin/magento module:disable Trusteed_AgenticCommerce
bin/magento setup:upgrade
composer remove trusteed/agentic-commerce-magento

To 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_status

The agent readiness dashboard

Can 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.

What each check looks at

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.

Security Acknowledgements

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.

Changelog

1.3.4

  • 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.

1.3.3

  • 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.

1.3.2

  • 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.

1.3.1

  • 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.

1.3.0

  • 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.

1.2.1

  • Fixed: bin/magento trusteed:check-webserver always reported FAIL, even against a perfectly served manifest. It accepted the response only if it carried a top-level mcpVersion key; the manifest this module emits has never had one (the version key is schema_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 under docs/ 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.md described five of the six rows in the merchant rule-configuration table with the wrong rule: told the merchant to configure R007 to restrict categories (R007 actually blocks cross-merchant abuse signals) and R005 as an amount cap (R005 actually blocks revoked agents). Corrected against the real rule definitions; R030/R032/R035/R042 added 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 a trusteed_agentic_visible attribute (the real attribute is is_agentic_visible, unrelated to any CEL rule).

1.2.0

  • Security fix: the agent token verifier treated exp, iat and nonce as 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 (nonce 16–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. validUntil travels 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, which json_decode maps to a PHP float, so is_int(81.4) was false and the score silently became null. 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 single ScoreNodeNormalizer, and rendered with the decimal intact (81.4, not 81) 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 is maxCentsPerLine, 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 returns NO_SIGNAL on 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.

1.1.1

  • 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.

1.1.0

  • 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: EnforcementClient no longer fabricates a placeholder dev-bypass signature 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).

1.0.0 (2026-06-18)

  • Initial release
  • MCP manifest endpoint
  • Webhook outbox with retry/backoff
  • Agent token verification (Ed25519)
  • HITL enforcement gate
  • Admin SPA dashboard

Support

License

Open Software License 3.0 (OSL-3.0). See LICENSE for full text.

About

Enable AI agents to make purchases in your Magento store securely. Set rules, block bad agents, get tamper-proof receipts (in the line of eIDAS/eSIGN). X402 digital currencies & agent-to-agent supported. Agentic readiness panel which monitors in real time the beahavior of the agents and the problems they report to shop in the store.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages