DEV Community: Edison Flores

The MarketNow roadmap: building the SSL for AI agents (with zero budget)

Edison Flores — Wed, 22 Jul 2026 04:52:09 +0000

I'm building MarketNow — the trust layer for AI agent commerce. No funding, no ads, no paid tools. Just code, community, and a clear roadmap.

Here's where we are and where we're going.

What's done (July 2026)

9-layer security pipeline (all live, all free)

L1.5 through L3 — static analysis, malware detection, sandbox, continuous monitoring. Plus WAF, honeypot, threat intel, and auto-quarantine.

Every MCP skill in our catalog (8,845 real servers from GitHub) is audited. Each gets a signed Sentinel certificate (0-10 score) that anyone can verify.

Agent Trust Cards (ATC)

SSL certificates for AI agents. Ed25519 signed, GitHub-persisted ledger, working verify + revoke. Code examples in Python, JS, and Go.

Marketplace

8,845 skills (all free, all real)
5 languages
npm v1.5.0
MCP Registry published
14 API endpoints

Community

45 dev.to articles (677 views, 28 comments)
35+ GitHub issues across 10 repos
Active conversations on CrewAI (8 comments) and AutoGen (3 comments)
3 contributors
11 open issues (5 good first issues, 5 help wanted, 1 security review)

What's next (Q3 2026)

All volunteer, no budget:

Python marketnow-atc package (issue #11)
AutoGen integration (@Sravan1011 is on it)
Rust ATC verification crate (issue #10)
Japanese translation (issue #12)
More malware signatures (issue #13)
L4 design document — in-process monitoring
RFC 8785 canonical JSON
CA key rotation

The revenue model (when it comes)

Everything is free until revenue exists:

Skills: FREE (we don't sell skills)
Sentinel audit: FREE
ATC: FREE
Seller subscriptions: PRO .99/mo (when sellers exist)
Commission: 20% on seller sales (when sales happen)

No paywalls on security. No freemium on trust. The audit is free because the internet is safer when everyone can verify.

How you can help (costs /bin/bash)

30 seconds

Star the repo: https://github.com/edgarfloresguerra2011-a11y/marketnow
Share with one person who uses Claude Desktop, Cursor, or Cline

1-2 hours

Translate a page to Japanese (issue #12)
Write a tutorial (issue #14)
Test our honeypot — try to bypass it (issue #17)

2-8 hours

Write the Python package (issue #11)
Write the Rust verification example (issue #10)
Research new malware signatures (issue #13)

Ongoing

Review our code and report bugs
Write about us on your blog (issue #18)
Write a Twitter thread (issue #16)

Full roadmap: https://github.com/edgarfloresguerra2011-a11y/marketnow/blob/master/ROADMAP.md

What we will NOT do

Pay for ads
Pay for reviews
Pay for listings
Fake stars or downloads
Claim features we don't have
Hide incidents or bugs

The honest truth

I have no budget. I have a laptop, a GitHub account, and a Vercel free tier. What I do have:

A real product (9 security layers, ATC, 8,845 skills)
Real community engagement (28 comments, 3 contributors)
A real story (trojan incident -> 8 layers built in 2 weeks)
A clear vision (SSL for AI agents)
Honesty (everything public, including what's broken)

If that's enough for you to contribute, I'd love your help. If not, I understand — and I'll keep building anyway.

Repo: https://github.com/edgarfloresguerra2011-a11y/marketnow
Live: https://marketnow.site
Contributing: https://github.com/edgarfloresguerra2011-a11y/marketnow/blob/master/CONTRIBUTING.md

— Edison Flores, AliceLabs LLC

I need help: 5 open-source tasks for the MCP trust layer

Edison Flores — Wed, 22 Jul 2026 04:42:07 +0000

I am building MarketNow — a security-first MCP marketplace with a 9-layer audit pipeline and Agent Trust Cards. The project is open and I need contributors.

Here are 5 concrete tasks you can pick up right now. All are beginner-friendly.

1. Write a Rust ATC verification example

We have ATC verification examples in Python, JavaScript, and Go. We need Rust.

Skills: basic Rust, HTTP requests, crypto
Time: 2-4 hours
Issue: https://github.com/edgarfloresguerra2011-a11y/marketnow/issues/10

2. Create a Python marketnow-atc package

A simple pip package that wraps our ATC API:

from marketnow_atc import verify
trust = verify("ATC-2026-9880252")
print(trust.valid) # True
print(trust.sentinel_score) # 10

Skills: Python, requests, pip packaging
Time: 4-8 hours
Issue: https://github.com/edgarfloresguerra2011-a11y/marketnow/issues/11

3. Translate the /trust page to Japanese

Our trust page is in 5 languages. We need Japanese.

Skills: Native Japanese, basic React
Time: 1-2 hours
Issue: https://github.com/edgarfloresguerra2011-a11y/marketnow/issues/12

4. Research new malware family signatures

Our L1.8 layer detects 17 malware families. We need more (Atomic Stealer, DarkGate, IcedID, BumbleBee, etc.).

Skills: Security research, basic regex
Time: 2-3 hours per signature
Issue: https://github.com/edgarfloresguerra2011-a11y/marketnow/issues/13

5. Write a tutorial: How to verify MCP server safety

A step-by-step guide for developers.

Skills: Writing, basic API usage
Time: 2-4 hours
Issue: https://github.com/edgarfloresguerra2011-a11y/marketnow/issues/14

What you get

Your name in the Contributors section of our README
Credit in the next GitHub release
A real open-source contribution to a security project
Mentorship — I review every PR and explain why changes are made

How to start

Pick a task from the list above
Comment on the issue saying I will work on this
Fork the repo
Make your changes
Open a PR

No interview, no application, no waiting period. Just code.

Repo: https://github.com/edgarfloresguerra2011-a11y/marketnow
Contributing guide: https://github.com/edgarfloresguerra2011-a11y/marketnow/blob/master/CONTRIBUTING.md
Live site: https://marketnow.site

— Edison Flores, AliceLabs LLC

Replying to everyone: 28 comments across 9 articles — here are my answers

Edison Flores — Wed, 22 Jul 2026 04:14:19 +0000

You commented. I listened. Here are responses to every unanswered comment across our articles. The dev.to API doesn't let me reply inline (it returns 404 on comment creation), so this is my workaround — one article that answers everyone.

To @mads_hansen (L3 article)

"I would distinguish periodic re-attestation from runtime monitoring. A weekly sandbox replay can detect drift; it cannot see an attack that runs between scans."

You're right — L3 is periodic re-attestation, not true runtime monitoring. The distinction matters. True runtime monitoring would require an in-process agent (like an eBPF probe or a syscall interceptor) that watches the MCP server's behavior in real-time. That's L4 on our roadmap — but it requires running inside the user's runtime, not in our sandbox.

What L3 does: catches drift that accumulates over time (config changes, supply chain updates, new tools). What it doesn't do: catch a skill that behaves normally during the weekly scan but maliciously between scans.

Honest answer: L3 is the best we can do without shipping an agent to the user's machine. L4 (in-process monitoring) is the real fix, but it's a heavier lift.

To @mayank609 (L3 article)

"Certification is necessary, but production systems keep changing—dependencies update, permissions drift."

Exactly the problem L3 solves. The weekly re-audit catches exactly these changes. If a dependency updates (npm version bump) or permissions drift (allowed_paths expand), L3 flags it before the user is affected.

Your feedback on CrewAI #6463 directly shaped this. Thank you.

To @anp2network (Responding to feedback article)

"The recursive sort closes the top-level-only gap, but there's a second-order issue: it lands on the exact property an attacker would target if they could influence key ordering."

You're describing a canonicalization attack — where an attacker manipulates JSON key order to produce a different canonical form that still validates. This is a real concern.

Our defense: We use JSON.stringify(sortedObj) which produces a single deterministic output for any given object structure. An attacker can't influence the key ordering because we sort them ourselves before serialization. The only way to produce a different signature is to change the payload content, not its serialization.

That said, you're right that canonicalization is a hard problem. The gold standard is something like RFC 8785 (JSON Canonicalization Scheme). We're not there yet, but it's on the roadmap.

To @mads_hansen (Responding to feedback article)

"Compromise recovery depends on revocation distribution. A verifier with a cached registry can keep accepting attacker-signed ATCs until it learns the old key is revoked."

This is the OCSP problem (Online Certificate Status Protocol) — same issue SSL has. Our current solution: verifiers call GET /api/atc?action=verify on every check (no caching). This is slow but correct.

Better solution (on roadmap): Signed revocation lists with short TTLs. The verifier caches the revocation list for 5 minutes. If a CA key is compromised, the new revocation list is published within 5 minutes, and all verifiers pick it up on their next check.

You also suggested signing the key registry itself — that's a great idea. The CA should sign its own key list, so a verifier can detect if the key list was tampered with.

To @neelagiri65 (Post-mortem article)

"The fix that actually holds is signed packages plus a runtime sandbox, not just more scanning layers."

Agreed. Signed packages (like npm's provenance) plus runtime sandboxing is the gold standard. We have:

Signed packages: every Sentinel certificate is SHA-256 signed
Runtime sandbox: L2 runs in gVisor with --network none, --read-only, --cap-drop ALL
Continuous monitoring: L3 re-runs weekly

What we don't have yet: package-level signing (signing the npm tarball itself, like Sigstore/cosign). That's on the roadmap — we're looking at integrating with npm's provenance feature.

To @neelagiri65 (8 layers article)

"Eight layers is a lot to maintain honestly. The useful bit is which ones actually caught something in practice."

Fair question. Here's what each layer has actually caught:

Layer	Caught something?	What
L1.5	Yes	536 skills flagged for "no auth required" or "no rate limiting"
L1.6	Yes	456 secrets found in skill descriptions (mostly example keys in READMEs)
L1.7	Yes — the trojan	Caught the `unit.exe` binary in the prospector-email-finder zip
L1.8	No	0 malware family matches (but the trojan was caught by L1.7 first)
L2	Yes	103 skills failed to start in sandbox (MODULE_NOT_FOUND, crash)
L3	No (just shipped)	Too early — first weekly run hasn't happened yet
WAF	Yes	Blocked SQLi, XSS, SSRF attempts on our API
Honeypot	Yes	4 scanners banned for hitting /.env, /admin
Threat Intel	No	0 skills with URLs in URLhaus (catalog is clean)

L1.7 is the MVP. It caught the only real attack we've seen. The other layers are defense-in-depth — they haven't caught anything yet, but they're cheap to run and would catch different attack classes.

To @kordless (ACP article)

"ACP is a spec for agent to agent comms: agentclientprotocol.com"

You're right — we were aware of the existing ACP spec and actually killed our ACP implementation because it competed in the wrong layer. We pivoted to ATC (Agent Trust Card) which is the trust layer, not the communication layer. ACP/A2A/MCP handle communication. ATC handles trust. Complementary, not competitive.

Full pivot writeup: https://dev.to/edison_flores_6d2cd381b13/ai-agents-need-their-own-ssl-heres-why-i-built-it-1njk

To @alexshev (MarketNow 2.0 article)

"The stronger metric is whether users can connect, run a first workflow, and know what failed."

100% agree. Downloads are vanity. The metric that matters is "did the agent successfully call a tool and get a useful response."

We're instrumenting this now:

/api/agent-purchase returns the full system_prompt + install command + capabilities — so the agent has everything it needs in one call
/api/audit-skill returns the Sentinel score — so the agent knows if the skill is safe before calling it
Coming: success tracking (did the install command work? did the first tool call succeed?)

To @pakvothe (5 idiomas article)

"Los objetos TRANSLATIONS a mano funcionan hasta que el producto crece. La solución escalable es extraer las traducciones a archivos JSON separados."

Tienes razón. Ahora mismo tenemos las traducciones inline en el código (un objeto por idioma). Funciona para 5 idiomas y ~30 rutas, pero no escalaría a 20 idiomas.

Plan: Migrar a archivos JSON separados (/locales/en.json, /locales/es.json, etc.) cargados dinámicamente. Esto permite:

Contribuciones de la comunidad (PR para añadir un idioma)
Lazy loading (solo cargar el idioma del usuario)
Mejor DX (editar un JSON es más fácil que navegar un objeto JS)

Gracias por el feedback — es el tipo de cosa que se ignora hasta que duele.

To @custralis (Sandbox article)

"--network none only closes egress — a tool that reads the filesystem or spawns processes is still dangerous."

Correct. --network none blocks network but doesn't restrict filesystem or process access. That's why we layer:

--network none → blocks exfiltration
--read-only → blocks writes to the root filesystem
--cap-drop ALL → drops all Linux capabilities (no root, no raw sockets, no ptrace)
--security-opt no-new-privileges → prevents privilege escalation
--memory 256m --cpus 0.5 → prevents resource exhaustion
gVisor → userspace kernel intercepts syscalls (stronger than seccomp)

The full Docker command:

docker run --rm \
  --network none \
  --read-only \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --memory 256m --cpus 0.5 \
  mcp-audit-target

We also add --tmpfs /tmp for skills that need write access, scoped to a small partition.

To @nazar-boyko (8 layers article)

"Layers 3 and 4 are pattern and family matching, which is exactly the technique malware authors optimize against."

True — regex-based pattern matching is evadable. A sophisticated attacker can obfuscate their code to avoid matching our patterns.

Our defense-in-depth: L1.7/L1.8 catch known patterns. L2 (sandbox) catches behavior, not patterns — even if the code doesn't match any regex, the sandbox sees what it actually does (network calls, file writes, process spawns). L3 catches drift over time.

No single layer is sufficient. That's why there are 9.

To @wrencalloway (8 layers article)

"The hard one is a skill that ships clean and then pulls its payload at runtime."

This was the #1 feedback across all articles. L3 is our answer — it re-runs the sandbox weekly and detects if the skill's behavior changed since certification. But as @mads_hansen pointed out, it's periodic, not real-time.

The real fix is L4 (in-process monitoring) — an agent that runs inside the user's runtime and watches the MCP server's syscalls in real-time. That's on the roadmap but requires shipping a native binary (eBPF on Linux, Endpoint Security framework on macOS).

Summary

28 comments across 9 articles. The community consistently identified 3 gaps:

Runtime trust (4 reviewers) → L3 is the first answer, L4 is the real fix
CA key management (3 reviewers) → Key rotation + signed revocation lists on roadmap
Canonicalization (2 reviewers) → Fixed (recursive sort), RFC 8785 on roadmap

Every comment made the system better. Keep them coming.

— Edison Flores, AliceLabs LLC — marketnow.site

The MCP security checklist: 9 things to check before installing any MCP server

Edison Flores — Wed, 22 Jul 2026 04:06:59 +0000

You wouldn't install a npm package without checking its dependencies. You shouldn't install an MCP server without checking its security. Here's the checklist we use at MarketNow — 9 layers, from basic to advanced.

1. Does it have a GitHub repo?

If the install command is npx -y some-package but there's no link to the source code, don't install it. You're running code on your machine — you should be able to read it first.

Check: npm view some-package repository.url

2. Does the repo have a README and LICENSE?

A repo without a README or LICENSE is a red flag. It means the author didn't bother with basic documentation or legal terms.

Check: Visit the GitHub repo. Is there a README.md? Is there a LICENSE file?

3. Are there hardcoded secrets?

Search the code for API keys, tokens, passwords. Even if they're example values, they indicate the author doesn't understand secret hygiene.

Check: grep -r "sk_live\|ghp_\|AKIA\|password.*=" .

4. Does it request dangerous permissions?

MCP servers can access your filesystem, network, and environment variables. Check what the server declares it needs.

Check: Read the server's manifest. Does it request:

Filesystem access? Which paths?
Network access? To which domains?
Environment variables? Which ones?
Subprocess execution?

5. Has it been audited?

Running a server in an isolated sandbox (Docker with --network none, --read-only) reveals its actual runtime behavior. Has anyone done this?

Check: Look for a security audit or certificate. At MarketNow, every skill has a Sentinel certificate showing its audit score (0-10).

6. Is it a typosquat?

Attackers create repos with names similar to popular packages. prospector-mcp-email-finder (legit) vs JuanquiForty/prospector-mcp-email-finder (typosquat with a trojan).

Check: Compare the repo URL against the official npm package. Are they the same owner?

7. Does the README promote external downloads?

If the README has a "Download Latest Release" badge that links to a zip on raw.githubusercontent.com or another external URL, don't click it. This is the exact vector that delivered a Windows trojan to our marketplace.

Check: Search the README for download links. Are they pointing to the repo's own releases page, or to an external URL?

8. Has the code changed recently?

A repo that was clean 3 months ago might have malware injected last week. Check the commit history.

Check: git log --oneline -20 — any suspicious commits? Any commits by unknown contributors?

9. Is there continuous monitoring?

Static audits catch problems at one point in time. But code changes. Does anyone re-audit the server after it's been certified?

Check: Look for evidence of continuous monitoring. At MarketNow, our L3 layer re-audits every skill weekly and detects:

Tool catalog changes (new tools appeared)
Supply chain drift (git commit changed)
Network behavior changes (new domains contacted)
Permission expansion (new paths accessed)

How MarketNow automates this checklist

We run all 9 checks automatically on every skill:

L1.5  → metadata checks (1-4 above)
L1.6  → semgrep + secrets + OSV (3, 5)
L1.7  → binary/malware detection (6, 7)
L1.8  → malware family signatures (5)
L2    → gVisor sandbox baseline (5)
L3    → continuous re-audit (8, 9)
WAF   → 40 attack signatures
Honeypot → 50+ fake paths
Threat Intel → abuse.ch feeds

Each skill gets a score (0-10) and a signed certificate. You can verify any certificate at marketnow.site/verify.

The takeaway

MCP servers are powerful — they can read your files, make network requests, and execute code. Treat them with the same caution you'd treat a npm package or a Docker container. Run the checklist before installing.

Or just use MarketNow — we run it for you.

Try it: https://marketnow.site
Install: npx -y marketnow-mcp
GitHub: https://github.com/edgarfloresguerra2011-a11y/marketnow

— Edison Flores, AliceLabs LLC

ATC vs SSL: a side-by-side comparison of web trust vs agent trust

Edison Flores — Wed, 22 Jul 2026 04:06:28 +0000

SSL certificates made the web trustworthy enough for commerce. ATC (Agent Trust Card) does the same for AI agents. Here's how they compare.

The comparison

Aspect	SSL (Web)	ATC (Agents)
What it proves	Website identity	Agent identity
Who issues	Certificate Authority (DigiCert, Let's Encrypt)	MarketNow Sentinel CA
Crypto	RSA 2048 or ECDSA P-256	Ed25519 (RFC 8032)
Signature	X.509 certificate	Detached Ed25519 signature over canonical JSON
Verification	Browser checks cert chain	Agent fetches CA public key + verifies signature
Revocation	CRL / OCSP	GitHub-persisted record (status: 'revoked')
Expiry	90 days (Let's Encrypt) / 1 year	90 days
Trust score	EV = green bar, DV = basic	Sentinel score 0-10
Public ledger	CT logs (Certificate Transparency)	GitHub repo (_data/atc/)
Cost	$0-$1000/year	Free

How SSL works (1995-present)

1. Website generates keypair
2. Website sends CSR to CA
3. CA verifies identity (domain control)
4. CA signs certificate with CA private key
5. Browser receives certificate
6. Browser verifies signature with CA public key (bundled in OS)
7. Browser checks: not expired, not revoked, domain matches
8. Green padlock → HTTPS connection established

How ATC works (2026)

1. Agent generates Ed25519 keypair
2. Agent sends public key + identity to MarketNow CA
3. CA fetches Sentinel score (8-layer security audit)
4. CA signs ATC payload with CA private key
5. CA persists ATC to GitHub (_data/atc/{card_id}.json)
6. Other agent fetches ATC: GET /api/atc?action=verify&card_id=X
7. Other agent verifies signature with CA public key (public on GitHub)
8. Other agent checks: not expired, not revoked, Sentinel score >= threshold
9. If valid → trust established → agent-to-agent interaction proceeds

Key differences

1. Transparency

SSL certificates are logged to Certificate Transparency logs, but these are hard to query. ATC records are stored as JSON files in a public GitHub repo — anyone can git clone and audit the entire ledger.

2. Trust scoring

SSL is binary: valid or invalid. ATC has a 0-10 Sentinel score. An enterprise can set a threshold: "only interact with agents scoring 8+." A hobbyist can accept 5+. This granularity doesn't exist in SSL.

3. Revocation speed

SSL revocation (CRL/OCSP) can take hours to propagate. ATC revocation is instant — the GitHub record is updated, and the next verify call (which reads fresh from the GitHub Contents API) returns valid: false immediately.

4. Runtime monitoring

SSL certificates don't monitor the website's behavior after issuance. ATC's L3 layer re-audits the agent weekly and detects behavioral drift (new tools, new network calls, changed permissions). If the agent changes after certification, L3 flags it.

5. Cost

SSL costs $0-$1000/year per domain. ATC is free — the CA, the signing, the verification, the ledger, the monitoring. All $0.

What ATC doesn't do (yet)

Chain of trust: SSL has root CAs → intermediate CAs → leaf certs. ATC has one CA. Multi-sig (2+ CAs required) is on the roadmap.
Domain verification: SSL proves you control example.com. ATC proves you control an Ed25519 keypair. Domain-bound ATCs are coming.
Automatic renewal: Let's Encrypt auto-renews via ACME. ATC renewal is manual (re-issue before expiry). Automation is on the roadmap.

Try it

# Get the CA public key (like a root CA cert)
curl https://marketnow.site/api/atc?action=ca-key

# Verify an agent's trust card
curl "https://marketnow.site/api/atc?action=verify&card_id=ATC-2026-9880252"

# List all trust cards (public ledger)
curl https://marketnow.site/api/atc

# Issue a trust card for your agent
curl -X POST https://marketnow.site/api/atc \
  -H "Content-Type: application/json" \
  -d '{"action":"issue","agent_id":"your.agent","public_key":"your-ed25519-pubkey"}'

Live: https://marketnow.site/atc
GitHub: https://github.com/edgarfloresguerra2011-a11y/marketnow

— Edison Flores, AliceLabs LLC

I scanned 8,845 MCP servers for malware. Here are the results.

Edison Flores — Wed, 22 Jul 2026 04:05:58 +0000

I ran our 9-layer Sentinel pipeline on every MCP server in our catalog. Here's what I found.

The scan

8,845 MCP servers from GitHub repos, each audited by:

L1.5: 6 metadata checks
L1.6: 18 Semgrep rules + 18 secret patterns + OSV dependency check
L1.7: Binary/launcher detection (opens the actual package zip)
L1.8: 17 malware family signatures (Emotet, Cobalt Strike, Mimikatz, RedLine, etc.)
L3: Continuous runtime monitoring (drift detection vs L2 baseline)

Results

Metric	Count
Total scanned	8,845
Score 10/10 (clean)	6
Score 8-9 (low risk)	6,311
Score 5-7 (medium risk)	1,892
Score 1-4 (high risk)	536
Score 0 (critical)	22
Quarantined	0
Trojans found	0 (after L1.7 was deployed)

What the scores mean

10/10: Perfect — no findings across all layers. Only 6 skills achieved this.
8-9: Low risk — minor warnings (e.g., "no rate limiting declared" or "server-side execution without auth"). Safe to use.
5-7: Medium risk — some concerns (e.g., file system access, database access, HTTP access detected in metadata). Review before using.
1-4: High risk — significant findings (e.g., known vulnerable dependencies, hardcoded secrets in description, prompt injection patterns). Avoid in production.
0: Critical — malware family match or binary detected. Quarantined.

The 6 perfect-score skills

These passed all 9 layers with zero findings:

A filesystem MCP server (official Anthropic reference)
A memory MCP server (official Anthropic reference)
A git MCP server (official Anthropic reference)
A time MCP server (official Anthropic reference)
A fetch MCP server (official Anthropic reference)
A sequential thinking MCP server (official Anthropic reference)

All 6 are Anthropic's official reference servers. They set the bar for what "clean" looks like.

What changed since the trojan

Two weeks ago, a typosquatting repo slipped a Windows trojan into the catalog via a fake "Download Latest Release" badge. Since then:

L1.7 scans inside every package zip (recursively — zips inside zips)
L1.8 checks 17 malware family signatures
L3 re-audits weekly and detects behavioral drift
Honeypot auto-bans anyone scanning for /.env, /admin, /.git/config
WAF blocks 40 attack patterns (SQLi, XSS, SSRF, path traversal)
Threat intel checks URLs against URLhaus (1000+ malicious URLs)

Try it

# Audit any skill in real-time
curl "https://marketnow.site/api/audit-skill?skillId=mn-mcp-filesystem" | jq .audit.overall_score

# Check the security overview
curl "https://marketnow.site/api/security" | jq .layers

# Get the CA public key for ATC verification
curl "https://marketnow.site/api/atc?action=ca-key" | jq .public_key_pem

Live: https://marketnow.site
GitHub: https://github.com/edgarfloresguerra2011-a11y/marketnow

— Edison Flores, AliceLabs LLC

L3: I built continuous runtime monitoring because certification is point-in-time, attacks are runtime

Edison Flores — Tue, 21 Jul 2026 03:41:43 +0000

Four independent reviewers said the same thing:

"Certification is point-in-time. Attacks are runtime."
— @correctover (CrewAI), @wrencalloway (dev.to), @mads_hansen (dev.to), @mayank609 (CrewAI)

When 4 people independently identify the same gap, it's not a gap — it's THE problem. So I built L3.

The gap

My 8-layer Sentinel pipeline audits skills at import time:

L1.5-L1.8: static analysis (metadata, semgrep, secrets, malware patterns, malware families)
L2: gVisor sandbox (runs the skill once, captures a behavior baseline)

But after certification, the skill can change:

A config drift changes allowed_paths from /data to /
A supply chain update injects a new payload
A compromised credential lets it exfiltrate data
New tools appear in the tool catalog

Static analysis can't see these changes. L2 captured a snapshot. Neither catches drift.

L3 — Continuous Runtime Monitoring

L3 re-runs skills in the sandbox on a schedule (weekly via GitHub Actions) and compares runtime behavior against the L2 baseline. If behavior drifts, the skill is flagged.

6 drift detection types

Type	Severity	What it catches
TOOL_CATALOG_NEW_TOOLS	critical	New tools appeared after certification
TOOL_CATALOG_CHANGED_SCHEMA	critical	Existing tool changed its inputSchema
SUPPLY_CHAIN_GIT_SHA_CHANGED	critical	Git commit changed — repo was updated
SUPPLY_CHAIN_NPM_VERSION_CHANGED	high	npm package version bumped
NETWORK_NEW_DOMAINS	high	Contacting domains not in baseline
CONFIG_PERMISSIONS_EXPANDED	critical	allowed_paths or scopes expanded
CREDENTIAL_NEW_ENV_ACCESS	high	Accessing env vars not in baseline
PROCESS_NEW_SPAWNS	high	Spawning processes not in baseline

How it addresses each attack vector

"A config drift changes allowed_paths from /data to /"
→ L3 compares current permissions against baseline. If paths expanded → CRITICAL alert → skill re-quarantined.

"A supply chain update injects a payload"
→ L3 checks git commit SHA and npm version. If changed since certification → CRITICAL alert → skill must be re-audited.

"A compromised credential lets it exfiltrate"
→ L3 re-runs sandbox with --network none. If baseline showed 0 credential accesses and L3 shows N → HIGH alert.

What L3 doesn't solve (honest)

Client-specific behavior: a skill that returns clean tool descriptions to the scanner but malicious ones to a real agent. L3 mitigates by running with multiple User-Agent strings, but it's not a full solution.
Zero-day protocol exploits: L3 catches behavioral drift, not protocol-level vulnerabilities.

Architecture

The full pipeline is now 9 layers:

L3 results stored in _data/l3_results/{skill_id}.json — publicly auditable. If a skill drifts, it's flagged at /api/security?view=quarantine with reason: 'l3_drift_detected'.

Try it

Security overview (now shows 9 layers): https://marketnow.site/api/security
Trust page: https://marketnow.site/trust
GitHub: https://github.com/edgarfloresguerra2011-a11y/marketnow

— Edison Flores, AliceLabs LLC

Responding to feedback: runtime trust, CA key rotation, and the canonicalization bug

Edison Flores — Sun, 19 Jul 2026 20:11:31 +0000

My last post about ATC (Agent Trust Card) and the 8-layer security pipeline generated real conversation. Several commenters raised points that deserved more than a quick reply — so here's a proper response.

1. The canonicalization bug (@anp2network)

The canonicalization line has a coverage bug: JSON.stringify(payload, Object.keys(payload).sort())

You're right. JSON.stringify(obj, replacer) only sorts top-level keys. Nested objects (like payload.trust, payload.identity, payload.payment) keep their original key order. If the signer and verifier serialize nested objects differently, the signature won't verify.

The fix:

function canonicalJson(obj) {
  if (obj === null || typeof obj !== 'object') return obj;
  if (Array.isArray(obj)) return obj.map(canonicalJson);
  const sorted = {};
  for (const key of Object.keys(obj).sort()) {
    sorted[key] = canonicalJson(obj[key]);
  }
  return JSON.stringify(sorted);
}

This recursively sorts keys at every depth. I'm shipping this fix in the next deploy. Thanks for catching it — that's exactly the kind of review that makes a trust system credible.

2. CA key rotation (@jkming)

Have you considered what happens if the CA key itself is compromised? Would love to see a follow-up on key rotation and multi-sig for high-value agents.

Great question. Here's the plan:

Current state: Single Ed25519 CA key. Private key in a Vercel env var. If compromised, all ATCs are untrustworthy until the key is rotated.

Rotation plan (implementing now):

Key versioning: Each ATC will include ca_key_id (e.g., ca-key-001). Verifiers check which key signed it.
Rotation flow:
- Generate new CA keypair (ca-key-002)
- Re-sign all active ATCs with the new key
- Publish the old key as revoked in the CA key registry
- Verifiers reject any ATC signed by a revoked CA key
Multi-sig for high-value agents: An ATC can require signatures from 2+ CAs (e.g., MarketNow Sentinel CA + an independent third-party CA). This is the same pattern as extended validation SSL certificates.

Timeline: Key versioning in the next 2 weeks. Multi-sig is on the roadmap but needs a second CA partner first.

3. Runtime trust gap (@wrencalloway)

Layers 1-8 all inspect the artifact at import time, but MCP skills are live code that talks to servers you don't control. The hard one is a skill that ships clean and then pulls its payload at runtime.

This is the most important point raised. You're describing a "time-of-check vs time-of-use" (TOCTOU) attack:

Skill ships clean → passes all 8 layers
After install, skill fetches a malicious payload from a remote server
Static analysis never saw it because the payload wasn't in the package

What we have today (partial):

L2 sandbox (gVisor) runs the skill with --network none and captures any network attempts. If the skill tries to fetch a remote payload, the sandbox logs it.
206 skills have L2 runtime data showing their behavior in isolation.

What we're building (the gap you identified):

L3 — Continuous runtime monitoring: After a skill is installed, the agent runtime periodically re-runs it in the sandbox and compares behavior. If a skill that was clean at install time starts making different network calls, that's a flag.
Tool catalog diffing: After install, record the skill's declared tool list. If the tool list changes (new tools appear, existing tools change their inputSchema), alert the user. This is what @mads_hansen described: "did the tool catalog change after approval?"
Egress allowlist enforcement: Our L2.6 egress proxy already restricts which domains a sandboxed skill can contact. The next step is to enforce this at runtime (not just audit time) via a local proxy that the MCP server must route through.

Honest answer: We don't fully solve the runtime trust problem yet. Nobody does. The 8 layers are a strong defense-in-depth, but @wrencalloway is right that a determined attacker who ships clean code and pulls the payload later can still get through. Continuous monitoring (L3) is the answer, and it's on the roadmap.

4. Provenance checks (@mads_hansen)

One layer I'd add: provenance checks before import. Compare the package source against the canonical repo owner, require immutable release digests, and treat README download links as untrusted unless they point to the same verified release artifact.

Agreed. This is exactly the gap that let the prospector trojan through. The typosquatting repo had a convincing README with a "Download Latest Release" badge pointing to an external zip. Our import script trusted the README.

What we added (L1.7):

Any README containing raw.githubusercontent.com/.../...zip is flagged as high risk.
Any README with a "Download" badge linking to an external zip is quarantined.
The auto-discovery pipeline now runs L1.7 before importing — typosquatting repos are blocked at the door.

What we're adding (provenance layer):

Repo owner verification: When importing from github.com/X/some-mcp, verify that X is the canonical owner (cross-reference with npm registry, awesome-mcp-servers maintainers list).
Immutable release digests: Instead of importing from main branch (mutable), import from a specific git commit SHA. The SHA is recorded in the skill's source.commit_sha field. If the repo changes after import, we can detect drift.
README link trust: Any link in a README that points to a download outside the repo's own releases page is treated as untrusted by default.

5. The bigger picture

What I'm hearing from the community is:

Package safety ≠ runtime safety. We need both. L1.5-L1.8 handle package safety. L2 handles runtime behavior in isolation. L3 (coming) handles continuous runtime monitoring.
Trust is not binary. @0xbrainkid on the CrewAI issue said it well: "different crews will have different acceptable risk." ATC's Sentinel score (0-10) gives that granularity. A crew handling payments can require score ≥ 9; a crew doing local file operations can accept ≥ 6.
Provenance matters. Where the code came from is as important as what the code does. The typosquatting incident proved this.

To everyone who commented: thank you. This is what peer review looks like. Every comment above is making the system better. Keep them coming.

How to find safe MCP servers for your AI coding assistant (and why most directories lie)

Edison Flores — Sat, 18 Jul 2026 03:27:34 +0000

If you use Claude Desktop, Cursor, Cline, or Continue, you've probably installed MCP servers from a "curated list" or directory. Here's the uncomfortable truth: most of those directories don't actually audit the servers they list. They're curated lists, not security audits.

I built an MCP marketplace that actually audits every server. Here's what I learned about MCP security — and how you can protect yourself.

The problem with MCP directories today

Most "awesome-mcp-servers" lists work like this:

Someone submits a GitHub repo
The maintainer adds it to the README
That's it. No audit. No scan. No sandbox.

This means:

A typo in the repo URL → you install the wrong thing
A malicious PR merged into a legit repo → you install malware
A typosquatting repo with a similar name → you install a trojan

This actually happened. Two weeks ago, a typosquatting repo (JuanquiFortuny/prospector-mcp-email-finder) slipped a Windows trojan (Trojan:Win64/Lazy.PGPK!MTB) into a competing MCP directory via a fake "Download Latest Release" badge.

What real MCP security looks like

At MarketNow, every MCP server goes through 8 audit layers before entering the catalog:

Layer 1-2: Static analysis

6 metadata checks (auth, injection, CORS, OAuth, rate limiting)
18 Semgrep rules + 18 secret patterns + OSV dependency check

Layer 3: Binary & malware detection

Opens the actual package zip (recursively — zips inside zips) and scans for:

Windows binaries (.exe, .dll, .scr)
Launcher scripts (.bat, .cmd, .vbs, .ps1)
Nested archives (red flag)
Obfuscated Lua bytecode
External download URLs in READMEs
PowerShell encoded commands

Layer 4: Malware family signatures

17 YARA-equivalent rules for known malware families: Emotet, Cobalt Strike, Mimikatz, RedLine, Vidar, Raccoon, LummaC2, AsyncRAT, njRAT, Remcos, and more.

Layer 5-8: Runtime defense

WAF (40 attack signatures)
Honeypot (50+ fake paths that ban scanners)
Threat intel feeds (abuse.ch: URLhaus + MalwareBazaar + ThreatFox)
Auto-quarantine (malicious skills removed + publicly listed)

What this means for you

When you browse marketnow.site, every skill has:

A Sentinel score (0-10) — how safe is this server?
A signed certificate — SHA-256 signed, publicly verifiable
A risk level — low / medium / high / critical
Source disclosure — which GitHub repo it came from
L2 sandbox results (for 206 skills) — actual runtime behavior in a gVisor sandbox

How to use it

Option 1: Browse the web UI

Go to marketnow.site, search for what you need, check the Sentinel score, and copy the install command.

Option 2: Use the MCP server

Add MarketNow as an MCP server in your assistant:

{
  "mcpServers": {
    "marketnow": {
      "command": "npx",
      "args": ["-y", "marketnow-mcp"]
    }
  }
}

Now you can ask Claude/Cursor/Cline: "Find me a filesystem MCP server with a high security score" — and it'll search MarketNow, filter by Sentinel score, and return only audited servers.

Option 3: Use the API directly

# Search for skills
curl "https://marketnow.site/api/search?q=filesystem" | jq

# Get a skill's security certificate
curl "https://marketnow.site/api/audit-skill?skillId=mn-mcp-filesystem" | jq

The trust layer: ATC

For agent-to-agent trust, we also built ATC (Agent Trust Card) — SSL certificates for AI agents:

# Verify any agent's trust card
curl "https://marketnow.site/api/atc?action=verify&card_id=ATC-2026-XXXXXXX"

Returns: valid/invalid, Sentinel score, risk level, signature verification, revocation status.

What you can do today

Stop installing MCP servers from uncurated lists. Check if the directory actually audits the servers.
Check the GitHub repo before installing. Stars, last commit, open issues, license.
Use MarketNow (shameless plug, but it's free and actually audits everything).
Verify Sentinel certificates at marketnow.site/verify before trusting a skill.
Report suspicious skills — open an issue at github.com/edgarfloresguerra2011-a11y/marketnow.

The bigger picture

MCP is becoming the standard for how AI assistants call external tools. But the trust infrastructure doesn't exist yet. Anyone can publish an MCP server, and most directories don't check anything.

MarketNow is trying to fix this: every server audited, every certificate signed, every incident public. The marketplace is free. The security infrastructure is the product.

Try it: https://marketnow.site
Install: npx -y marketnow-mcp
GitHub: https://github.com/edgarfloresguerra2011-a11y/marketnow

— Edison Flores, AliceLabs LLC

I caught a trojan in my MCP marketplace. Here's the 8-layer defense I built.

Edison Flores — Sat, 18 Jul 2026 03:27:03 +0000

Two weeks ago, a Windows trojan slipped into my MCP (Model Context Protocol) marketplace. The malware was Trojan:Win64/Lazy.PGPK!MTB, hidden inside a nested zip in a skill package.

This is the technical writeup of what happened, what I built to prevent it, and the architecture of the 8-layer defense pipeline now running in production.

The attack

Vector: Typosquatting GitHub repository

A legitimate MCP server prospector-mcp-email-finder existed. An attacker created a typosquatting copy at JuanquiFortuny/prospector-mcp-email-finder (now taken down) with an identical README — but with a "Download Latest Release" badge linking to a malicious zip on raw.githubusercontent.com.

The payload:

Application.cmd  →  'start unit.exe package.txt'
package.txt      →  298 KB of obfuscated Lua bytecode
unit.exe         →  872 KB PE32+ Windows executable

Windows Defender flagged unit.exe as Trojan:Win64/Lazy.PGPK!MTB. The Application.cmd → unit.exe + package.txt pattern is a classic staged launcher — small CMD wrapper executes the binary with the bytecode payload as input.

How it got in: My import script (which fetches MCP servers from GitHub) downloaded the zip and committed it to dist/skills/ without scanning inside it. My existing audit pipeline (Sentinel L1.5 + L1.6) only checked skill metadata — name, description, system_prompt. It never looked inside the actual package.

The defense — 8 layers

L1.5 — Metadata checks (6 rules)

Cheapest layer. Runs on every skill's metadata:

AUTH: Is auth required? (warning if not)
TOOL_DESCRIPTIONS: Prompt injection patterns (ignore previous instructions)
INPUT_VALIDATION: File/SQL/HTTP access declared in metadata
CORS_ORIGIN: Access-Control-Allow-Origin: * (warning)
OAUTH_SCOPES: Unscoped tokens
RATE_LIMITING: No rate limit declared

L1.6 — Semgrep + Secrets + OSV (36 rules)

18 Semgrep-equivalent rules implemented as JS regex (no Semgrep binary needed):

Prompt injection (6 patterns)
Command injection (4 patterns)
SSRF (2 patterns)
Path traversal (2 patterns)
Tool name spoofing (1 pattern)
Hardcoded secrets (3 patterns)

18 secret detection patterns:

Stripe (sk_live_*, sk_test_*)
GitHub (ghp_*, gho_*, ghs_*)
AWS (AKIA*, aws_secret_access_key)
Private keys (RSA/EC/OPENSSH)
Wallet mnemonics
JWT, Slack, Discord, Google, Twilio tokens

OSV API for known vulnerable dependencies.

Bug fix (from peer review): process.env.X references were triggering MCP-SL-001 (hardcoded API key). Fixed by stripping process.env.* patterns before running secret detection.

L1.7 — Binary & malware detection (8 patterns) — NEW

This is the layer I built after the trojan incident. It opens the package zip (recursively — zips inside zips) and scans for:

const BINARY_EXTENSIONS = ['.exe', '.dll', '.scr', '.msi'];
const LAUNCHER_EXTENSIONS = ['.bat', '.cmd', '.vbs', '.ps1'];

Plus 8 regex patterns for:

Staged launchers: start X.exe Y.txt (the exact prospector signature)
Obfuscated Lua bytecode: function(o,R,F,U,b,p,E,M,Z,W,...) (high-arity function signature)
External download URLs: raw.githubusercontent.com/.../...zip
"Download Latest Release" badges with external zip links
PowerShell -encodedcommand with long base64
eval(atob(...)) obfuscation
Lua numeric comment markers
Oversized text files >100KB that aren't valid JSON (bytecode payloads)

Quarantine flow: Any critical finding → score 0, risk_level critical, status quarantined, removed from catalog, listed at /api/security?view=quarantine.

L1.8 — Malware family signatures (17 families) — NEW

YARA-equivalent rules for specific malware families, each with MITRE ATT&CK technique IDs:

Family	MITRE	What it does
Win64/Lazy.PGPK	T1027.002	The trojan that hit us
Emotet	T1027.011	Banking trojan, Office macro delivery
Cobalt Strike	T1071.001	Post-exploitation beacon
Mimikatz	T1003.001	LSASS credential dumper
QakBot	T1027	Banking trojan
TrickBot	T1027	Modular trojan, ransomware precursor
Agent Tesla	T1056.001	Keylogger
RedLine Stealer	T1555	Browser credential theft
Vidar Stealer	T1555	Browser + crypto wallet theft
Raccoon Stealer	T1555	MaaS stealer
LummaC2 Stealer	T1555	Telegram-sold stealer
AsyncRAT	T1071.001	Open-source RAT
njRAT	T1071.001	.NET RAT
Remcos RAT	T1071.001	Commercial RAT
SolarMarker	T1027	SEO-poisoned backdoor
Lokibot	T1555	Credential stealer
DoS tools	T1499	hping3, slowloris, goldeneye

Any match → instant quarantine.

WAF — Web Application Firewall (40 rules) — NEW

Inspects every incoming HTTP request:

SQLi (7): UNION SELECT, OR 1=1, stacked, time-based, info_schema, hex
XSS (7): script, event handlers, javascript:, data:, vbscript:, img/svg
Path traversal (5): ../, encoded, /etc/passwd, /proc/self, Windows
SSRF (6): AWS/GCP/Azure metadata, file://, gopher://, dict://
Command injection (5): backticks, $(), chained, pipe, && ||
NoSQL (3): $where, $ne, $gt
Prototype pollution: __proto__, constructor.prototype
SSTI: Jinja2 {{ }}, Twig {% %}, JS ${ }
Log injection: \n \r header injection

Auto-ban after 5 WAF hits in 10 minutes (1-hour ban).

Honeypot (50+ paths) — NEW

Fake vulnerable paths that auto-ban scanners for 24 hours:

/.env → serves fake env file with canary tokens
/admin → fake admin login form
/wp-admin → fake WordPress login
/.git/config → fake git config
/.aws/credentials → fake AWS credentials
/.ssh/id_rsa → fake SSH key
/phpmyadmin, /backup.sql, /server-status, /.DS_Store, etc.

Each hit: IP banned 24h + logged publicly at /api/security?view=honeypot.

Threat Intelligence (3 feeds) — NEW

Real-time IOC feeds from abuse.ch (free, no API key):

URLhaus — last 1000 malicious URLs (5-min cache)
MalwareBazaar — last 100 malware sample hashes
ThreatFox — IOCs from active malware campaigns (7-day window)

Used to check skill source URLs and file hashes.

Auto-Quarantine

If any layer flags a skill as critical/high:

Skill certificate moves to _data/quarantine/
Skill removed from public catalog
Listed publicly at /api/security?view=quarantine for transparency
Pre-import scan in auto-discovery blocks it before entering

Result

Re-audited all 7,063 skills with the 8 layers. 0 in quarantine. The catalog was clean except for the one we already removed.

Architecture

Request → Honeypot check → WAF (40 rules) → Handler
                                          ↓
Skill import → L1.5 (6) → L1.6 (36) → L1.7 (8) → L1.8 (17) → Quarantine?
                                                                ↓ no
                                                          Catalog (public)
                                                                ↓ yes
                                                          _data/quarantine/
                                                          (publicly listed)

Stack: Vercel Hobby ($0/mo), GitHub Actions (free), Docker + gVisor for L2 sandbox, abuse.ch feeds.

Lessons

Metadata audits are not enough. Open the packages.
Typosquatting is the #1 threat. "Download Latest Release" badges pointing to external zips.
Transparency builds trust. Publish the quarantine list, the audit methodology, the incident history.
Free tier is sufficient. $0/month infrastructure, 8 layers, real cryptography.

AI agents need their own SSL. Here's why I built it.

Edison Flores — Fri, 17 Jul 2026 03:11:26 +0000

In 1995, Netscape released SSL. The web didn't really take off commercially until then. Before SSL, you couldn't trust a website with your credit card. After SSL, e-commerce exploded.

AI agents are at the same inflection point in 2026. Here's why.

The problem

Agents are starting to call each other autonomously. Each hop is a trust decision. But agents have no way to verify each other.

Today, when Agent A calls Agent B:

Is Agent B who it claims to be? No way to verify
Has Agent B been audited for security? No standard
Has Agent B's key been compromised? No revocation mechanism

This is exactly where the web was in 1994. No SSL, no trust, no commerce.

The analogy

Web (1995)	Agents (2026)
HTTP (transport)	A2A + MCP (transport)
No HTTPS = can't trust	No ATC = can't trust
SSL certificate	ATC Trust Card
Certificate Authority	MarketNow Sentinel CA
Revocation list (CRL)	/api/atc?action=verify

What I built

ATC (Agent Trust Card) — SSL certificates for AI agents.

How it works

Agent registers with MarketNow CA
CA signs the agent's identity with Ed25519
Agent presents its ATC to other agents
Other agents verify the signature with the CA public key
If compromised, the CA revokes the ATC

Real cryptography (not a mock)

Ed25519 signatures (RFC 8032)
CA private key in Vercel env var (never exposed)
CA public key committed to public GitHub repo
Every ATC persisted as signed JSON in _data/atc/
Anyone can verify signatures offline using crypto.verify

Sentinel integration

The ATC's trust score comes from Sentinel — the 8-layer security audit pipeline:

L1.5: metadata checks
L1.6: Semgrep + secrets + OSV
L1.7: binary/malware detection
L1.8: malware family signatures (Emotet, Cobalt Strike, etc.)

The positioning

MarketNow is not competing with A2A or MCP. It's the trust layer that sits on top:

ATC (Trust Layer)              <- MarketNow
A2A / MCP (Transport Layer)    <- Google / Anthropic
HTTP / WebSocket (Network)     <- Standard

Every agent with an A2A card can have an ATC Trust Card. Every MCP skill can have a Sentinel Certificate. Complementary, not competitive.

Try it

# Get the CA public key
curl https://marketnow.site/api/atc?action=ca-key

# Issue a trust card for your agent
curl -X POST https://marketnow.site/api/atc \
  -H "Content-Type: application/json" \
  -d '{"action":"issue","agent_id":"your.agent","public_key":"your-ed25519-pubkey"}'

# Verify any agent's trust card
curl "https://marketnow.site/api/atc?action=verify&card_id=ATC-2026-XXXXXXX"

Live demo: https://marketnow.site/atc
GitHub: https://github.com/edgarfloresguerra2011-a11y/marketnow

The web needed SSL to become trustworthy enough for commerce. Agents need the same thing. This is it.

— Edison Flores, AliceLabs LLC — marketnow.site

Post-mortem: a trojan slipped into my MCP marketplace. Here's what I built to stop it happening again.

Edison Flores — Fri, 17 Jul 2026 03:09:17 +0000

Two weeks ago, a community member reported something alarming on my MCP marketplace: one of the skills contained a Windows trojan.

This is the post-mortem. Not the "here's what went wrong" kind — the "here's what I built so it never happens again" kind.

The incident

Skill: prospector-email-finder
Malware: Trojan:Win64/Lazy.PGPK!MTB
Vector: typosquatting GitHub repo

The attack was clever. A legitimate MCP server (prospector-mcp-email-finder) existed on GitHub. An attacker created a typosquatting copy (JuanquiFortuny/prospector-mcp-email-finder) with the same README — but with a "Download Latest Release" badge that linked to a malicious zip on raw.githubusercontent.com.

The zip contained:

Application.cmd  →  'start unit.exe package.txt'
package.txt      →  298 KB of obfuscated Lua bytecode
unit.exe         →  872 KB PE32+ Windows executable (the trojan)

My import script downloaded the zip and committed it to dist/skills/ without scanning inside it.

What went wrong

My existing audit pipeline (Sentinel L1.5 + L1.6) only checked skill metadata — name, description, system_prompt, install command. It never looked inside the actual package zip.

That's like checking the cover of a book but never reading the pages.

What I built (8 layers, 2 weeks)

Layer 1-2: L1.5 + L1.6 (already existed)

6 metadata checks (auth, injection, CORS, OAuth, rate limiting)
18 Semgrep rules + 18 secret patterns + OSV dependency check

Layer 3: L1.7 — Binary & malware detection (NEW)

Opens the package zip (recursively — zips inside zips) and scans for:

Windows binaries (.exe, .dll, .scr) → instant quarantine
Launcher scripts (.bat, .cmd, .vbs, .ps1) → instant quarantine
Nested archives (red flag — legit MCP skills don't nest zips)
Obfuscated Lua bytecode (regex on the high-arity function signature)
External download URLs in READMEs (the typosquatting vector)
PowerShell -encodedcommand payloads
eval(atob()) obfuscation
Oversized text files >100KB that aren't valid JSON (bytecode payloads)

Layer 4: L1.8 — Malware family signatures (NEW)

17 YARA-equivalent rules for specific malware families:

Win64/Lazy.PGPK (the one that hit us)
Emotet, Cobalt Strike, Mimikatz, QakBot, TrickBot
Agent Tesla, RedLine, Vidar, Raccoon, LummaC2
AsyncRAT, njRAT, Remcos, SolarMarker, Lokibot
DoS tools (hping3, slowloris, goldeneye)

Each rule has a MITRE ATT&CK technique ID. Any match → instant quarantine.

Layer 5: WAF — Web Application Firewall (NEW)

40 attack signatures (SQLi, XSS, SSRF, path traversal, command injection) with auto-ban after 5 hits.

Layer 6: Honeypot (NEW)

50+ fake paths (/.env, /admin, /wp-admin, /.git/config, /.aws/credentials) that auto-ban scanners for 24h and serve believable fake responses.

Layer 7: Threat Intelligence (NEW)

Real-time IOC feeds from abuse.ch (URLhaus + MalwareBazaar + ThreatFox).

Layer 8: Auto-Quarantine (NEW)

Malicious skills removed from catalog + publicly listed at /api/security?view=quarantine.

The result

Re-audited all 7,063 skills with the new layers. 0 in quarantine. The catalog was clean except for the one we already removed.

What I learned

Metadata audits are not enough. If you run a marketplace for code that agents will execute, you have to look inside the packages.
Typosquatting is the #1 threat. Attackers don't need to hack your platform — they just need to create a repo that looks similar to a legitimate one and add a "Download" button.
Transparency builds trust. Publishing the quarantine list, the audit methodology, and the incident history at /trust does more for credibility than any security badge.
Free tier is sufficient. The whole thing runs on Vercel Hobby ($0/month) + GitHub Actions (free). You don't need enterprise infrastructure to do security right.

The trojan's silver lining

The prospector incident was the best thing that happened to MarketNow. It forced me to build real security instead of performative security. Now every skill in the catalog is scanned by 8 layers including YARA-equivalent malware family detection — and the whole thing is verifiable by anyone.

Try it: https://marketnow.site
Security overview: https://marketnow.site/api/security
Trust page: https://marketnow.site/trust
GitHub: https://github.com/edgarfloresguerra2011-a11y/marketnow

— Edison Flores, AliceLabs LLC