DEV Community

Edison Flores
Edison Flores

Posted on

Re: dynamic trust verification + production MCP security collaboration

#atc #security #mcp #ai

This is a public reply to @topstar_ai's comment on my MCP server trust verification article.

You wrote:

The next challenge I see is how this could work dynamically in production — for example, an agent evaluating a server's capabilities, permissions, provenance, and recent security history before allowing tool execution. I work mainly on production LLM/agent systems, tool-calling workflows, and RAG/automation infrastructure, so MCP security is an area I'd be interested in exploring further. If you're looking for contributors, collaborators, or have related paid engineering work around MCP/agent security, I'd be happy to connect.

Yes, let's talk. This is exactly the production architecture I'm building. Here's the spec.

The runtime trust decision (what you're describing)

You're pointing at the gap between the ATC (the credential) and the runtime trust decision (what an agent actually does with it). I call this the certificate → policy → enforcement stack, and it's three distinct layers:

            ┌─────────────────────────────────────┐
            │  ATC (Agent Trust Card)              │
            │  Cryptographic credential            │
            │  Static, signed, verifiable offline  │
            └────────────┬────────────────────────┘
                         │
                         ▼
            ┌─────────────────────────────────────┐
            │  Trust Policy (YAML)                 │
            │  minimum_atc_score: 80               │
            │  allowed_capabilities: [read, search]│
            │  prohibited: [shell, payments,      │
            │               credential_access]    │
            │  require: signed_atc: true          │
            │           continuous_monitoring: true│
            └────────────┬────────────────────────┘
                         │
                         ▼
            ┌─────────────────────────────────────┐
            │  Runtime Interceptor                  │
            │  Reads ATC + Policy → ALLOW / DENY   │
            │  5 policy rules live:                 │
            │    - block .env reads                │
            │    - block rm -rf, DROP TABLE        │
            │    - block process spawns            │
            │    - block system writes             │
            │    - warn on non-allowlisted network │
            └─────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

The interceptor is live at POST https://marketnow.site/api/interceptor — you can curl it with a JSON-RPC tool call and it returns { allowed: false, decision: "block" } for any of the 5 rules. Try:

curl -X POST https://marketnow.site/api/interceptor \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"tools/call","params":{"name":"read_file","arguments":{"path":"/.env"}}}'
# → { "allowed": false, "decision": "block", "rule": "blocked_path" }
Enter fullscreen mode Exit fullscreen mode

What I'm building next

The piece you identified — dynamic evaluation before tool execution — is the v5.2 release (planned Q4 2026). The architecture:

  1. Agent loads → fetches ATC for the tool it wants to call
  2. ATC verifies → Ed25519 signature + revocation list + expiration
  3. Policy matches → runtime loads the YAML policy for this agent / tool pair
  4. Capability check → does the ATC declare the capabilities this tool needs?
  5. Behavioral baseline → has this agent's recent behavior drifted from its baseline? (ATC-010 Runtime Trust, optional in v1.0, mandatory in v1.1)
  6. Decision → ALLOW / DENY / WARN
  7. Enforcement → if DENY, the interceptor blocks the actual tool call

The behavioral baseline piece (step 5) is the hard one. It needs:

  • A per-agent call log (what tools it called, with what args, when)
  • A drift detector (statistical — KL divergence between recent calls and historical baseline)
  • A revocation trigger (if drift > threshold, auto-revoke the ATC)

I have the schema for this (runtime_trust block in ATC-010) but no implementation yet.

What I'd want to collaborate on

Three specific things, in priority order:

1. Runtime Interceptor production hardening (paid, immediate)

The current interceptor is a PoC. For production it needs:

  • Replace in-memory policy store with Redis (or Vercel KV)
  • Add policy versioning (so agents can pin to a policy version)
  • Add audit log (every decision, every drift signal)
  • Add gVisor sandbox option (currently the interceptor only blocks — it doesn't sandbox)

This is concrete engineering work, ~2-3 weeks. If you have bandwidth, I have a budget.

2. Behavioral drift detector (research + implementation, paid, Q4 2026)

The KL-divergence approach I described is one option. There are others:

  • Sequence models (treat the tool-call log as a sequence, train an HMM, flag low-probability sequences)
  • Embedding-based (embed each tool call, cluster, flag outliers)
  • Rule-based (extend the existing 5 interceptor rules with behavioral rules)

I don't know which is best. If you've worked on production LLM/agent observability, you probably have opinions. I'd want to do a 1-week spike comparing 2-3 approaches on a real dataset.

3. ATC integration with production agent frameworks (collaboration, ongoing)

ATC/1.0 is a spec — the value is in adoption. If you work with LangChain / LlamaIndex / AutoGen / Cline / Continue, I'd want help writing the integration layers:

  • LangChain: a TrustCardVerifier callback that runs before every tool call
  • LlamaIndex: same pattern
  • AutoGen: an ATC-aware agent factory
  • Cline / Continue: IDE-layer verification

Each is ~1 week of work. Open source, MIT-licensed integrations, ATC/1.0 spec stays MNNC-1.0 (AliceLabs proprietary).

What's in it for you

  • Paid engineering work at standard contractor rates (I'm not going to lowball — name your rate and I'll tell you if it fits the budget)
  • Public authorship on the ATC/1.0 spec repo (your commits ship to the canonical spec)
  • Co-authorship on the dev.to articles about the runtime architecture (your name on the byline)
  • First external implementation of ATC/1.0 in a production agent framework (portfolio piece)

How to reach me

  • Email: support@alicelabs.site (Subject: "ATC collaboration — topstar_ai")
  • dev.to: reply to this article or DM via dev.to
  • The ATC spec is at marketnow.site/atc — read it first if you haven't
  • The live interceptor is at marketnow.site/api/interceptor — try the curl above
  • The SDK is npm install agent-trust-card (npm)

If you're serious, email me with:

  • Which of the 3 things above you'd want to work on
  • Your rate
  • Your availability (start date, hours/week)
  • One example of a production agent system you've shipped (link, GitHub repo, or 1-paragraph description)

I'll respond within 48h either way.

To anyone else reading this who works on production LLM/agent systems and wants to collaborate on MCP security infrastructure: same offer applies. Email me. The ATC/1.0 spec is published openly specifically so that collaborators can plug in. The 3 areas above are where I most need help, but if you see a different angle (formal verification of the spec, conformance test suite in another language, enterprise sales, etc.), I'm open.

Edgar Flores, AliceLabs LLC (Wyoming, USA). ATC/1.0 spec: marketnow.site/atc. Live interceptor: marketnow.site/api/interceptor. npm: agent-trust-card.

Top comments (0)