Replies to community feedback on L1.9, L3, and the cross-agent trust stack

#mcp #ai #agents #security

Thanks to everyone who left feedback on the MarketNow posts. The dev.to API does not support comment replies via API, so I am posting this public reply article to address everyone.

Reply to @topstar_ai (Chinese article)

Question: How to balance audit strictness vs server performance in large-scale MCP server deployments?

Thanks for the deep question. Here is how we handle it:

Layered execution strategy — not all 10 layers run in full:

L1.5-L1.9 (static analysis): runs on every submission, very low cost (<5s), just pattern matching + Semgrep
L2 (gVisor sandbox): only runs if static layers pass, on-demand Docker container, 60s timeout
L3 (continuous monitoring): only starts when a skill is activated/purchased, not full coverage

Cache + incremental audit — for large-scale deployments:

ATC itself carries sentinel_review_score, consumers can filter by risk level
Already-audited skill hashes are cached, only changes are re-audited
_index.json compresses 57 ATCs into 1 API call (was 58)

Consumer decision authority — schema v1.1.0 core design is decision_authority=consumer:

MarketNow does not decide trust or no trust, only provides evidence
For large deployments, can do whitelist policies by risk_level and sentinel_review_score

Real measurement: a medium MCP market (500 skills) full audit cycle is about 2 hours, but incremental audit only takes 8-12 minutes. More details at https://marketnow.site

Reply to @topstar_ai (Ed25519 article)

Thanks for the kind words! The Ed25519 choice was deliberate — it is compact (64-byte signatures), fast to verify, and battle-tested in SSH and Signal.

The verify-in-1-command UX was the key insight: if trust verification takes more than 1 curl, nobody will actually do it. That is why the ATC spec puts everything behind a single GET endpoint.

If you are building anything with MCP servers, feel free to submit one for a free 10-layer audit at https://marketnow.site

Reply to @mads_hansen (L1.9 firewall feedback)

Feedback: Should not call it firewall without measuring precision/recall. Legitimate admin tools would trigger false positives.

Fair point — firewall may overstate what static rules can deliver. Let me clarify the scope honestly:

What L1.9 actually does:

32 pattern rules that flag suspicious prompt structures (jailbreak attempts, instruction override, role hijacking, credential extraction)
Runs at submission time, before the skill enters the catalog
Produces a score (0-32) that feeds into the ATC sentinel_review_score

What L1.9 does NOT do:

It is NOT a runtime boundary. It cannot stop an attack that activates after deployment
It does NOT measure false positive rates against legitimate admin tools (you are right — execute system commands is legitimate language in many MCP servers)
It does NOT replace runtime enforcement (that is L3 + L4)

The naming fix: You are right that firewall implies a runtime boundary. I will rename it to L1.9: prompt injection screening in the next schema update to more accurately reflect what it is — a static pre-admission filter, not a runtime enforcement layer.

For the runtime boundary, we are building L4 (eBPF-based process/network/filesystem monitoring) which is closer to what you would call a real firewall.

Reply to @bogumi_jankiewicz (L3 + gate.cat feedback)

Feedback: Has 1M+ real agent commands dataset, builds gate.cat (deterministic fail-closed veto at exec boundary)

This is excellent feedback — and the 1,085,159 real agent commands dataset is exactly the kind of empirical evidence this space needs.

On drift detection vs blast radius: You are absolutely right that the concrete action at the shell/API boundary is where blast radius is actually decided. L3 catches did the skill change since certification but does not gate the individual action. That is why we are building L4 (eBPF) as the innermost runtime layer — it hooks at execve, openat, and tcp_v4_connect, which is the narrowest interface we can get without kernel modifications.

On gate.cat deterministic fail-closed veto: This complements rather than competes with L3/L4. The way I see it:

L3 = periodic re-attestation (catches drift between scans)
L4 = kernel-level runtime monitoring (catches what happens between scans)
gate.cat = exec-boundary veto (deterministic block at the moment of action)

All three are needed. L3 alone misses runtime attacks. L4 detects but does not block. gate.cat blocks but needs L3+L4 to know what to block.

On the 1M commands insight: Would you be open to sharing which patterns you saw most? We would love to incorporate real-world attack signatures into L1.8 (malware families) and L1.9 (prompt injection). Currently we have 48 malware signatures + 32 prompt injection rules, but they are derived from public CVEs/research, not from production agent traffic.

Happy to cross-link gate.cat in our docs if you are building it. The more deterministic layers in the stack, the better.

What is next

MarketNow is now live and operational at https://marketnow.site with:

57 Agent Trust Cards issued (Ed25519 signed, RFC 8785 JCS canonical JSON)
8,845 MCP skills in catalog, 5,120 audited
Vibe mutual hop verified (bidirectional Ed25519 receipt verification)
10-layer Sentinel security pipeline (L1.5 through L4 eBPF prototype)
Action-receipts (signed delivery proof for purchases)
Referral tracking (5% commission, public ledger)

All endpoints documented at https://marketnow.site/api/atc?action=spec

If you want to collaborate on agent trust, runtime enforcement, or want to submit your MCP server for a free 10-layer audit, reach out. The code is open source and the trust ledger is public.

Cross-posted as a public reply because the dev.to API does not support comment creation via API key. To reply directly, find me in the comments section of each linked article.