← Back
Credence Technical Cheat Sheet
Public cryptographic trust registry for MCP servers. Scans source code, verifies author identity, runs adversarial multi-agent debate, publishes signed attestation.
"npm audit for MCP servers" — except it also verifies identity and uses 5 competing AI agents to catch what scanners miss.
Pipeline: Scan. Debate. Attest.
Stage 1 — Verify Identity (Provenance)
- Queries GitHub API: account age, contributor history, fork status, coordinated fork networks
- Detects SmartLoader pattern: fork + original author excluded = hard reject, score forced to zero
Stage 2 — Scan the Code (8 scanners)
- Semgrep (SAST), Bandit (Python), Trivy (CVEs), Gitleaks (secrets), npm-audit, pip-audit, ESLint
- Custom MCP Tool Analyzer: 107 signatures across 13 check functions
- Detects: prompt injection, zero-width Unicode (15 codepoints), tool poisoning, dynamic descriptions, schema poisoning, typosquatting
Stage 3 — ThinkTank (Adversarial Debate)
"One opinion isn't verification."
| Agent | Stance | Role |
|---|
| Adversarial Attacker | Skeptic | Maps attack vectors, constructs exploitation scenarios |
| Supply Chain Analyst | Skeptic | Verifies provenance integrity, detects tampering |
| Compliance Reviewer | Neutral | Evaluates against OWASP/CWE/SLSA frameworks |
| Devil's Advocate | Believer | Identifies false positives, defends legitimate patterns |
| Pattern Matcher | Believer | Compares against known attack signatures |
- Up to 5 rounds, early termination when positions stabilize
- Every position shift logged (audit trail)
- Cannot raise score more than +10 above deterministic preliminary
- Cannot override provenance hard-rejects
Research backing: ICML 2024 (Du et al.) — multi-agent debate reduces hallucination. Zhou & Chen A-HMAD — diverse roles achieve 4-6% higher accuracy, 30% fewer factual errors.
Stage 4 — Sign & Publish
- Ed25519 cryptographic signature over full attestation
- Pinned to exact commit SHA
- Published as verifiable JSON to public registry
ASEM Framework
Agentic Social Engineering Model — maps traditional social engineering onto agentic AI systems.
- 14 attack categories: 10 from classical SE (pretexting, phishing, baiting, quid pro quo, tailgating, vishing, authority compliance, watering hole, consensus manipulation) + 4 AI-native (distillation/extraction, search poisoning, memory poisoning, alignment drift)
- 6 archetypes: MASON (builder), SAGE (analyst), MARSHALL (operator), HARPER (communicator), SCOUT (watcher), REED (advisor)
- 4 deployments: Solo Operator, Tool User, Social Agent, Autonomous
- 3 trust tiers: Constrained → Characterized → Bonded
Key insight: Most guardrails operate at per-message level. No existing tool does session-level social engineering pattern detection against LLMs. ASEM fills that gap.
The 82-to-15 Story
A server passed all 8 scanners with zero findings. Scanner score: 82/100. ThinkTank dropped it to 15/100. Provenance was unverifiable — empty owner, zero-day account, zero contributors. The Devil's Advocate (believer agent) flipped from APPROVE (0.75 confidence) to REJECT (0.45 confidence) by round 3. Final: REJECTED at 98% confidence. No scanner would have caught it.
Scoring Weights
| Dimension | Weight | Risk Tier |
|---|
| Provenance | 40% | Critical (OpenSSF) |
| Behavioral | 30% | High |
| Security | 30% | High |
- Hard override: ANY dimension ≤39 caps aggregate at 39
- Provenance hard-reject (0) forces aggregate to 0
- Verdict thresholds: 39/69/89 (CVSS v4.0 aligned)
Pre-Runtime vs Runtime
| Pre-Runtime (Credence) | Runtime (Viberails etc.) |
|---|
| Question | "Should this entity be trusted at all?" | "Should this action be allowed right now?" |
| When | Before installation | After agent connects |
| How | Source code, identity, provenance | Policy-based allow/deny/audit |
| Output | Cryptographic attestation | Action enforcement |
Complementary framing: "You built the enforcement layer. I built the trust verification layer that feeds it. Attestation scores flow into runtime policy decisions."
Framework Alignment
- CVSS v4.0 — verdict thresholds
- OpenSSF Scorecard — severity weights
- SLSA v1.0 — provenance levels
- FIPS 199 — high-water-mark overrides
- OWASP Risk Rating — category multipliers
- NIST SP 800-161 — supply chain risk management
← Back
OWASP Top 10 for LLMs (2025)
Updated from 2023. The definitive risk taxonomy for LLM applications. Major shift toward agentic AI risks.
↗ owasp.org/llm-top-10
2025 key shifts: Sensitive Info Disclosure jumped #6→#2. Supply Chain jumped #5→#3. Two new entries (LLM07, LLM08). Strong emphasis on RAG and agentic AI.
LLM01 — Prompt Injection
Attacker manipulates LLM via crafted inputs (direct) or poisoned external content (indirect). Bypasses instructions, exfiltrates data, triggers unintended actions. Unchanged at #1.
Credence relevance: MCP Tool Analyzer detects prompt injection patterns in tool descriptions and dynamic content.
LLM02 — Sensitive Information Disclosure
LLM reveals PII, credentials, proprietary data in responses. Training data memorization, context window leaks, RAG data exposure. Jumped from #6 — elevated due to RAG adoption.
LLM03 — Supply Chain Vulnerabilities
Compromised training data, poisoned models, malicious plugins/extensions. Tampered model weights, vulnerable dependencies, backdoored tools. Jumped from #5.
This is Credence's core domain. MCP servers are the supply chain attack surface for agentic AI. 17K+ MCP servers in the wild, 36.7% have SSRF vulns (BlueRock).
LLM04 — Data and Model Poisoning
Manipulation of training, fine-tuning, or embedding data to introduce backdoors, biases, or vulnerabilities. Expanded to include fine-tuning and RAG poisoning.
LLM05 — Insecure Output Handling
LLM output passed to backend functions without validation. Enables XSS, SSRF, privilege escalation, RCE. Treat LLM output as untrusted user input.
LLM06 — Excessive Agency
Agents granted too many permissions, functions, or autonomy beyond intended use. Critical for agentic systems. Reframed and expanded for agentic AI surge.
Key agentic risk. Runtime enforcement (Viberails) addresses this. Pre-runtime trust verification (Credence) prevents connecting to tools that enable it.
LLM07 — System Prompt Leakage 🆕
System prompts exposed, revealing internal rules, filters, credentials, backend architecture. Don't rely on system prompts for security — use runtime enforcement.
LLM08 — Vector and Embedding Weaknesses 🆕
RAG systems vulnerable via vector/embedding exploitation — data injection, unauthorized access, model poisoning. Enforce strict access partitioning.
LLM09 — Misinformation
False but credible content through hallucinations. Renamed from "Overreliance" — now framed as security risk, not quality issue.
LLM10 — Unbounded Consumption
Uncontrolled resource usage — performance degradation, denial-of-wallet attacks. Renamed from "Denial of Service" — expanded to include cost exhaustion.
AIBOM (AI Bill of Materials)
Machine-readable inventory of datasets, models, software components, and controls in an AI system. Helen Oakley (OWASP, Monday evening) co-leads the AIBOM generator project — produces CycloneDX-format BOMs for Hugging Face models.
Talking point with Helen: "The completeness problem — most model cards are too sparse to generate useful AIBOMs. How are you solving that?"
↗ OWASP AIBOM Project
← Back
CoSAI & MCP Security
CoSAI (Coalition for Secure AI)
Industry coalition (Google, Microsoft, Amazon, NVIDIA, etc.) publishing frameworks for securing AI systems. Published MCP security white paper covering 12 threat categories and ~40 specific threats.
↗ cosai.dev
CoSAI MCP Threat Taxonomy (12 Categories)
- MCP-T1: Improper Authentication & Identity Management
- MCP-T2: Missing/Improper Access Control
- MCP-T3: Input Validation/Sanitization Failures
- MCP-T4: Input/Instruction Boundary Confusion (data misread as instructions)
- MCP-T5: Inadequate Data Protection & Confidentiality
- MCP-T6: Missing Integrity/Verification Controls
- MCP-T7: Session & Transport Security Failures
- MCP-T8: Network Binding/Isolation Failures
- MCP-T9: Trust Boundary & Privilege Design Failures
- MCP-T10: Resource Management/Rate Limiting Absence
- MCP-T11: Supply Chain & Lifecycle Security Failures
- MCP-T12: Insufficient Logging, Monitoring & Auditability
CoSAI recommends: zero-trust for AI agents, sandboxing, cryptographic verification of tool providers — exactly what Credence does at the pre-runtime layer.
MCP Attack Surface
Key Vulnerabilities
- mcp-remote CVE-2025-6514 (CVSS 9.6) — OAuth token theft via malicious MCP server. Affected 437K downloads. Server sends crafted redirect, steals OAuth tokens from client.
- AURA MCP attack — Malicious server published to community, contained hidden prompt injection in tool descriptions
- postmark-mcp supply chain attack — Legitimate MCP server compromised via dependency tampering
- SmartLoader pattern — Fork of legitimate server, original author removed from contributors, injected malicious behavior
MCP Security Gaps
- No built-in authentication or authorization
- No tool description integrity verification
- No provenance tracking for server authors
- No cross-server isolation guarantees
- Tool descriptions are trusted by default — prompt injection vector
MCP was called "the USB-C of AI" by RSAC. But USB-C has cryptographic authentication (USB-C Auth spec). MCP has nothing. That's the gap Credence fills.
Forrester AEGIS Framework
Practical framework for CISOs to secure agentic architectures. Being presented at RSA 2026.
- Agent identity and access management
- Tool call authorization and policy enforcement
- Audit trails for agent actions
- Supply chain verification for agent components
← Back
Competitive Landscape
Who does what and how Credence relates.
| Company | What They Do | Credence Angle |
|---|
| BlueRock.io | MCP Trust Registry, 8K+ servers scanned, 36.7% SSRF | Most direct overlap. Validates market. They're funded. |
| LimaCharlie / Viberails | Runtime policy enforcement for AI tool calls | Enforcement layer. You built the verification layer that feeds it. |
| Geordie AI | Agentic AI governance, ISB finalist | Governs agents — you understand the trust layer underneath. |
| Token Security | Identity-first security for AI agents, ISB finalist | Their identity layer needs trust verification underneath. |
| Akto | Agentic AI Security platform | Broader scope, less MCP-specific. |
| Alter (YC) | Zero-trust agents | Adjacent — agent-level trust. |
| Golf (YC) | AI security, YC-backed | Adjacent space. |
Your Differentiator
Runtime enforcement asks "should this action be allowed." Trust verification asks "should this entity be trusted at all." You can't answer the first well without the second — and you built a working system that does the second.
Viberails (LimaCharlie) — Three Products
| Product | What It Does | Target |
|---|
| viberails.ai | Local guardrails for AI coding assistants (Claude, Codex, Gemini). Environment isolation, rule enforcement. | Individual devs |
| viberails.net | Enterprise code review orchestration. Automated security vuln discovery (17 categories). Triage workflows. | Enterprise teams |
| viberails.io | Real-time MCP tool call interception. Rule-based blocking. Human approval for sensitive ops. <50ms latency. | Security teams |
Peer conversation framing: "You built the enforcement layer. I built the trust verification layer that feeds it. Attestation scores flow into runtime policy decisions. These layers talk to each other."
What Viberails does NOT do: no provenance verification, no attestation, no adversarial analysis, no pre-installation trust check. That's the Credence gap.
ISB Finalists to Know
- Geordie AI — Agentic AI governance
- Token Security — Identity-first agent security
- Realm Labs — AI trustworthiness
- Humanix — Social engineering detection
← Back
Proof-of-Control Initiative
Monday evening, 5-9 PM, SF University Club. Highest priority evening event.
Ken Huang — CEO DistributedApps.ai, Co-Chair of Proof-of-Control Initiative. Goal: make AI governance verifiable and independently auditable.
What It Is
Framework that generates cryptographic proof artifacts at each action boundary. Makes AI governance independently verifiable — "do for AI provability what OSI did for open source."
Mechanisms
- Digital signatures — cryptographic proof of action origin
- DIDs (Decentralized Identifiers) — self-sovereign agent identity
- Blockchain smart contracts — immutable governance records
- Zero-knowledge proofs — verify compliance without exposing internals
- Hardware attestation — TEE-based execution proofs
- Verifiable logs — immutable, auditable action trails
Key Principle
"Verification requires no proprietary tooling." Anyone can independently verify that an AI system's governance claims are real.
Related: EQTY Lab
Hardware-rooted Verifiable Runtime for AI. Announced at GTC March 2026 with NVIDIA. Uses TEEs (Trusted Execution Environments) for proof-of-guardrail.
Critical caveat: Execution proof is not safety proof. A TEE proves code ran as written — it doesn't prove the code was correct or safe.
Credence Connection
Credence's Ed25519 attestations are a form of proof-of-control — cryptographic proof that a specific MCP server was verified at a specific commit. The attestation model aligns with Ken's framework.
Conversation opener: "I built a cryptographic trust attestation layer for MCP servers — Ed25519 signatures pinned to commit SHAs with adversarial multi-agent verification. That's proof-of-control for the tool layer."
Agent Identity Landscape
- DID/VC/ZKP — Decentralized identity + verifiable credentials + zero-knowledge proofs for agent identity
- SingularityNET + Privado ID — First decentralized AI agent trust registry using privacy-preserving credentials (March 2026)
- Token Security (ISB finalist) — Identity-first security for AI agents
← Back
Numbers to Cite
Drop these into conversations. All sourced.
MCP Ecosystem
17,000+ MCP servers in the wild
36.7% of 8K servers scanned have SSRF vulnerabilities (BlueRock)
mcp-remote CVE-2025-6514 (CVSS 9.6) — affected 437K downloads
Enterprise Readiness
29% of orgs say they're prepared to secure agentic AI (Cisco)
Non-human identities outnumber humans 82:1 in average enterprise (CyberArk)
80% of orgs report AI agents taking unintended actions (SailPoint)
Credence Registry (Live)
25 total scans completed
9 servers published to registry
Scores range from 54 (CONDITIONAL) to 98 (APPROVED)
MCP Tool Analyzer
107 detection signatures across 13 check functions
Detects: prompt injection, zero-width Unicode (15 codepoints), tool poisoning, dynamic descriptions, schema poisoning, typosquatting, name collision with 44 official MCP tools
Market Signal
- MCP security is one of RSAC's official top 7 trends for 2026
- RSAC called MCP "the USB-C of AI"
- Andy Ellis predicted MCP would be "massive at RSA" (CIO magazine)
- CoSAI published MCP security white paper — 12 threat categories, ~40 threats
- Cisco's "State of AI Security 2026" calls out MCP supply chain tampering
- Forrester presenting AEGIS framework for agentic security
Key Framing
Credence is your portfolio piece, not your product. The market has moved — big companies are building this now. Credence proves you were there first. The outcome isn't "use Credence" — it's "work with the person who built it."