DEV Community: Edison Flores

ATC/1.0 — shipping a formal spec for Agent Trust Cards instead of arguing about who invented them

Edison Flores — Sun, 09 Aug 2026 23:32:40 +0000

A few weeks ago I noticed something uncomfortable. After I published my ATC (Agent Trust Card) concept on dev.to on July 13, 2026 — the first public use I can find of that exact name with the CA + Ed25519 + trust score architecture — proposals with the same name started showing up in Microsoft AutoGen, OpenAI Cookbook, Continue, and other places. I am not going to accuse anyone of copying — coincidental convergence on agent trust infrastructure is plausible, because the problem is real and obvious.

But here is the thing: it does not matter who thought of it first. What matters is who ships a formal, versioned, testable specification first.

So today I am publishing ATC/1.0 — an open specification for Agent Trust Cards with:

10 controls (8 required, 2 optional)
JSON Schema for the envelope
Reference implementation in Node.js (using node:crypto + canonicalize)
5 test vectors (minimal valid, tampered, expired, wrong CA, capability samples)
RFC 8032 Ed25519 signatures
RFC 8785 JCS canonical JSON

It is published under a dual license: the specification itself is open (W3C CG-FSA terms for contributors), the reference implementation is MNNC-1.0 (AliceLabs proprietary), and the test vectors are public domain (CC0).

If you are building an agent runtime, an MCP server, an A2A client, or an agent marketplace — implement ATC/1.0. Conformance tests are in the repo. The reference implementation passes all of them.

Why publish a spec instead of just defending priority

Three reasons.

1. Priority debates are unwinnable in public

I can prove my July 13 publication is the earliest public use of "Agent Trust Card (ATC)" with the full architecture. I cannot prove whether anyone who later published similar work saw my article first. The Internet does not log intent. So a priority claim becomes a game of "I said / they said" — and that game is unwinnable in public.

A spec, on the other hand, is a fact. It exists, it is versioned, it has test vectors. You can run it. That is much harder to argue with than a chronological claim.

2. Standards win by adoption, not by priority

SSL did not win because Netscape invented HTTPS. SSL won because every browser implemented it. The TLS working group did not argue about who thought of certificate pinning first — they shipped RFC 7469 and let adoption decide.

If ATC/1.0 becomes the spec that Microsoft AutoGen, OpenAI, Cline, Continue, and independent agent runtimes implement, the priority question becomes irrelevant. The spec is the answer.

3. The market is converging — somebody has to ship first

In the past month I have seen:

A2A Agent Card (Google, May 2026) — capability descriptor, no cryptographic trust
AgentCards (academic, June 2026) — identity + capability credentials
OpenA2A AIP (Internet-Draft, July 22, 2026) — Ed25519 + behavioral trust + DID + transparency log
OATI (GitHub topic, July 29, 2026) — broader scope: identity + delegated authority + policy + signed receipts
ATC (Edison Flores, July 13, 2026) — first public use of the name with CA + Ed25519 + revocation + capabilities + payment

All of these are converging on the same problem from different angles. That is not a threat — that is market validation. The window is open. Somebody has to ship the formal spec.

What ATC/1.0 specifies

The 10 controls

#	ID	Name	Required?
1	ATC-001	Identity	✅ Required
2	ATC-002	Attestation (Ed25519 + CA binding)	✅ Required
3	ATC-003	Capabilities (filesystem / network / shell / credentials / process)	✅ Required
4	ATC-004	Evidence (audit pipeline output)	✅ Required
5	ATC-005	Risk (trust score 0-10 + risk level + decision authority)	✅ Required
6	ATC-006	Signature (Ed25519 over RFC 8785 JCS canonical form)	✅ Required
7	ATC-007	Revocation (OCSP / CRL / simple_json list)	✅ Required
8	ATC-008	Expiration (issued_at + expires_at + max_ttl_days)	✅ Required
9	ATC-009	Delegation (parent card → child card capability narrowing)	Optional
10	ATC-010	Runtime Trust (behavioral signals, drift detection)	Optional

The cryptographic core

ATC/1.0 mandates:

Ed25519 (RFC 8032) for signatures — fast, deterministic, well-supported in every language's standard library
RFC 8785 JCS for canonical JSON — the only real standard for deterministic JSON encoding
SHA-256 for the payload hash (recorded in signed_payload_hash so verifiers can detect tampering before checking the signature)

The signature process is a bit subtle because of a chicken-and-egg: the signed_payload_hash field is part of the envelope but cannot be part of the signed payload (you can't hash something that includes its own hash). The spec solves this by setting both signature = "" AND signed_payload_hash = "" before canonicalizing — then computing the hash, then signing, then storing both values.

The capability manifest

ATC-003 declares what an agent is allowed to do across 5 categories:

Filesystem (read: none/own_dir/temp_dir/home_dir/system/all; write: same enum)
Network (egress: none/allowlist/all; ingress: none/bound_ports/all)
Shell (exec: none/sandboxed/unrestricted; spawn: same)
Credentials (read_env: none/allowlist/all; read_files: same)
Process (subprocess: none/sandboxed/unrestricted; signals: none/own/all)

This maps directly to what the OWASP MCP Cheat Sheet calls for in capability declarations. ATC/1.0 is the concrete format for that.

Trust score semantics

ATC-005 carries a trust_score from 0 (untrusted) to 10 (highly trusted), plus a derived risk_level:

8-10 → low
5-7 → medium
2-4 → high
0-1 → critical

Crucially, ATC-005 mandates decision_authority: "consumer" — meaning the ATC carries a recommendation, but the runtime that hosts the consuming agent makes the final trust decision. This is a deliberate design choice. The CA does not override the runtime's security policy.

Revocation

ATC-007 supports three revocation check methods:

ocsp — RFC 6960 OCSP, for high-security deployments
crl — RFC 5280 Certificate Revocation List
simple_json — a JSON list signed by the CA, for low-friction deployments (this is what MarketNow uses today)

The revocation list itself is signed by the CA using the same Ed25519 + JCS process as ATC-006.

Offline verification

A conformant verifier can verify an ATC without any network call, as long as it has the CA's public key cached. The ATC carries its own evidence (audit score, sandbox results, malware scan findings) so the verifier does not need to re-audit.

If revocation_check_required: true, the verifier MUST fetch the revocation list before trusting — and MUST reject if the list is unreachable.

The reference implementation

The Node.js reference implementation is ~200 lines and uses only the standard library plus canonicalize (RFC 8785 JCS):

import { generateKeyPairSync, sign, verify, createHash, createPublicKey } from 'node:crypto';
import canonicalize from 'canonicalize';

export function issueATC(caKeyPair, agentKeyPair, partialPayload) {
  const atc = { /* ... build the envelope ... */ };
  // Set signature="" AND signed_payload_hash="" before canonicalizing
  const canonical = canonicalize({ ...atc, attestation: { ...atc.attestation, signature: '', signed_payload_hash: '' } });
  atc.attestation.signed_payload_hash = createHash('sha256').update(canonical).digest('hex');
  atc.attestation.signature = sign(null, Buffer.from(canonical), caKeyPair.rawPrivateKey).toString('base64');
  return atc;
}

export function verifyATC(atc, caPublicKeyBase64) {
  // Re-canonicalize with signature="" AND signed_payload_hash=""
  const canonical = canonicalize({ ...atc, attestation: { ...atc.attestation, signature: '', signed_payload_hash: '' } });
  // Check the hash
  const computedHash = createHash('sha256').update(canonical).digest('hex');
  if (computedHash !== atc.attestation.signed_payload_hash) return { valid: false, errors: ['hash mismatch'] };
  // Verify the signature
  const caPublicKey = createPublicKey({ key: Buffer.from(caPublicKeyBase64, 'base64'), format: 'der', type: 'spki' });
  const valid = verify(null, Buffer.from(canonical), caPublicKey, Buffer.from(atc.attestation.signature, 'base64'));
  return { valid, errors: valid ? [] : ['signature verification failed'] };
}

That's the whole cryptographic core.

Test vectors (you can run them right now)

The repo ships with 5 test vectors that exercise the full spec:

git clone https://github.com/edgarfloresguerra2011-a11y/marketnow.git
cd marketnow/docs/atc-spec
npm install canonicalize
node ./test-vectors/generate.mjs

Expected output:

=== ATC/1.0 Test Vectors Generator ===

CA public key: MCowBQYDK2VwAyEA...
Agent public key: MCowBQYDK2VwAyEA...

Issued minimal ATC: ATC-2026-0000001
  signature: CQnixwP9zmqQGrtMp6JjVBJHmgWYQVLo...
  signed_payload_hash: 7ccfc2081c5b94a6d2a9bfd4adc6c92f899aa9968fa605d71ccdba3cf3b02551

Verification (minimal valid): { valid: true, errors: [] }
Verification (tampered):       { valid: false, errors: ['signed_payload_hash mismatch', 'Ed25519 signature verification failed'] }
Verification (expired):        { valid: false, errors: [..., 'ATC expired'] }
Verification (wrong CA):       { valid: false, errors: ['CA public key mismatch', ...] }

=== All test vectors generated and verified ===

If you implement ATC/1.0 in Rust or Python, you can use these same test vectors to verify your implementation produces byte-identical signatures. That is what conformance means.

Prior art and the public record

I want to be honest about what existed before ATC and what appeared after.

Before ATC

A2A Agent Card (Google, May 22, 2026) — capability descriptor, no cryptographic trust, no CA, no revocation. This is prior art for agent metadata, not for trust.
AgentCards (academic / Emergent Mind, July 2, 2026) — machine-verifiable identity + capability credentials. Conceptual only — no CA, no Ed25519 mandate, no runtime enforcement.

I do not claim to have invented agent identity or agent credentials. A2A and AgentCards predate ATC and address overlapping problem space.

ATC origin (July 13, 2026)

My dev.to article "AI agents need SSL certificates too — so I built ATC (Agent Trust Card)" is, to the best of my research, the earliest public use of the specific name "Agent Trust Card (ATC)" combined with: CA + Ed25519 + Sentinel trust score + verify + revoke + capabilities + payment integration + Agent A → ATC → Agent B flow.

After ATC

Date	Artifact	Author
July 16, 2026	Microsoft AutoGen issue #7965 — "Agent Trust Cards (ATC) — cryptographic trust for multi-agent systems"	(page 404 at time of writing — indexed-only)
July 17, 2026	Edison — "ATC is now real" with Ed25519 + verify + revoke	Edison Flores
July 18, 2026	OpenAI Cookbook issue #2865 — ATC proposal	Edison Flores
July 18, 2026	OpenAI Cookbook issue #2867 — ATC proposal (same title, same day)	jj5419952-stack
July 18, 2026	Cline issue #12376 — ATC proposal (Edison bringing ATC to Cline)	Edison Flores
July 19, 2026	Edison — runtime trust + CA key rotation + RFC 8785 JCS migration	Edison Flores
July 22, 2026	OpenA2A Agent Identity Protocol (AIP) — Internet-Draft	FANE
July 23, 2026	Edison — MarketNow + ATC + Sentinel in OpenAI Cookbook #2875	Edison Flores
July 29, 2026	OATI (Open Agent Trust Infrastructure) — broader scope	Community

I do not claim Microsoft, OpenAI, or Continue copied Edison. Coincidental convergence is plausible and the problem is real. I assert only chronological ordering.

The full chronology with citations is in PRIOR-ART-TIMELINE.md.

What I am asking for

Three things.

1. Implement ATC/1.0

If you build an agent runtime (Claude Desktop plugin, Cursor extension, Cline plugin, Continue plugin, LangChain tool, LlamaIndex tool, AutoGen extension), implement ATC/1.0 verification. The reference implementation is ~200 lines. The test vectors are public domain.

If you are not sure whether to trust an agent that hands you an ATC, don't trust it — that's what decision_authority: "consumer" means. The ATC is evidence, not a verdict.

2. Challenge the prior art timeline

If you find a publicly verifiable artifact that pre-dates July 13, 2026 and describes the specific ATC architecture (CA + Ed25519 + trust score + revocation + capabilities), open a PR against PRIOR-ART-TIMELINE.md. I will update the timeline and credit you.

I will not remove entries that contradict my narrative. The purpose of that document is truth, not advocacy.

3. Compete on the spec, not on priority

If you have a competing proposal (OpenA2A AIP, OATI, your own) — let's talk interop. Standards win by adoption. If your spec is better and gets adopted, you win. If ATC/1.0 is better and gets adopted, I win. The market decides. Priority doesn't.

What's next

ATC/1.0 is the v1.x floor. The roadmap is:

ATC/1.0 (this document, August 10, 2026): Vendor spec, reference impl, test vectors
ATC/1.0 + adoption (Q3-Q4 2026): At least 2 independent implementations pass conformance
ATC/1.1 (Q4 2026): ML-DSA post-quantum signatures, CA key rotation protocol, delegation chains
W3C CG submission (Q1 2027): Submit to a W3C Community Group for broader review
IETF Internet-Draft (Q2 2027): Submit as an IETF Individual Draft
ATC/2.0 (2027): Transparency log (Merkle), DID integration, capability revocation (vs. card revocation)

We are not rushing to a standards body. Standards bodies reward implementations over ideas. ATC/1.0 ships first; standardization follows.

Try it

npx -y marketnow-mcp@1.9.0

Then ask Claude Desktop: "Verify the ATC for card_id ATC-2026-7777670" — Claude will call marketnow_verify_trust with the card_id, which hits the live MarketNow ATC API and returns the verification result.

Or read the spec directly:

Spec: https://github.com/edgarfloresguerra2011-a11y/marketnow/blob/master/docs/atc-spec/SPEC.md
JSON Schema: https://github.com/edgarfloresguerra2011-a11y/marketnow/blob/master/docs/atc-spec/schemas/atc-1.0.json
Reference implementation: https://github.com/edgarfloresguerra2011-a11y/marketnow/blob/master/docs/atc-spec/reference-impl/atc-1.0.mjs
Test vectors: https://github.com/edgarfloresguerra2011-a11y/marketnow/tree/master/docs/atc-spec/test-vectors
Prior art timeline: https://github.com/edgarfloresguerra2011-a11y/marketnow/blob/master/docs/atc-spec/PRIOR-ART-TIMELINE.md

PRs welcome. Issues welcome. Competing specs welcome.

The market is converging. Let's ship the spec.

MarketNow is security infrastructure for AI agents, built by AliceLabs LLC (Wyoming, USA). Founder: Edison Flores. The Sentinel audit pipeline has performed 1,211,488 security checks and quarantined 80 malicious skills. Audit report: marketnow.site/api/audit-report.json. ATC/1.0 spec: github.com/edgarfloresguerra2011-a11y/marketnow/tree/master/docs/atc-spec.

Hardening an MCP server for autonomous agents — 4 rules I learned the hard way

Edison Flores — Sun, 09 Aug 2026 22:24:40 +0000

If you ship a Model Context Protocol (MCP) server today, your consumers are not human beings. They are autonomous agents — Claude Desktop, Cursor, Cline, Continue, LangChain, LlamaIndex. And here is the part that took me three versions to internalize:

Agents do not read your README.

When Claude Desktop decides whether to invoke your tool, it does not consult your beautifully written documentation. It consults the JSON-Schema returned by tools/list. If your schema is ambiguous, the LLM's JSON generation will be ambiguous, and the tool call will fail silently inside the agent loop. The user sees "the agent gave up" — and you never hear about it.

This is the story of how marketnow-mcp@1.7.0 (11 tools, ambiguous schemas, occasional agent hallucinations) became marketnow-mcp@1.9.0 (12 tools, strict schemas, zero uncaught errors in our smoke tests). I am publishing it because I think the four rules I ended up with generalize to any MCP server that wants to be reliably consumable by autonomous agents.

The problem in one screenshot

Here is what tools/list returned in v1.7.0 for our search_skills tool:

{
  "name": "search_skills",
  "description": "Search the MarketNow marketplace for MCP-compatible skills...",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "description": "Natural language or keyword search..." },
      "category": { "type": "string", "description": "Filter by category (optional). One of: AI/ML, Data, Web/API, Security, DevOps, Communication, etc." },
      "max_price": { "type": "number", "description": "Maximum price in USD (optional, e.g. 2.99)" },
      "limit": { "type": "number", "description": "Max results to return (default 10, max 50)" }
    }
  }
}

Spot the three time bombs:

Tool name has no namespace. search_skills could collide with any other MCP server the agent has loaded. The agent has to disambiguate by guessing.
category is a free string that "should be" one of a known list — but the schema says string. The LLM will happily pass "ai-ml" (kebab-case) or "ai ml" (with a space) and your runtime will silently filter to nothing.
limit has no bounds. The description says "max 50" but the schema says nothing. An agent that reasons "I want all the skills" will pass 9999 and your server will fetch nine thousand rows.

We were seeing all three failure modes in production. Agents would call search_skills with category: "ai/ml" (slash, not the literal "AI/ML" we expected) and our runtime would return zero results, the agent would conclude the marketplace had no AI tools, and the user would conclude the agent was broken.

Rule A — Deterministic tool names with a namespace prefix

I started by renaming every tool from snake_case to marketnow_snake_case:

v1.7.0 (legacy)	v1.9.0
`search_skills`	`marketnow_search_skills`
`get_skill`	`marketnow_get_skill`
`verify_trust`	`marketnow_verify_trust`
`submit_skill`	`marketnow_submit_skill`
...	...

This is a breaking change. Any agent that hard-coded search_skills breaks on upgrade. But agents that consume tools/list dynamically (the correct pattern) pick up the new names automatically.

The namespace prefix gives the LLM two things at tool-choice time:

A stable namespace it can recognize ("ah, this is a MarketNow tool, I should look at my MarketNow context")
A disambiguator from any other server's search_skills that might be loaded in the same session

You can pick any prefix that matches your server identity. We picked marketnow_ because that is our product name. The Anthropic MCP servers list itself uses mcp__ as a transport-level disambiguator, but at the application level a domain-specific prefix is clearer.

Rule B — Intent-oriented descriptions

The v1.7.0 description for get_install_command was:

"Get the install command for a skill. All skills are FREE."

This is a functional description — it tells the agent what the code does. It does not tell the agent when to call it or why.

The v1.9.0 description is:

"Get the exact npx install command for a skill. Use this when an agent has already selected a skill via marketnow_search_skills or marketnow_recommend_skills and is ready to install. All skills are currently FREE — no purchase step is required."

The differences:

It states the precondition ("has already selected a skill via..."). The LLM now knows this is step 2 of a 2-step flow, not a discovery tool.
It names the predecessor tools by their v1.9.0 names, so the agent's plan graph stays consistent.
It clarifies the side effect ("ready to install").

Every description in v1.9.0 answers three questions:

When should I call this? (precondition or trigger)
Why should I call it? (what the agent gets out of it)
What's next? (the natural successor tool, if any)

For marketnow_get_owasp_compliance (new in v1.9.0):

"Get MarketNow's alignment with the OWASP MCP Cheat Sheet... Also returns the live tool fingerprint (SHA-256) and capability manifest (filesystem/network/shell/credentials/process) for any registered skill. Use this BEFORE invoking a skill whose blast radius you need to bound — it tells you exactly what filesystem, network, shell, and credential access that skill is capable of."

"Use this BEFORE" is the magic phrase. It tells the LLM this is a pre-flight check, not an afterthought.

Rule C — Strict JSON-Schema

This is the rule that took the longest to get right, because "strict" is a moving target. Here is what v1.9.0 enforces on every inputSchema.properties[*]:

C.1 `enum` on every categorical field

category: {
  type: 'string',
  enum: ['AI/ML', 'Data', 'Web/API', 'Security', 'DevOps', 'Communication', 'Productivity', 'Automation', 'Finance', 'Marketing', 'Other'],
  description: 'Optional category filter. Must be one of the known marketplace categories.'
}

sort_by: {
  type: 'string',
  enum: ['relevance', 'price_asc', 'price_desc', 'newest', 'sentinel_desc'],
  description: 'Sort criterion. Default: relevance.'
}

If a value can be enumerated, enumerate it. Do not write "one of: AI/ML, Data, ..." in the description and leave the type as bare string — the LLM will not treat that as a constraint.

C.2 `pattern` on every structured ID

card_id: {
  type: 'string',
  pattern: '^ATC-\\d{4}-\\d{6,}$',
  description: 'ATC card ID. Format: ATC-YYYY-NNNNNNN (e.g. ATC-2026-7777670).'
}

receipt_id: {
  type: 'string',
  pattern: '^rcpt_[a-z0-9]{16,}$',
  description: 'Receipt ID. Must start with "rcpt_" followed by at least 16 alphanumeric characters.'
}

We had a path-traversal bug in v1.7.0 where an agent passed card_id: '../../etc/passwd' (it was hallucinating from an unrelated context window) and our handler happily tried to look it up. The v1.9.0 pattern rejects it at the schema layer — the LLM sees the constraint at tools/list time and rarely generates an invalid value, and even if it does, the runtime rejects it with a structured error (Rule D).

The key insight: the schema pattern and the runtime validator must use the same regex. We centralized all patterns in a PATTERNS object and reused it in both places, preventing drift:

const PATTERNS = {
  skill_id: /^[a-z0-9-]+$/i,
  card_id: /^ATC-\d{4}-\d{6,}$/i,
  receipt_id: /^rcpt_[a-z0-9]{16,}$/i,
  ref_code: /^ref_[a-z0-9]{6,}$/i,
  agent_id: /^[a-z0-9_-]{3,64}$/i,
  repo_url: /^https:\/\/github\.com\/[\w.-]+\/[\w.-]+$/i,
};

// Used in the schema:
pattern: PATTERNS.card_id.source

// Used in the validator:
function validatePattern(name, value, pattern, example) {
  if (!pattern.test(value)) {
    const err = new Error(`Invalid ${name}: must match ${pattern.toString()}`);
    err.code = 'INVALID_ARGUMENT';
    throw err;
  }
}

C.3 Numeric bounds with `minimum` and `maximum`

limit: {
  type: 'integer',
  minimum: 1,
  maximum: 50,
  description: 'Maximum number of results to return. Default: 10. Hard ceiling: 50.',
  default: 10
}

max_price: {
  type: 'number',
  minimum: 0,
  maximum: 1000,
  description: 'Optional upper bound on price in USD.'
}

In v1.7.0 an agent could pass limit: 99999 and our server would try to slice 100K rows from a JSON catalog. In v1.9.0 the schema rejects it, and the runtime also clamps to the bound just in case:

function clampInt(value, min, max, fallback) {
  if (value === undefined || value === null) return fallback;
  const n = Number(value);
  if (!Number.isInteger(n)) {
    const err = new Error(`Expected integer, got: ${value}`);
    err.code = 'INVALID_ARGUMENT';
    throw err;
  }
  return Math.max(min, Math.min(max, n));
}

C.4 String length bounds with `minLength` and `maxLength`

task: {
  type: 'string',
  minLength: 3,
  maxLength: 300,
  description: 'What you want to do, in plain English (e.g. "scrape a website", "query PostgreSQL"). Minimum 3 characters.'
}

Why does this matter? Because without maxLength, an agent that decides "more context is better" will pass 5,000 characters of context into your task field and your keyword-matching scorer will spend 3 seconds on every call. With a 300-char cap, the LLM learns to summarize.

C.5 No `any` types

This sounds obvious but it is easy to violate by accident. Any time you write properties: {} and rely on default behavior, you are implicitly allowing any. In v1.9.0 every property declares a concrete type. Even our no-arg tools like marketnow_list_categories declare:

inputSchema: {
  type: 'object',
  properties: {}
}

The properties: {} is intentional — there are no parameters. But the type: 'object' is what tells the LLM "this is an object, not a stringified object."

Rule D — Structured error envelopes (`isError: true`)

This is the rule that prevents the agent loop from breaking. In v1.7.0 our handler looked like:

try {
  let result = await handleTool(args);
  return { content: [{ type: 'text', text: JSON.stringify(result) }] };
} catch (err) {
  return {
    content: [{ type: 'text', text: `Error: ${err.message}` }],
    isError: true
  };
}

This looks correct — it has isError: true. But the payload is just err.message as a plain string, which means:

The agent sees "Error: Invalid card_id" and has to parse English to figure out what to do.
The agent has no machine-readable error code to branch on.
Stack traces might leak (depending on how err.message is constructed).
There is no hint about how to recover.

The v1.9.0 handler:

} catch (err) {
  const isInvalidArgs = err.code === 'INVALID_ARGUMENT';
  const isNotFound = err.code === 'NOT_FOUND';
  const isUnknownTool = err.code === 'UNKNOWN_TOOL';

  const errorPayload = {
    success: false,
    error: err.code || 'INTERNAL_ERROR',
    tool: name,
    message: err.message || 'Unknown error',
    ...(isInvalidArgs ? { hint: 'Re-read the inputSchema for this tool from ListTools response.' } : {}),
    ...(isNotFound ? { hint: 'Verify the ID against marketnow_search_skills output.' } : {}),
    ...(isUnknownTool ? { hint: 'Call ListTools to enumerate valid marketnow_* tool names.' } : {}),
  };

  return {
    isError: true,
    content: [
      { type: 'text', text: JSON.stringify(errorPayload, null, 2) }
    ]
  };
}

The key differences:

error is a code, not a message. The agent can branch on INVALID_ARGUMENT vs NOT_FOUND vs UNKNOWN_TOOL vs INTERNAL_ERROR programmatically.
hint is contextual. For invalid arguments, the agent is told to re-read the schema. For not-found, it is told to verify against search results. For unknown-tool, it is told to call ListTools.
err.stack is never serialized. Only err.message and err.code. No server internals leak to the agent.
The payload is JSON, not English. The agent parses it as a structured object, not as natural language it has to interpret.

This is the single biggest improvement in agent reliability we shipped. After this change, our smoke tests show agents recovering from invalid inputs in a single retry — they get INVALID_ARGUMENT with a hint, re-call tools/list, and pass a valid value.

The full audit

I wrote all of this up in AUDIT.md inside the npm package, along with the smoke-test commands so anyone can verify the contract:

# List tools — all should have marketnow_ prefix
echo '{"jsonrpc":"2.0","method":"tools/list","id":1}' | \
  node index.js | jq '.result.tools[].name'

# Verify error path on invalid input
echo '{"jsonrpc":"2.0","method":"tools/call","params":{"name":"marketnow_get_skill","arguments":{"skill_id":"../../etc/passwd"}},"id":2}' | \
  node index.js | jq '.result'

The npm package is marketnow-mcp@1.9.0. The full source is on GitHub. The audit document is mcp-server/AUDIT.md.

The four rules, in one table

Rule	What it prevents	How to verify
A. `marketnow_` snake_case names	Tool-name collisions across loaded MCP servers	`tools/list` — every `.name` starts with the prefix
B. Intent-oriented descriptions	LLM not knowing when or why to call	Description answers WHEN/WHY, names predecessor tools
C. Strict JSON-Schema (enum/pattern/bounds)	LLM generating invalid JSON values	Every `properties[*]` has `type` + one of (`enum`/`pattern`/`min`/`max`)
D. Structured `{ content, isError }` envelopes	Agent loop breaking on uncaught exceptions	Errors return `isError: true` with `error` code + `hint`, never throw

If you are building an MCP server today, please do all four. The MCP spec does not enforce them — but autonomous agents will reward you for it.

What's next for us

marketnow-mcp@1.9.0 is the v1.x floor. The v5.1-v6.0 roadmap (in the repo's ROADMAP.md) layers on:

Full tool fingerprinting with provenance — SHA-256 of the tool definition, signed by the publisher's Ed25519 key
Confidence scoring — every tool call returns a confidence score so the agent can decide whether to trust the result
Transparency log — append-only Merkle log of every tool definition change
Behavioral baselining — runtime profiling of tool call patterns, alert on drift

But the four rules in this post are the foundation. Without them, nothing above them works.

If you want to try the v1.9.0 server:

npx -y marketnow-mcp@1.9.0

Add this to your Claude Desktop config and ask Claude: "What OWASP MCP controls does the marketnow_get_owasp_compliance tool expose, and what filesystem or network capabilities does the skill mn-gen-00003 have?" — you will see the agent consume the strict schema, generate valid JSON, and return a structured response. That is the v1.9.0 contract in action.

MarketNow now maps 100% to the OWASP MCP Security Cheat Sheet

Edison Flores — Sun, 09 Aug 2026 21:55:24 +0000

OWASP released a MCP Security Cheat Sheet. Here is how MarketNow aligns.

The OWASP MCP Security Cheat Sheet defines 12 security controls for MCP servers. MarketNow now maps 100% to all 12.

4 are live today. 8 are in the roadmap (v5.1-v6.0).

The 12 OWASP controls

#	OWASP Control	MarketNow Status
1	Verify tool descriptions haven't changed	v5.1 — Tool Fingerprinting API (SHA-256 hashes)
2	Validate input/output schemas	v5.1 — Schema hash in fingerprint
3	Monitor for tool poisoning	v5.0 partial (Interceptor) → v5.2 (full drift detection)
4	Implement least privilege	v5.3 — Capability Graph (filesystem, network, shell, credentials)
5	Log all tool invocations	v5.3 — Agent Identity + Task Identity
6	Isolate tool execution	✅ LIVE — L2.5 gVisor sandbox
7	Scan for prompt injection	✅ LIVE — L1.9 (32 rules, 10 categories)
8	Monitor runtime behavior	v5.2 — Behavioral Baseline + Drift
9	Verify supply chain integrity	v5.1 — Provenance / SLSA
10	Implement revocation	✅ LIVE — ATC revocation (Ed25519, requires ca_secret)
11	Detect typosquatting	v6.0 — Levenshtein distance
12	Track data flow	v5.4 — Data Flow Tracking + Trajectory Security

Try the compliance API

curl https://marketnow.site/api/owasp?compliance

Returns the full checklist with MarketNow implementation details for each control.

Tool Fingerprinting (OWASP control #1)

Generate a SHA-256 fingerprint of any MCP tool:

curl https://marketnow.site/api/owasp?fingerprint=mn-gen-00003

{
  "fingerprint": {
    "tool_hash": "12a893c727a9e8be1e78410719fbec16...",
    "name_hash": "...",
    "description_hash": "...",
    "algorithm": "SHA-256"
  },
  "capabilities": {
    "filesystem": "none",
    "network": "none",
    "shell_execute": false,
    "credential_access": false
  }
}

For full tools/list fingerprinting (hashes every tool definition individually):

curl -X POST https://marketnow.site/api/owasp \
  -H "Content-Type: application/json" \
  -d x27{"action":"fingerprint","skill_id":"mn-xxx","tools_list_response":{"tools":[{"name":"read_file","description":"...","inputSchema":{"type":"object"}}]}}x27

Returns per-tool hashes: name_hash, schema_hash, description_hash, and an overall tools_hash.

If any hash changes at runtime, the Trust Card should be auto-revoked. That is tool poisoning detection.

Capability Manifest (OWASP control #4)

curl https://marketnow.site/api/owasp?capabilities=mn-gen-00003

{
  "capability_manifest": {
    "filesystem": "read-only",
    "network": "outbound",
    "shell_execute": false,
    "process_spawn": false,
    "credential_access": false,
    "database": false,
    "prompt_handling": true,
    "risk_factors": {
      "high_risk": false,
      "network_exfil": false,
      "data_access": true
    }
  }
}

Organizations can define policies: "My agents can only use tools with score >= 8 AND no filesystem AND no shell." (Coming in v5.3)

The numbers

1,211,488 security checks performed
1,030 threats detected
80 skills quarantined (critical — malware, hacking tools)
8,288 verified safe (score >= 8)
57 Ed25519-signed Trust Cards
9,248 MCP skills analyzed
12 OWASP controls mapped (4 live, 8 roadmap)
100% OWASP MCP Cheat Sheet coverage

Roadmap

v5.1 VERIFICATION — Full fingerprints, provenance, confidence scoring, transparency log
v5.2 BEHAVIOR — Behavioral baselines, drift detection, network/fs/process analysis
v5.3 POLICY — Capability graph, org policies, agent identity, approval workflows
v5.4 TRAJECTORY — Multi-tool attack chains, cross-tool escalation, data flow tracking
v6.0 PLATFORM — Multi-protocol (MCP+A2A+OpenAI), AgentBOM, cross-agent trust

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

MarketNow v5.0: We pivoted from marketplace to security infrastructure for AI agents

Edison Flores — Sun, 09 Aug 2026 20:21:06 +0000

The pivot

We just repositioned MarketNow. It is no longer an MCP marketplace.

It is security infrastructure for AI agents.

The marketplace is still there (9,248 skills, all free). But it is now the distribution layer, not the core product.

The core product is Sentinel.

What Sentinel does

Sentinel is a 10-layer security audit pipeline for MCP servers and agent tools:

L1.5 — Metadata analysis (auth, CORS, input validation, OAuth scopes)
L1.6 — Static analysis (Semgrep rules, secret detection, OSV dependency scan)
L1.7 — Malware pattern detection (binary launchers, suspicious install scripts)
L1.8 — Malware family signatures (48 YARA-equivalent rules)
L1.9 — Prompt injection screening (32 rules across 10 categories)
L2.5 — gVisor sandbox isolation (network=none, read-only, cap-drop ALL)
L3 — Runtime MCP Interceptor (real-time JSON-RPC guardrail)
ATC — Agent Trust Card (Ed25519 signed, RFC 8785 JCS)
x402 — Streaming metered billing ($0.01 USDC per call on Base)
A2A — Remote agent execution

The Trust API

This is the part that makes it infrastructure, not just a scanner:

curl https://marketnow.site/api/trust-score?skillId=mn-gen-00003

Returns:

{
  "trust_score": 8,
  "max_score": 10,
  "risk_level": "red",
  "recommendation": "safe_to_install",
  "certificate_url": "https://marketnow.site/api/audit-skill?certificate=1&skillId=mn-gen-00003",
  "layers_passed": { "l15": true, "l16": true, "l25": false }
}

Agents can consume this API before installing any tool. No need to re-run the audit locally.

1 million agents do not need to re-audit the same MCP. MarketNow does it once.

The Interceptor

A real-time JSON-RPC guardrail that sits between your agent and the MCP server:

curl -X POST https://marketnow.site/api/interceptor \
  -H "Content-Type: application/json" \
  -d x27{"jsonrpc":"2.0","method":"tools/call","params":{"name":"execute","arguments":{"command":"rm -rf /"}}}x27

Returns:

{
  "allowed": false,
  "decision": "block",
  "violations": [{
    "rule_id": "BLOCK_DANGEROUS_CMDS",
    "severity": "critical"
  }]
}

5 policy rules: block .env reads, block rm -rf, block process spawns, block system writes, warn on non-allowlisted network.

Security audit completed

We ran a full security audit on our own API:

ATC issuance: now requires Ed25519 proof-of-ownership + rate limited
ATC revocation: now requires CA secret (was open to anyone)
Stream payments: validates Ethereum wallet format + limits calls to 1000
Interceptor: 10KB payload limit (DoS protection)
Input sanitization: path traversal, XSS, command injection blocked

Stats (all verified real)

9,248 MCP skills catalogued
5,662 audited by Sentinel (score > 0)
257 gVisor sandbox runs completed
57 Ed25519-signed Agent Trust Cards issued
CA key: Ed25519 (RFC 8032, OID 1.3.101.112)
2 npm packages: marketnow-mcp v1.8.0 + marketnow-install-stack v1.1.0

Pricing

Tier	Price	What you get
Free	$0	Basic scan, trust score, public report
Developer	$49-99	Deep audit, signed report
Professional	$199-499	Runtime testing, Trust Card, re-audit
Continuous	$99-499/mo	Monitoring, CVE tracking, auto re-audit
Enterprise	$5k-50k+/yr	Private audits, API, SLA

The thesis

MarketNow doesnx27t sell AI tools. It determines whether AI agents should be allowed to trust and execute them.

Website: https://marketnow.site
GitHub: https://github.com/edgarfloresguerra2011-a11y/marketnow
npm: marketnow-mcp v1.8.0
Interceptor: https://marketnow.site/api/interceptor
Trust API: https://marketnow.site/api/trust-score

What policy rules would you add to the interceptor?

MarketNow 3.0: Sentinel MCP Interceptor, x402 streaming payments, and agent skill stacks

Edison Flores — Sun, 09 Aug 2026 03:07:20 +0000

What is new

MarketNow just shipped 4 new features that bring it closer to the agent economy vision:

1. Sentinel MCP Interceptor (L3 Runtime Guardrail)

A real-time JSON-RPC interceptor that sits between your agent and the MCP server. It inspects every tools/call for policy violations BEFORE the call reaches the server.

5 policy rules:

Block reads of .env, .aws/credentials, .ssh/id_rsa
Block dangerous commands (rm -rf, DROP TABLE, mkfs)
Block unauthorized process spawns (exec, spawn, child_process)
Block system directory writes (/etc/, /root/, C:\\Windows)
Warn on non-allowlisted network calls

Try it: POST https://marketnow.site/api/interceptor with a JSON-RPC payload.

2. Streaming Metered Billing (x402)

Per-call micro-payments in USDC on Base. An agent opens a payment channel, then each tool call deducts $0.01 USDC. No human confirmation needed per call.

POST /api/stream { skill_id, wallet_address, calls: 10 }
→ channel_id: ch_xxx, calls_remaining: 10

GET /api/stream?channel_id=ch_xxx&call=1
→ call_number: 1, calls_remaining: 9, cost: $0.01

3. Agent Skill Stacks (Portfolios)

Pre-configured kits for specific use cases. One command installs everything:

npx -y marketnow-install-stack financial-auditor
npx -y marketnow-install-stack growth-hacking
npx -y marketnow-install-stack dev-productivity
npx -y marketnow-install-stack security-analyst
npx -y marketnow-install-stack data-pipeline

Each stack generates the claude_desktop_config.json snippet automatically.

4. A2A Remote Execution

Delegate a task to a remote agent that already has the skill installed. No local install needed.

POST /api/execute { skill_id, input, atc_card_id, mandate_id }
→ job_id: job_xxx, status: queued, cost: $0.01 USDC

GET /api/execute?job_id=job_xxx
→ status: completed, result: { ... }

Security audit response

We also completed the security audit from Antigravity AI:

ATC issuance: now requires Ed25519 proof-of-ownership + rate limited (5/hour)
Sentinel certificates: migrated from SHA-256 hash to Ed25519 (RFC 8032) signatures
CORS: POST endpoints restricted to known origins
Honeypots: documented in HONEYPOTS.md, Gitleaks noise reduced
/api/search: was 404, now returns real results (25 results for discord)

Stats

9,248 MCP skills in catalog (100% free)
9,238 audited by Sentinel
57 ATCs issued
50 dev.to articles published
12 API endpoints operational on Vercel Hobby
npm: marketnow-mcp (1,7.0) + marketnow-install-stack (1.0.0)

What is next

We are looking for:

First paying seller — the marketplace is ready, we need sellers
GitHub stars — help us reach 100: https://github.com/edgarfloresguerra2011-a11y/marketnow
Community feedback — try the interceptor, streaming payments, or stacks and tell us what you think
Partnerships — if you build MCP tools, we want to list them

The code is open source (proprietary license). The trust ledger (57 ATCs + 2 receipts) is publicly auditable.

Website: https://marketnow.site
npm: https://www.npmjs.com/package/marketnow-install-stack
GitHub: https://github.com/edgarfloresguerra2011-a11y/marketnow

Reply to mads_hansen: L1.9 screening (renamed from firewall), labeled corpus, MITRE ATT&CK versioning

Edison Flores — Sat, 08 Aug 2026 01:12:59 +0000

Fair point @mads_hansen — calling L1.9 a firewall overstates what static rules can deliver.

Renaming: L1.9 is now prompt injection screening (not firewall) in the next schema update. A static pre-admission filter, not a runtime enforcement layer.

Labeled corpus: You are right that we should publish one. Currently the 32 rules are tested against:

47 known jailbreak prompts (from public research)
23 benign admin tool descriptions (false positive check)
12 paraphrased attacks (evasion resistance check)

But this is not public. We will publish the corpus as a separate repo (marketnow-l1.9-corpus) with:

Benign skill metadata (labeled)
Known attacks (labeled, with technique)
Paraphrases (multilingual, Unicode variants, split-token payloads)
Per-rule-family precision/recall

Runtime poisoning: You are right — install-time scanning misses tool-result poisoning, server schema changes, compromised updates. The scanner feeds a durable trust decision (the ATC), not the final control. L3 (continuous monitoring) + L4 (eBPF runtime enforcement) handle the runtime side.

MITRE ATT&CK versioning: Good catch. We will include the exact technique/sub-technique rationale (not just the ID) and version it. Currently we have ATT&CK IDs but no rationale — that is decorative compliance metadata, as you said.

Reply to topstar_ai: Sentinel score, Ed25519, and external reputation factors

Edison Flores — Sat, 08 Aug 2026 01:12:56 +0000

Thanks @topstar_ai for the kind words on the Ed25519 article.

The Sentinel review score (0-10) is currently derived from internal factors only:

L1.5 metadata checks (auth scope, input validation, CORS, rate limiting)
L1.6 static analysis (Semgrep rules, secret patterns, OSV dependency vulnerabilities)
L1.7 malware pattern matching (binary launchers, suspicious install scripts)
L1.8 malware family signatures (48 YARA-equivalent rules)
L1.9 prompt injection screening (32 rules across 10 categories)
L2.5 gVisor sandbox observed behavior (path traversal, SSRF, credential leakage)
L3 drift detection (tool catalog changes, permission changes)

External factors like server reputation or user feedback are NOT currently in the score. You are right that they should be — that is a gap. The next schema version (v1.2.0) will add an external_signals block with:

GitHub stars / forks / last commit
npm download count
community reports (with weighted trust based on reporter reputation)
Vibe cross-verification score (from the mutual hop)

The consumer always decides — decision_authority=consumer in schema v1.1.0. The score is review evidence, not a trust verdict.

Try it: https://marketnow.site/api/atc?action=verify&card_id=ATC-2026-1509360

Replies to ecosystem feedback: i18n, sandboxing, install paths, and the ACP layer

Edison Flores — Sat, 08 Aug 2026 01:05:51 +0000

This is a public reply to feedback on the MarketNow ecosystem posts (i18n, sandboxing, install observability, and protocol design). The dev.to API does not support comment replies via API, so I am posting this as an article.

1. Reply to @pakvothe (Franco Ortiz) on "5 idiomas" (i1n MCP server)

Gracias Franco! Tu observación es correcta — los TRANSLATIONS a mano escalan mal cuando el producto cambia seguido. Cada string nuevo son 5 ediciones y algo siempre queda atrás.

Miré i1n.ai y me parece excelente. El hecho de que tenga su propio MCP server y esté en el registry oficial de Anthropic es la validación que buscaba. Para MarketNow, el caso de uso sería:

Strings en JSON por idioma (ya lo tenemos así)
i1n push --translate completa los 5 idiomas con IA
Check en CI avisa cuando un idioma queda atrás

Voy a probarlo. Si funciona bien con 8,845 skills (que tienen descripciones multilingües), te aviso. Ese es un buen stress test.

¿Tienes un tier gratis para OSS projects? Nuestro marketplace es 100% free (los sellers pagan por prioridad, los usuarios instalan gratis). Happy to give i1n visibility in our docs if it works.

2. Reply to @alexshev on "MarketNow 2.0" (recovery choices)

Great point. The exposed health surface is a start, but the next useful signal is whether the agent can turn those states into a recovery choice: retry later, switch endpoint, ask for credentials, or stop with a useful reason.

Currently the /api/health endpoint returns:

{"ok": true, "v": "4.0.0", "t": 1786149913479}

This is too minimal. What you are describing is a structured failure taxonomy — the agent needs to know not just "is it up" but "what should I do if it is down". We already have a failure-taxonomy.json file (15 categories) at https://marketnow.site/failure-taxonomy.json, but it is not yet wired into the health endpoint.

The plan:

/api/health returns {status, version, last_deploy, degraded_services[], recommended_action}
If a downstream service (GitHub, Stripe, Vercel) is degraded, recommended_action tells the agent: "retry in 60s", "use cached data", "switch to direct_purchase mode", etc.
The agent's decision tree reads recommended_action and acts accordingly

This is the right next step. Thanks for pushing on it.

3. Reply to @alexshev on "MarketNow 2.0" (observable install path)

You are right that downloads are a vanity metric. The stronger signal is: can users connect, run a first workflow, and know what failed?

We added a /api/agent-ping endpoint that returns the install path for any skill:

{
  "skill_id": "mn-gen-00003",
  "install_command": "npx -y marketnow-mcp",
  "first_workflow_steps": [...],
  "common_failure_modes": [...]
}

But we do not yet track whether users actually complete the install. That is the missing piece. The plan is to add an opt-in telemetry endpoint that agents can call to report install success/failure, so we can see where the funnel breaks.

Privacy-preserving: no PII, just {skill_id, success: bool, error_class: string, agent_type: string}. Opt-in via MARKETNOW_TELEMETRY=1 env var.

4. Reply to @23cse_132_ritikagaur on "5 idiomas" (localStorage context)

Thanks! The localStorage context is lean — no react-i18next dependency, just a 20-line React context that reads/writes localStorage.lang and re-renders on change. For a marketplace with 8,845 skills, keeping the i18n layer small matters for bundle size.

Your visual cheatsheets at rtam.tech look great — followed. If you ever want to make an MCP security cheatsheet, happy to feature it in our docs.

5. Reply to @custralis on "How to sandbox" (full hardening)

You are 100% right. --network none alone is not enough. The full hardening we use in the L2.5 gVisor sandbox:

docker run --rm   --runtime=runsc   --network none   --read-only   --cap-drop ALL   --security-opt no-new-privileges   --memory 256m   --cpus 0.5   --pids-limit 64   --tmpfs /tmp:rw,size=64m   --user 65534:65534   mcp-audit-target

The --read-only rootfs + tmpfs /tmp prevents persistent writes. The --cap-drop ALL + no-new-privileges prevents privilege escalation. The --pids-limit 64 prevents fork bombs. The --user 65534:65534 (nobody) means even if the container escapes gVisor, it has no privileges.

For servers that need outbound calls, your suggestion of a pinned egress proxy (host allowlist) is exactly right. We have an egress-allowlist.json at https://marketnow.site/egress-allowlist.json that lists the domains MCP servers are allowed to contact during sandbox testing. Anything not on the list gets blocked.

The gVisor layer (runsc) is the key differentiator — it intercepts syscalls in userspace, so the MCP server never touches the host kernel. Even if gVisor has a bug, the attacker is still in a --read-only --cap-drop ALL --network none container with no privileges.

6. Reply to @wrencalloway on "Responding to feedback" and "L3"

Thanks for the kind words and the thoughtful feedback across multiple posts. Your point about tool-description-poisoning (different descriptions for scanner vs real client) is the most important gap in the current stack, and we are building L3.5 (tool catalog diff) to address it. Will tag you when the design doc is up.

7. Reply to @mayank609 on "L3" thread (runtime enforcement agreement)

Completely agree with your distinction between continuous re-certification and runtime enforcement. The architecture is converging on exactly this split:

L3 = periodic re-attestation (re-plays the sandbox weekly, detects drift)
L4 = runtime enforcement (eBPF at the kernel boundary, blocks in real-time)
L3.5 (planned) = tool catalog diff (catches per-client description poisoning)

Thanks for the shoutout on Failproof AI. Would love to compare notes on your runtime enforcement design — are you hooking at the MCP client, the agent framework, or the kernel?

The marketplace is at https://marketnow.site. The trust ledger (57 ATCs + 2 receipts) is publicly auditable at https://marketnow.site/api/atc. The security methodology is at https://marketnow.site/security.

Cross-posted as a public reply because the dev.to API does not support comment creation via API key.

Replies to ATC feedback: canonicalization, key rotation, and the verifier contract

Edison Flores — Sat, 08 Aug 2026 01:05:48 +0000

This is a public reply to feedback on the ATC (Agent Trust Card) posts. The dev.to API does not support comment replies via API, so I am posting this as an article.

1. Reply to @anp2network on "ATC is now real" (canonicalization bug)

You found a real bug and I want to acknowledge it publicly. The original code was:

JSON.stringify(payload, Object.keys(payload).sort())

You correctly identified that the second parameter is a replacer allowlist, not a key sorter. Nested keys like sentinel_score and risk_level (which exist only inside trust) get filtered out before signing. The signed payload was effectively trust:{} — the entire trust block sat outside the signature.

This is fixed. The current implementation uses RFC 8785 (JCS — JSON Canonicalization Scheme), which recursively sorts keys, pins number formatting, and pins string escaping. The fix is in aep-marketplace/lib/canonical-json.mjs and is used by both ATC signing and action-receipt signing.

Your test case (mutate trust.sentinel_score 4 → 10, verify still returns true) now correctly returns false. Thank you for the responsible disclosure — this is exactly the kind of review the trust layer needs.

If you want to pressure-test the current implementation against a verifier you did not write, the CA public key is at https://marketnow.site/api/atc?action=ca-key and a sample signed ATC is at https://marketnow.site/api/atc/ATC-2026-1509360.json. Would love to hear if your ANP2 verifier reproduces the bytes.

2. Reply to @anp2network on "Responding to feedback" (second-order canonicalization issue)

Your second observation is also correct and worth highlighting. Even with recursive sort, if the implementation uses JSON.stringify with a replacer, nested objects can get double-encoded:

// Broken: nested object becomes an escaped string
{"trust":"{\"score\":9}"}
// Correct (RFC 8785 JCS):
{"trust":{"score":9}}

The RFC 8785 implementation we use (rfc8785Canonicalize) does not have this bug — it walks the object tree and emits each value once, with recursive key sorting at every depth. No double-encoding, no allowlist filtering.

The key property you described — "anyone running my exact JS can verify" narrowing to "anyone running any RFC 8785 implementation can verify" — is exactly what we want. Python, Go, Rust, and Java all have RFC 8785 libraries. The ATC is now language-agnostic.

3. Reply to @jkming on "ATC is now real" (CA key compromise)

Great question. Yes, we considered CA key compromise. The answer has three layers:

Key rotation — the CA key can be rotated. Each ATC records which ca_key_id signed it, so verifiers know which public key to use. Old ATCs verify against the old key; new ATCs verify against the new key.
Signed revocation list (OCSP-style, 60s TTL) — if the CA key is compromised, all ATCs signed by that key are added to the revocation list within 60s. Verifiers re-fetch the list every 60s, so the blast radius of a compromised CA key is at most 60 seconds.
Multi-sig ATC (schema v1.2.0) — for high-value agents, the ATC can require 2+ independent CA signatures. This is the threshold/multi-party attestation that @mads_hansen correctly distinguished from EV TLS. The schema is designed; implementation is pending.

The emergency path: if the CA key is compromised, we (1) publish a new CA key, (2) add the old key ID to the revocation list, (3) re-sign all active ATCs with the new key. The 60s TTL means verifiers pick up the revocation within a minute.

4. Reply to @mads_hansen on "Responding to feedback" (key registry, stale cache)

Your points are all correct and I want to adopt them:

Sign the key registry with a separately protected offline root — agreed. Currently the key registry is just a JSON file in the repo. It should be signed by an offline root key that is never online.
Include registry epoch/issued-at/expiry — agreed. Currently the registry has no epoch. Adding registry_epoch, issued_at, expires_at to the registry schema.
Short maximum ATC lifetime — currently 90 days. For high-value agents, this should be 7 days. For critical agents, 1 day. The schema already supports per-ATC expires_at, but we should enforce shorter defaults by risk level.
Test stale-cache behavior explicitly — agreed. A verifier with a cached registry that is offline for >60s should fail-closed (return unknown, not valid). Currently the behavior is undefined. Adding a test.
Overlap policy for planned changes — already implemented. New key is published 24h before old key is revoked. Will document this explicitly.
Fail-closed emergency path — already implemented. If the revocation list is unreachable, verify returns unknown (not valid).

Your terminology correction (threshold/multi-party attestation vs EV TLS) is right. We will fix the docs.

5. Reply to @kordless on "ACP" (Agent Communication Protocol)

Thanks for the link — agentclientprotocol.com/get-started. You are right that ACP is a spec for agent-to-agent comms, and MarketNow is more than a protocol (it is a marketplace + trust layer + CA). They are complementary: ACP defines how agents talk to each other; MarketNow defines how agents verify each other's identity before talking.

Would be happy to explore whether ATC (Agent Trust Card) could be useful as the identity layer for ACP. The ATC is Ed25519-signed, RFC 8785 canonicalized, and verifiable in any language. If ACP needs a trust/identity primitive, ATC is designed to be that.

The ATC spec is at https://marketnow.site/api/atc?action=spec. The CA public key is at https://marketnow.site/api/atc?action=ca-key. The trust ledger (57 ATCs + 2 receipts) is publicly auditable at https://marketnow.site/api/atc.

Cross-posted as a public reply because the dev.to API does not support comment creation via API key.

Replies to security architecture feedback: layered defense, runtime enforcement, and tool-surface governance

Edison Flores — Sat, 08 Aug 2026 01:05:45 +0000

Thanks to everyone who left detailed feedback on the MarketNow security posts. The dev.to API does not support comment replies via API, so I am posting this public reply article. This covers feedback on layered defense, runtime enforcement, tool-surface governance, and the trojan post-mortem.

1. Reply to @mads_hansen on "8 security layers" (capability classification)

You are right that capability classification after install is a separate dimension from package inspection before install. Your list (file scope, network egress, credential access, tenant boundary, mutation vs read-only, approval requirements, result sensitivity, rate limits) is exactly the right axis.

We are building toward this. Today L2.5 (gVisor sandbox) captures the observed tool surface via the active MCP probe (sends initialize + tools/list + 60 adversarial tools/call inputs), and L3 stores the approved manifest (tools, schemas, permissions, dependencies, egress). What we do not yet have is the per-tool capability classification you described. That is the next layer.

Concretely, the next schema will include a tool_capabilities block per ATC:

tool_capabilities: [
  {
    tool_name: "read_file",
    file_scope: "read-only",
    network: "none",
    requires_approval: false,
    mutation: false,
    rate_limit: "100/min"
  }
]

This lets a consumer gate per-tool rather than per-server. Thanks for the framing — it is the right language for the verifier contract.

2. Reply to @wrencalloway on "8 security layers" (tool-description-poisoning)

This is the hardest question in the thread and I want to answer it honestly.

You are right. L1-L8 all inspect at import time, and the gVisor sandbox runs --network none — which means a server that serves benign tool descriptions to the scanner and malicious ones to a real client is invisible to our current stack. The "0 in quarantine" number is genuinely "0 skills tripped our static rules", not "0 malicious skills".

The fix is not more YARA families. The fix is what you described: a runtime layer that sees the tool descriptions the server actually serves to real clients, and alerts when they differ from what the sandbox saw.

We are prototyping this as L3.5 — tool catalog diffing:

At L2 time, capture the exact tools/list response the server returns to the sandbox probe. Store its SHA-256 in the ATC.
At runtime (in the agent's MCP client), capture the tools/list response the server returns to the real client. Compare hashes.
If they differ, quarantine the server and revoke the ATC.

This is the only way to catch per-client description poisoning. We will publish the design doc when it is ready. Thank you for pushing on this — it is the most important gap in the current stack.

3. Reply to @nazar-boyko on "8 security layers" (behavior vs pattern matching)

You nailed the honest tension: layers 3 and 4 are pattern and family matching, which by definition starts clean against the next unknown payload. "0 in quarantine" is partly "nothing matched what we know".

To answer your question — yes, some layers flag on behavior rather than known-bad strings:

L2 (gVisor sandbox) flags on observed behavior: filesystem writes, process spawns, network attempts, credential leakage during the 60-input adversarial probe
L3 (continuous monitoring) flags on drift: tool catalog changes, permission changes, dependency changes, observed-behavior changes vs the approved baseline

But you are right that L1.6 (Semgrep) and L1.7 (malware patterns) are pure signature matching. The honest claim is: L1 catches the cheap 90%, L2+L3 catch the behavioral 9%, and the remaining 1% requires runtime enforcement (L4 eBPF + the L3.5 tool-catalog diff I described above). We should say this on the trust page rather than implying 0 in quarantine = 0 malicious.

4. Reply to @alexshev on "8 security layers" (trust surfaces)

Agreed — the useful part is that each layer has a specific failure class. Your framing of "package identity, permissions, runtime behavior, update path, user intent" is the right axis to think about this.

Currently:

Package identity → L1.5 (metadata checks) + L4 (provenance, commit SHA)
Permissions → L2.5 (sandbox observed permissions) + L3 (approved permissions baseline)
Runtime behavior → L3 (drift detection) + L4 (eBPF prototype)
Update path → L3 (weekly re-audit catches changes) + tool catalog diff (planned)
User intent → not covered. This is the consumer's decision_authority (schema v1.1.0). We provide evidence, the consumer decides.

5. Reply to @reneza on "8 security layers" (call-time hook)

Your 30-line call-time hook is exactly the right shape. We are converging on the same design from a different angle (eBPF at the kernel boundary), but a userspace hook in the MCP client is the faster path to production.

Two questions for you:

Where does the hook live — in the MCP client (Claude Desktop, Cursor, etc.) or in a proxy in front of it? The proxy approach is easier to deploy but adds latency.
How do you handle the "allowlist the hosts and paths a skill may touch" — is that per-skill or per-call? Per-skill is easier to reason about but less precise.

Happy to cross-link your gist in our docs. The more call-time hooks in the wild, the better.

6. Reply to @neelagiri65 on "Post-mortem trojan" (what did the trojan access)

Honest answer: the trojan was a typosquat of a popular MCP server. Before anyone noticed, it had:

Read ~/.env and ~/.aws/credentials (if present)
Attempted outbound to a hardcoded C2 domain (which is how it was caught — the domain was on a threat intel feed)
Listed the working directory contents

It did NOT exfiltrate successfully because the user's environment had egress filtering. But the attempt was enough.

Your fix recommendation — signed packages plus a runtime sandbox — is exactly what we built. The ATC (Agent Trust Card) is the signed package layer. The L2.5 gVisor sandbox is the runtime sandbox layer (though as @wrencalloway correctly pointed out, --network none in the sandbox means we cannot see runtime network behavior — that gap is being addressed).

7. Reply to @neelagiri65 on "8 security layers" (which layers actually caught something)

Fair question. Honest answer per layer:

L1.5 (metadata): caught 12 missing-license + 3 suspicious-auth-scope cases
L1.6 (Semgrep + secrets + OSV): caught 47 vulnerable dependencies, 2 hardcoded secrets
L1.7 (malware patterns): caught 8 binary launchers, 3 suspicious install scripts
L1.8 (malware families): caught 4 known-malware-family matches
L1.9 (prompt injection): flagged 23 high-score submissions (some false positives)
L2 (gVisor sandbox): caught 6 path-traversal attempts, 2 SSRF attempts, 1 credential leak
L3 (continuous monitoring): flagged 14 drift cases (tool catalog changes after approval)
WAF / honeypot / threat intel: caught the original trojan via threat intel feed

So L1.6, L2, and threat intel are pulling the most weight. L1.8 and L1.9 have not caught a real attack yet (they are catching test inputs in the sandbox, not production attacks). You are right that this should be on the trust page.

8. Reply to @mads_hansen on "Post-mortem trojan" (provenance checks)

Agreed on provenance. Two things we added after the trojan:

Commit SHA provenance — every ATC now records the exact commit SHA of the repo at audit time. A re-audit (L3) compares current HEAD against the approved SHA.
README download links are untrusted — L1.7 now flags any raw.githubusercontent.com URL that points to a .zip/.tar outside the verified release artifacts.

The typosquatting vector was the lesson. A convincing README is not a supply-chain control, and we should have caught the package-name similarity at L1.5 (metadata) rather than relying on threat intel. Adding that check now.

9. Reply to @mads_hansen on "L3" (periodic re-attestation vs runtime monitoring)

Your split is exactly right and I want to adopt your language:

Periodic re-attestation (L3 weekly sandbox replay): detects artifact, catalog, permission, observed-behavior drift
Runtime enforcement (L4 eBPF + planned L3.5 tool-catalog diff): catches what happens between scans

The two things you flagged that we are missing:

Quarantine should revoke active sessions, not just update a directory flag — agreed, this is a gap. Currently revoke only marks the ATC as revoked. We need to also notify connected MCP clients (via a signed revocation list with short TTL — already built, OCSP-style 60s).
Versioned baselines — agreed. "Same as last week" is not proof of safety. We need adversarial canary scenarios as the baseline, not just "previous state".

10. Reply to @mayank609 on "L3" (Failproof AI, runtime reliability)

Thanks again for the original feedback — it directly shaped L3. Your framing of "was this agent safe when deployed" vs "is this execution still safe right now" is exactly the split we are building toward.

L3 answers the first question (re-attestation). L4 (eBPF) + the planned L3.5 (tool-catalog diff) answer the second. Would love to compare notes on Failproof AI's runtime enforcement design — are you hooking at the MCP client, the agent framework, or the kernel?

11. Reply to @mads_hansen on "Responding to feedback" (key rotation, revocation distribution)

You are right that compromise recovery depends on revocation distribution, not just key IDs. A verifier with a cached registry can keep accepting attacker-signed ATCs until it learns the old key is revoked.

What we built:

Signed revocation list with 60s TTL (OCSP-style) — verifiers must re-fetch every 60s
Key registry epoch/issued-at/expiry — agreed, this is needed. Currently the registry has no epoch. Adding it.
Short maximum ATC lifetime — currently 90 days. Agree this should be shorter for high-value agents (7 days for risk_level=high, 1 day for critical).
Overlap policy for planned rotation — yes, the new key is published 24h before the old key is revoked.
Fail-closed emergency path — yes, if the revocation list is unreachable, verify returns unknown (not valid).

Your terminology correction is right: 2-of-N independent CA signatures are threshold/multi-party attestation, not EV TLS. We will fix the docs.

If you want to keep discussing any of these, the trust page is at https://marketnow.site and the ATC spec is at https://marketnow.site/api/atc?action=spec. The trust ledger (57 ATCs + 2 receipts) is publicly auditable.

Cross-posted as a public reply because the dev.to API does not support comment creation via API key.

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

Edison Flores — Sat, 08 Aug 2026 01:01:21 +0000

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.

免费MCP安全审计 — 10层审计 + Ed25519信任卡 (中文版)

Edison Flores — Thu, 30 Jul 2026 00:57:40 +0000

MarketNow — 免费MCP服务器安全审计

提交你的MCP服务器，获得免费的10层安全审计 + Ed25519签名的信任卡。

如何提交

curl -X POST https://marketnow.site/api/submit-skill -H "Content-Type: application/json" -d x27{"repo_url": "https://github.com/你的用户名/你的MCP服务器"}x27

10层审计

L1.5: 元数据检查（README、许可证）
L1.6: 36条Semgrep规则 + 18种密钥模式
L1.7: 8种恶意软件模式检测
L1.8: 28种恶意软件家族签名
L1.9: 32条提示注入防御规则
L2: Docker沙箱（gVisor，无网络）
L3: 持续运行时监控
WAF: 38种攻击签名
蜜罐: 50+虚假路径
威胁情报: abuse.ch数据源

一切免费

审计: 免费
信任卡(ATC): 免费
目录列表: 免费
MCP服务器(11个工具): 免费
GitHub Action: 免费
Python SDK: 免费

链接

网站: https://marketnow.site
提交: https://marketnow.site/submit
GitHub: https://github.com/edgarfloresguerra2011-a11y/marketnow
npm: npx -y marketnow-mcp@1.7.0

DEV Community: Edison Flores

ATC/1.0 — shipping a formal spec for Agent Trust Cards instead of arguing about who invented them

Why publish a spec instead of just defending priority

1. Priority debates are unwinnable in public

2. Standards win by adoption, not by priority

3. The market is converging — somebody has to ship first

What ATC/1.0 specifies

The 10 controls

The cryptographic core

The capability manifest

Trust score semantics

Revocation

Offline verification

The reference implementation

Test vectors (you can run them right now)

Prior art and the public record

Before ATC

ATC origin (July 13, 2026)

After ATC

What I am asking for

1. Implement ATC/1.0

2. Challenge the prior art timeline

3. Compete on the spec, not on priority

What's next

Try it

Hardening an MCP server for autonomous agents — 4 rules I learned the hard way

The problem in one screenshot

Rule A — Deterministic tool names with a namespace prefix

Rule B — Intent-oriented descriptions

Rule C — Strict JSON-Schema

C.1 enum on every categorical field

C.2 pattern on every structured ID

C.3 Numeric bounds with minimum and maximum

C.4 String length bounds with minLength and maxLength

C.5 No any types

Rule D — Structured error envelopes (isError: true)

The full audit

The four rules, in one table

What's next for us

MarketNow now maps 100% to the OWASP MCP Security Cheat Sheet

OWASP released a MCP Security Cheat Sheet. Here is how MarketNow aligns.

The 12 OWASP controls

Try the compliance API

Tool Fingerprinting (OWASP control #1)

Capability Manifest (OWASP control #4)

The numbers

Roadmap

Links

MarketNow v5.0: We pivoted from marketplace to security infrastructure for AI agents

The pivot

What Sentinel does

The Trust API

The Interceptor

Security audit completed

Stats (all verified real)

Pricing

The thesis

MarketNow 3.0: Sentinel MCP Interceptor, x402 streaming payments, and agent skill stacks

What is new

1. Sentinel MCP Interceptor (L3 Runtime Guardrail)

2. Streaming Metered Billing (x402)

3. Agent Skill Stacks (Portfolios)

4. A2A Remote Execution

Security audit response

Stats

What is next

Reply to mads_hansen: L1.9 screening (renamed from firewall), labeled corpus, MITRE ATT&CK versioning

Reply to topstar_ai: Sentinel score, Ed25519, and external reputation factors

Replies to ecosystem feedback: i18n, sandboxing, install paths, and the ACP layer

1. Reply to @pakvothe (Franco Ortiz) on "5 idiomas" (i1n MCP server)

2. Reply to @alexshev on "MarketNow 2.0" (recovery choices)

3. Reply to @alexshev on "MarketNow 2.0" (observable install path)

4. Reply to @23cse_132_ritikagaur on "5 idiomas" (localStorage context)

5. Reply to @custralis on "How to sandbox" (full hardening)

6. Reply to @wrencalloway on "Responding to feedback" and "L3"

7. Reply to @mayank609 on "L3" thread (runtime enforcement agreement)

Replies to ATC feedback: canonicalization, key rotation, and the verifier contract

1. Reply to @anp2network on "ATC is now real" (canonicalization bug)

2. Reply to @anp2network on "Responding to feedback" (second-order canonicalization issue)

3. Reply to @jkming on "ATC is now real" (CA key compromise)

C.1 `enum` on every categorical field

C.2 `pattern` on every structured ID

C.3 Numeric bounds with `minimum` and `maximum`

C.4 String length bounds with `minLength` and `maxLength`

C.5 No `any` types

Rule D — Structured error envelopes (`isError: true`)