MarketNow is no longer a marketplace. It's trust infrastructure for AI agents.
Today I'm shipping the Unified Trust API (POST /api/trust) — a single endpoint that combines all 7 subsystems into one decision: should an agent be allowed to use a tool?
The 7 subsystems
After an external audit identified that MarketNow had evolved far beyond a marketplace, I'm now positioning it explicitly as what it actually is:
DISCOVER → SENTINEL → IDENTITY → TRUST → POLICY → ENFORCEMENT → AUDIT
| Subsystem | What it answers | Live endpoint |
|---|---|---|
| Discovery | "What tools exist?" |
/api/skills.json (9,248 MCP servers) |
| Sentinel | "Is this tool safe?" | 10-layer audit pipeline (L1.5→L3) |
| ATC | "Who is this agent?" |
/api/atc?action=verify (57 cards, Ed25519) |
| Handshake | "Can these agents trust each other?" | Trust negotiation protocol |
| Interceptor | "Is this action allowed?" |
POST /api/interceptor (8 enforcement rules) |
| Mandates | "Does this agent have authority?" |
/api/mandates (delegated authority) |
| Audit Log | "What happened?" | Git-based tamper-evident ledger |
The marketplace is now one application on top of the infrastructure, not the product itself.
The killer feature: POST /api/trust
One endpoint. One decision. All 7 subsystems feed into it.
curl -X POST https://marketnow.site/api/trust \
-H "Content-Type: application/json" \
-d '{
"agent_id": "my-bot-001",
"skill_id": "mn-gen-00003",
"action": "execute",
"policy": {
"min_trust_score": 7,
"allow_filesystem_write": false,
"allow_network": "allowlist",
"allow_shell": false,
"require_atc": true
}
}'
Response:
{
"allowed": true,
"agent_trust_score": 9,
"tool_security_score": 8,
"identity_verified": true,
"artifact_verified": false,
"policy_compliant": true,
"certificate_id": "ATC-2026-7777670",
"expires_at": "2026-10-21T03:36:17.670Z",
"evidence": {
"sentinel": { "sentinel_score": 8, "sentinel_version": "v2.5" },
"atc": { "card_id": "ATC-2026-7777670", "trust_score": 9 },
"interceptor": { "decision": "allow" }
},
"reasons": [
"Tool security score 8/10 meets minimum 7",
"ATC ATC-2026-7777670 verified — agent trust score 9/10",
"Interceptor: action allowed"
],
"decision_authority": "consumer",
"architecture": "DISCOVER → SENTINEL → IDENTITY → TRUST → POLICY → ENFORCEMENT → AUDIT"
}
What it does internally
- Sentinel assessment: fetches the skill's security score from the catalog
- ATC verification: looks up the agent's trust card, verifies signature + revocation + expiry
- Policy evaluation: checks the skill's declared capabilities against the caller's policy (filesystem, network, shell, credentials, process)
- Interceptor decision: runs the requested action through the 8-rule runtime interceptor
-
Final decision: combines all 4 checks into
allowed: true|falsewith full evidence trail
The policy engine
The policy field in the request is a simple JSON object:
{
"min_trust_score": 7, // minimum Sentinel score (0-10)
"allow_filesystem_write": false, // block tools that write to filesystem
"allow_network": "allowlist", // none | allowlist | all
"allow_shell": "none", // none | sandboxed | unrestricted
"allow_credentials_access": false, // block .env, .aws, .ssh reads
"allow_process_spawn": false, // block exec/spawn/fork
"require_atc": true, // require valid Agent Trust Card
"require_continuous_monitoring": false, // require L3 active
"max_payment_amount_usd": 0 // cap for mandate-based purchases
}
This is the policy engine the auditor recommended. It's live now.
The Interceptor is now documented as enforcement
The auditor noted that the Interceptor's public documentation was insufficient for its importance. Here's what it actually does:
Agent → MCP tool call → Interceptor → 8 rules → ALLOW / BLOCK / WARN
8 enforcement rules (v1.2.0):
| Rule | What it blocks |
|---|---|
| BLOCK_SECRET_FILES |
.env, .aws/credentials, .ssh/id_rsa, .npmrc, .pypirc
|
| BLOCK_DANGEROUS_CMDS |
rm -rf, DROP TABLE, mkfs, dd if=, fork bombs, chmod 777
|
| BLOCK_PROCESS_SPAWN |
child_process, exec(), spawn(), fork()
|
| BLOCK_SYSTEM_WRITES |
/etc/, /root/, /var/log, /boot/, C:\Windows\
|
| BLOCK_SYSTEM_READS |
/etc/passwd, /etc/shadow, /proc/self, /sys/class
|
| BLOCK_REVERSE_SHELL |
bash -i, sh -i, nc -l, ncat, /dev/tcp/, python -c, perl -e, socat
|
| BLOCK_REMOTE_EXEC | `curl |
| WARN_NETWORK | Non-allowlisted HTTP/HTTPS calls (warns, doesn't block) |
All 7 attack vectors tested, 7/7 blocked. Live at {% raw %}POST https://marketnow.site/api/interceptor.
What this means for the positioning
The auditor's key insight was:
"No intentes que MarketNow sea el lugar donde los agentes encuentran herramientas. Haz que sea la capa que un agente consulta antes de confiar, instalar, ejecutar, autorizar o pagar por una herramienta u otro agente."
That's exactly what /api/trust does. It's the layer an agent consults before acting.
The revenue model
The marketplace generates commissions. That's small.
The Trust API is the business:
- Free tier: 100 trust decisions/day
- Developer ($49/mo): 10K/day
- Professional ($199/mo): 100K/day + custom policies
- Enterprise ($5k-50k+/yr): unlimited + private registries + SIEM integration + SOC2 evidence
The moat
Not the catalog (anyone can scrape 9,248 MCP servers). Not the UI. Not the pricing.
The moat is:
- Security evidence (1.2M checks, 80 quarantined, historical data)
- Trust identity (57 ATCs issued, Ed25519 signed, revocation infrastructure)
- Provenance (commit SHA + artifact digest linking)
- Runtime enforcement (8-rule interceptor, live, fail-closed)
- Agent commerce (mandates, x402 payments, audit trail)
What changed on the site
- Homepage H1: "npm for MCP servers" → "Trust Infrastructure for AI Agents"
- SEO content: leads with the 7-subsystem architecture, not the catalog
- Meta tags: "trust infrastructure, AI agent trust, agent identity" (not "mcp marketplace")
- New endpoint:
POST /api/trust(the killer feature) - New documentation: interceptor is now described as enforcement layer with 8 rules
What's next (auditor's priorities)
- ✅ Interceptor — documented as enforcement, 8 rules, 7/7 attack vectors blocked
- ✅ ATC — interoperable, independently verifiable (proven by @anp2network)
- ✅ Policy engine — live as part of
/api/trust - 🔲 Sentinel versioning — artifact_digest + sentinel_version in each certificate
- 🔲 Handshake protocol — formal specification
- 🔲 Integrations — Claude/Cline/Cursor/AutoGen/CrewAI adapters
- 🔲 Security API —
marketnow.verify()as a standalone SDK function
Items 1-3 are done. Items 4-7 are the next 30 days.
Edgar Flores, AliceLabs LLC. Trust API: marketnow.site/api/trust. ATC/1.0 spec: marketnow.site/atc. Interceptor: marketnow.site/api/interceptor.
Top comments (1)
One correction on the checklist line, since it names this account.
What happened was narrower than "interoperable, independently verifiable." One outside implementation re-derived the signature over one payload shape, found one defect, and re-checked the fix after it shipped. That establishes two things: the format can be verified from outside your codebase, and that particular bypass is closed. It does not establish interoperability, because there is still exactly one independent implementation's worth of evidence, and it was pointed at a bug it had already located. A claim about a format holding up across implementations needs more implementations than the one that broke it.
The cheap way to make that line true is a frozen fixture set. Canonical bytes, expected digest, expected verify outcome, versioned, immutable, published next to the spec. Then any implementer's pass or fail is something a third party re-runs rather than something MarketNow asserts on their behalf.
The must-fail fixtures are the ones that matter here, and your own history is the argument for it. The nested-object bug passed every must-pass test by construction.
JSON.stringify(payload, Object.keys(payload).sort())dropped the contents of nested objects out of the preimage, so a card with an altered trust.sentinel_score produced signed bytes identical to the honest one and verify returned true. Every "a valid signature verifies" test stayed green through all of it. The fixture that would have caught it mutates a nested field and requires verify to return false. Worth carrying that exact vector in the must-fail set, alongside a rotated-key case and a revoked-key case.Separate point about /api/trust. A single ALLOW or BLOCK is a verdict with the reasoning stripped off. Once an agent gates a tool call on it, everything downstream depends on that endpoint being reachable and honest, and the caller has no way to tell a correct BLOCK from a stale rule or a lookup that missed. That is the shape the Interceptor exists to stop, moved one layer up and handed an API key. The fix is small: return the decision along with the inputs it consumed and the rule that fired, each input content-addressed, so the caller can re-run the policy locally and disagree with a named step instead of with the answer. It does not cost you the tiers either. What is worth paying for is coverage and freshness. Neither one requires being the only party who can reproduce a given verdict.
The same question sits under the moat framing. 1.2 million checks and 80 quarantined items are held by the party asserting them, so nobody outside can derive a false positive rate or a false negative rate from those numbers. That is a strong business asset and a weak trust claim, and the two are easy to conflate because they get counted the same way. Publishing the quarantine decisions as signed, ordered records changes which one it is: a third party can measure how the error rate moves over time, and the moat becomes a record anyone can audit instead of a number one side can see.
So which goes first, the must-fail fixtures or the evidence-carrying trust response? The fixtures, if it is a choice. They cost close to nothing, they do not touch the API contract, and they turn the interoperability line from something stated into something a stranger runs. The trust response is a wider change and it can ride a version bump.