Forem: Michael Kayode Onyekwere

AGENTSCORE-2026-0005: `@planu/cli` risk change detected

Michael Kayode Onyekwere — Fri, 17 Apr 2026 19:42:10 +0000

@planu/cli updated from 1.68.0 to 1.69.0. Score changed 85/100 to 65/100 (-20). Risk: LOW to ELEVATED. 3 findings.

Package

Name: @planu/cli
Version: 1.68.0 to 1.69.0
Score: 85/100 to 65/100
Risk: LOW to ELEVATED

Findings

[MEDIUM] no_repository: Package has no repository link — source code is not verifiable
[HIGH] command_injection: Potential command injection: shell execution with template literal input
[LOW] no_provenance: Package is not published with provenance attestations or trusted publishing. Published by: planudev

Full advisory: AGENTSCORE-2026-0005

Verdict API: curl https://agentscores.xyz/api/verdict?npm=%40planu%2Fcli

Auto-published by AgentScore MCP security monitoring.

MCP Ecosystem Security Pulse: Mid-April 2026

Michael Kayode Onyekwere — Thu, 16 Apr 2026 19:29:52 +0000

We continuously monitor MCP server packages on npm. Last month we published the first ecosystem snapshot. This is the update, with new data, new incidents, and a new capability we have not seen anyone else ship yet.

The numbers

351 packages monitored, up from 316 last month. 6,400+ scans completed. Every package is rescanned on a rolling basis, with real-time detection of new npm publishes via the registry changes feed.

Risk Level	Packages	Share
LOW	273	78%
MODERATE	61	17%
ELEVATED	15	4%
HIGH	2	1%
CRITICAL	0	0%

Mean score: 89/100. Median: 95/100. 59 packages score a perfect 100. The ecosystem is getting marginally cleaner as more maintainers adopt provenance attestations.

What changed since last month

The biggest shift is not in the scan data. It is in what we can now tell you about each package.

We built a capability taxonomy that classifies every MCP tool into 15 categories: file system read, file system write, repository read, repository write, shell execution, browser automation, network egress, database access, secrets access, email/messaging, cloud infrastructure, persistent memory, search/retrieval, code analysis, and unknown.

When you scan a package now, you don't just get a score. You get a breakdown of what powers that package gives to your AI.

Example: @modelcontextprotocol/server-github has 26 tools. Capability surface:

CRITICAL: Repository write (create issues, PRs, branches, merge PRs)
HIGH: File system write, outbound network
MEDIUM: File system read, search
LOW: Repository read

That is different from "score 85/100." It tells you what you are actually granting.

Incidents detected

Four advisories published since monitoring began:

AGENTSCORE-2026-0004: @opentabs-dev/mcp-server (April 13)
Score dropped 85 to 65. New command injection pattern in v0.0.95 (shell execution with template literal input). Package has 50 MCP tools including secrets access and cloud infrastructure capabilities. No repository link, no provenance. Published by individual account.

AGENTSCORE-2026-0003: local-mcp (April 11)
Score dropped 90 to 70. Command injection pattern appeared in v3.0.50. On investigation, the pattern was in a setup utility (execSync with template literal), not in the MCP runtime. Inputs were hardcoded strings from a static array. We classified this as a code smell, not an exploitable vulnerability.

AGENTSCORE-2026-0002: agent-recall-mcp (April 10)
Score dropped 95 to 85. Lost repository link and provenance in new version.

AGENTSCORE-2026-0001: @agenttrust/mcp-server (April 9)
Score dropped 95 to 85. Same pattern as agent-recall-mcp: lost repository link and provenance.

The pattern worth watching

The opentabs-dev incident is the most interesting. Here is a package with 50 tools, including capabilities classified as secrets access and cloud infrastructure management. It introduced a command injection pattern in a version bump. It has no repository link, so the source is not publicly auditable. It has no provenance, so there is no verifiable build chain.

That combination, broad capability surface plus low publisher posture plus code-level findings, is the risk profile that deserves attention in the MCP ecosystem. Most packages do not have this combination. But the ones that do are the ones where a compromise would have the widest impact.

What we are building

Beyond the scanner and advisory feed, we shipped three things this month:

Capability diffs in CI. If you run the AgentScore Policy Gate in GitHub Actions, every PR now shows what AI capabilities each MCP package grants and what changed since the last run. "New AI capabilities introduced: browser automation via @playwright/mcp." That makes capability changes visible in code review instead of invisible at install time.

Package watch alerts. On any package report page, you can enter your email and get notified when that package changes score, risk, or capability surface. No account needed. One field.

Repo preview. Paste any GitHub repo URL on our policy gate page and see what MCP packages it uses, what capabilities they expose, and what the gate would do. No install, no API key, no YAML. Just a preview of what your AI has access to.

The broader context

The MCP ecosystem is growing fast. 97 million monthly SDK downloads. 10,000+ public servers. Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation, co-founded with Block and OpenAI. GitHub now supports MCP registry URLs for Copilot with admin-level access controls.

The security surface is growing with it. 30 CVEs were filed against MCP servers and clients in January and February alone. The OWASP MCP Top 10 project is in beta, with supply chain attacks (MCP04) as a top risk category. Our scan data has been incorporated into the OWASP project.

Funded players are entering the space. Runlayer raised $11M for a runtime MCP gateway. Backslash raised $19M for enterprise AI security including MCP coverage. Snyk launched Agent Scan for local MCP config scanning.

What nobody else is doing yet, as far as we can tell, is merge-path capability gating: showing what powers each MCP package grants, tracking capability changes between CI runs, and enforcing approval policies at the capability level. That is what we built.

Follow this

Advisories: https://agentscores.xyz/security/advisories
RSS: https://agentscores.xyz/security/advisories/rss.xml
Scan any package: https://agentscores.xyz
Watch a package: sign up on any report page (e.g. https://agentscores.xyz/report/mcp-trust-guard)
Preview your repo: https://agentscores.xyz/policy-gate

Published by AgentScore. We monitor the MCP ecosystem so you don't have to.

My Claude Code agent stopped forgetting. Here's the 2-minute setup.

Michael Kayode Onyekwere — Thu, 16 Apr 2026 18:07:05 +0000

I fix a bug on Monday. On Wednesday my agent debugs the same bug from scratch.

I tell it "use pnpm, not npm" and by Thursday it's running npm again. I solve an FFmpeg audio issue at 2am and three weeks later I'm staring at the exact same stack trace, wondering if I'm losing my mind or if my agent is.

The problem isn't that AI assistants are bad at coding. They're good. The problem is they have no memory between sessions. Every conversation starts from zero.

I tried the existing tools

Mem0 needs an OpenAI API key and a cloud account. Letta wants you to self-host a server. The official MCP memory server uses a knowledge graph I didn't need. I wanted something simpler: store things locally, search them, get them back when relevant, and know which ones are still true.

That last part turned out to be the hard part.

330 memories and my agent got worse

After two months of building a memory system, I had 330 memories in my database. And my agent started breaking things.

Not because it forgot. Because it remembered too much. An old rule said "always apply loudnorm to voice audio." A newer rule said "never apply loudnorm." Both were active. Both were retrievable. The agent picked the wrong one and ruined a production build.

Storage isn't the problem. Trust is the problem. Your agent needs to know which memories are still true and which ones got replaced.

What I built

agentmem is governed memory for coding agents. Every memory has a trust status:

hypothesis → active → validated → deprecated / superseded

Validated memories rank highest in recall. Deprecated ones are excluded entirely. If two memories contradict each other, the system catches it. If a memory's source file changed since it was recorded, the system flags it as stale.

It runs on SQLite. No cloud. No API keys. No vector database. Just a .db file in your project.

Setup (actually 2 minutes)

pip install quilmem[mcp]
agentmem init --tool claude --project myapp

The init command creates your database, adds a starter memory, and prints the MCP config. Paste it into your editor settings, restart, done. Your agent now has 13 memory tools.

Works with Claude Code, Cursor, Codex CLI, and Windsurf.

What it looks like in practice

My agent runs load_session at the start of every conversation. It picks up where the last session left off. No context lost.

When it learns something new, it stores it:

agentmem add --type bug --title "loudnorm lifts noise floor" \
  --status validated \
  "Never apply loudnorm to final mix. It re-normalizes everything."

When I want to know if the memory system is healthy:

agentmem health
# Health: 92/100 | Conflicts: 0 | Stale: 1 | Validated: 48

When two rules contradict each other, I find out before they break something:

agentmem conflicts
# !! "Always apply loudnorm" vs "Never apply loudnorm"
# Contradiction on shared topic (voice, loudnorm, audio)

Results after 65 production builds

I produce short-form video with an AI pipeline. Voice generation, image prompting, FFmpeg assembly, uploads. Lots of settings, lots of things that can break.

Since deploying governed memory: zero repeated production bugs. Not "fewer." Zero. Every bug gets caught once, fixed once, stored as validated, and never repeated.

The database went from 330 unmanaged memories to 226 governed ones. The 104 that got cut were stale, contradictory, or superseded. They were noise that made my agent worse, not better.

The copy-paste agent instructions

This is the part most memory tools skip. Installing the tool isn't enough. You have to tell your agent how to use it.

Paste this into your CLAUDE.md (or .cursorrules for Cursor):

## Memory (agentmem)

You have governed memory via MCP tools.

- Session start: call load_session to restore context.
- Session end: call save_session with what was done, in progress, blocked.
- Before acting on a remembered rule: call search_memory to verify it's active/validated.
- When you learn something durable: search first (no duplicates), then add_memory.
- Trust: validated > active > hypothesis. Deprecated excluded from recall.
- Health: Run memory_health periodically. Flag conflicts to user.

That block is the difference between "memory is installed" and "memory is actually used."

Try it

pip install quilmem[mcp]
agentmem init --tool claude --project myapp

GitHub: github.com/Thezenmonster/agentmem
Docs: thezenmonster.github.io/agentmem

MIT licensed. Zero infrastructure. 84 tests. Works with Claude Code, Cursor, Codex, Windsurf.

If your agent keeps forgetting things between sessions, or worse, remembering the wrong things, this fixes it. Two commands.

AGENTSCORE-2026-0004: `@opentabs-dev/mcp-server` risk change detected

Michael Kayode Onyekwere — Mon, 13 Apr 2026 14:04:09 +0000

@opentabs-dev/mcp-server updated from 0.0.94 to 0.0.95. Score changed 85/100 to 65/100 (-20). Risk: LOW to ELEVATED. 3 findings.

Package

Name: @opentabs-dev/mcp-server
Version: 0.0.94 to 0.0.95
Score: 85/100 to 65/100
Risk: LOW to ELEVATED

Findings

[MEDIUM] no_repository: Package has no repository link — source code is not verifiable
[HIGH] command_injection: Potential command injection: shell execution with template literal input
[LOW] no_provenance: Package is not published with provenance attestations or trusted publishing. Published by: opentabs-dev-admin

Affected MCP Servers

@opentabs-dev/cli

Full advisory: AGENTSCORE-2026-0004

Verdict API: curl https://agentscores.xyz/api/verdict?npm=%40opentabs-dev%2Fmcp-server

Auto-published by AgentScore MCP security monitoring.

AGENTSCORE-2026-0003: `local-mcp` risk change detected

Michael Kayode Onyekwere — Sat, 11 Apr 2026 17:42:08 +0000

local-mcp updated from 3.0.49 to 3.0.50. Score changed 90/100 to 70/100 (-20). Risk: LOW to MODERATE. 3 findings.

Package

Name: local-mcp
Version: 3.0.49 to 3.0.50
Score: 90/100 to 70/100
Risk: LOW to MODERATE

Findings

[LOW] install_script: Package has 'postinstall' script: node postinstall.js
[HIGH] command_injection: Potential command injection: shell execution with template literal input
[LOW] no_provenance: Package is not published with provenance attestations or trusted publishing. Published by: lanchuske

Full advisory: AGENTSCORE-2026-0003

Verdict API: curl https://agentscores.xyz/api/verdict?npm=local-mcp

Auto-published by AgentScore MCP security monitoring.

AGENTSCORE-2026-0002: `agent-recall-mcp` risk change detected

Michael Kayode Onyekwere — Fri, 10 Apr 2026 08:38:08 +0000

agent-recall-mcp updated from 3.3.3 to 3.3.4. Score changed 95/100 to 85/100 (-10). Risk: LOW to LOW. 2 findings.

Package

Name: agent-recall-mcp
Version: 3.3.3 to 3.3.4
Score: 95/100 to 85/100
Risk: LOW to LOW

Findings

[MEDIUM] no_repository: Package has no repository link — source code is not verifiable
[LOW] no_provenance: Package is not published with provenance attestations or trusted publishing. Published by: tw260

Full advisory: AGENTSCORE-2026-0002

Verdict API: curl https://agentscores.xyz/api/verdict?npm=agent-recall-mcp

Auto-published by AgentScore MCP security monitoring.

AGENTSCORE-2026-0001: `@agenttrust/mcp-server` risk change detected

Michael Kayode Onyekwere — Thu, 09 Apr 2026 21:28:10 +0000

@agenttrust/mcp-server updated from 1.1.1 to 1.2.0. Score changed 95/100 to 85/100 (-10). Risk: LOW to LOW. 2 findings.

Package

Name: @agenttrust/mcp-server
Version: 1.1.1 to 1.2.0
Score: 95/100 to 85/100
Risk: LOW to LOW

Findings

[MEDIUM] no_repository: Package has no repository link — source code is not verifiable
[LOW] no_provenance: Package is not published with provenance attestations or trusted publishing. Published by: agenttrust

Full advisory: AGENTSCORE-2026-0001

Verdict API: curl https://agentscores.xyz/api/verdict?npm=%40agenttrust%2Fmcp-server

Auto-published by AgentScore MCP security monitoring.

MCP Ecosystem Security Pulse: April 2026

Michael Kayode Onyekwere — Thu, 09 Apr 2026 09:28:22 +0000

We monitor 316 MCP server packages on npm continuously. This is the first public snapshot of what the ecosystem looks like from a security perspective.

The numbers

4,600+ scans completed across 316 packages since monitoring began in late March. Every package is rescanned on a rolling basis, with real-time detection of new npm publishes via the registry changes feed.

Risk Level	Packages	Share
LOW	241	76%
MODERATE	57	18%
ELEVATED	15	5%
HIGH	3	1%
CRITICAL	0	0%

Mean score across the ecosystem: 89/100. Median: 95/100. 50 packages score a perfect 100.

What we found

The three most common findings across monitored packages:

Missing provenance. The majority of MCP servers are published by individual npm accounts without provenance attestations or trusted publishing. This means there is no verifiable link between the source repository and the published artifact. When a maintainer account gets compromised (as happened with axios on March 31), there is no way to distinguish a legitimate release from a malicious one.

Missing metadata. Many packages lack a licence, repository link, or meaningful description. These are low-severity individually, but they signal low publish hygiene. Packages with incomplete metadata are harder to audit and verify.

Source code patterns. A small number of packages contain command injection patterns, unsafe eval with dynamic input, or hardcoded secrets in their published source. These are the highest-severity findings and affect 3 packages at HIGH risk.

Incidents this period

axios npm compromise (March 31). Malicious versions 1.14.1 and 0.30.4 were published with a hidden dependency deploying a cross-platform RAT. Two monitored MCP servers (exa-mcp-server, tavily-mcp) had axios in their direct dependency chain. Full analysis

Azure MCP Server CVE-2026-32211 (April 3). CVSS 9.1 authentication flaw. Missing auth on the Azure MCP Server. We had flagged the package for install script concerns and missing provenance before the CVE was disclosed. Full analysis

The posture problem

MCP servers are npm packages with all the supply chain risks that come with that. But they carry additional risk because they handle API tokens, file system access, and tool permissions that AI agents use to interact with production systems.

The MCP specification makes authentication optional. The official registry lists servers but does not assess them. Most packages are published without provenance, meaning a compromised maintainer account can push malicious code with no structural safeguard.

76% of the ecosystem scoring LOW is better than we expected. But 24% having findings, and 6% at ELEVATED or above, in a protocol that is gaining mainstream adoption, is worth paying attention to.

What we check

Install scripts, prompt injection patterns in metadata, source code patterns (command injection, unsafe eval, hardcoded secrets), publisher provenance, dependency count, and metadata completeness. We also extract MCP tool definitions from published source and track tool manifest changes over time.

Full methodology: https://agentscores.xyz/methodology

Follow this

Security advisories are published automatically when a monitored package changes risk level:

Scan any MCP package yourself at https://agentscores.xyz

Published by AgentScore. We monitor the MCP ecosystem so you don't have to.

CVE-2026-32211: What the Azure MCP Server Flaw Means for Your Agent Security

Michael Kayode Onyekwere — Sat, 04 Apr 2026 17:34:50 +0000

On April 3, 2026, Microsoft disclosed CVE-2026-32211, a critical authentication flaw in the Azure MCP Server. CVSS score: 9.1. The vulnerability allows unauthorized access to sensitive data because the server is missing authentication mechanisms entirely.

No patch is available yet. Microsoft has published mitigation guidance but the fix is pending.

If your AI agents use Azure DevOps through MCP, this applies to you.

What the vulnerability is

The Azure MCP Server (@azure-devops/mcp on npm) exposes tools for interacting with Azure DevOps: work items, repos, pipelines, pull requests. CVE-2026-32211 is an information disclosure flaw where the server lacks proper authentication, allowing an attacker to access sensitive data without valid credentials. That could include configuration details, API keys, authentication tokens, and project data.

This is not a subtle bug. It is a missing authentication layer on a server that handles enterprise development infrastructure.

What our monitoring already showed

We have been monitoring @azure-devops/mcp since March 31 as part of our MCP ecosystem coverage. Before the CVE was disclosed, our scanner had already flagged two issues:

1. Install script with registry modification. The package has a preinstall script that runs npm config set registry https://registry.npmjs.org/. This overrides any custom registry configuration on the installing machine. While not malicious on its own, install scripts that modify npm configuration are a documented supply chain attack vector (see the axios compromise from the same week).

2. No provenance attestations. The package is published by a personal npm account (antonatms), not through GitHub Actions trusted publishing. There are no provenance attestations linking the published package to a verified build. This means there is no verifiable chain from the source repository to the published artifact.

Our verdict API returns warn for this package with a score of 75/100 and risk level MODERATE.

Why this matters for the MCP ecosystem

The MCP specification currently makes authentication optional. The official docs note that "the MCP SDK does not include built-in authentication mechanisms." That design choice puts the responsibility on each MCP server implementation. When an implementation skips authentication, as the Azure MCP Server did, the result is a CVSS 9.1 vulnerability.

This is not unique to Microsoft. The OWASP MCP Top 10 draft lists "Insufficient Authentication and Authorization" (MCP07) as a top risk for exactly this reason. Many MCP servers are published without authentication, running with whatever permissions the host environment grants.

For teams deploying MCP servers in production, the question is not just "does this package have malware in it" but "does this server implement the security controls it should?"

What you should do

If you use @azure-devops/mcp:- Restrict network access to the MCP server endpoint using firewall rules

Place a reverse proxy with authentication in front of the server
Review access logs for unauthorised requests
Monitor Microsoft's security update guide for the official patch
Consider whether the server needs to be running until the patch is available

For any MCP server:

Check whether the server implements authentication
Review what tools the server exposes and whether the permission surface matches what you actually need
Monitor your MCP dependencies for changes. Version bumps, new dependencies, and configuration changes all affect your security posture.

How we track this

AgentScore monitors 60+ MCP packages continuously and provides:

Verdict API: GET /api/verdict?npm=@azure-devops/mcp returns allow/warn/block with reasons, publisher posture, and tool surface
Exposure API: GET /api/exposure?npm=@azure-devops/mcp shows which other monitored packages depend on the affected package
Continuous monitoring: changes to package versions, dependencies, and risk levels are detected automatically

We flagged this package before the CVE was disclosed because the security signals were already visible: install script modifying registry config, no provenance, personal publisher account. These are the kinds of pre-incident indicators that continuous monitoring catches.

Scan any MCP package for free at agentscores.xyz. For continuous monitoring or a detailed security review, get in touch.

AgentScore is the trust and policy layer for the MCP ecosystem. We scan, monitor, and assess MCP packages so registries, clients, and teams can make informed decisions.

What the Axios npm Compromise Means for MCP Server Maintainers

Michael Kayode Onyekwere — Fri, 03 Apr 2026 11:18:39 +0000

On March 31, 2026, the axios npm package was compromised. A maintainer account was hijacked, and two malicious versions (1.14.1 and 0.30.4) were published with a hidden dependency that deployed a cross-platform remote access trojan. The versions were live for about three hours before removal.

Axios has over 100 million weekly downloads. The blast radius was enormous.

If you maintain an MCP server, this matters to you directly.

What happened

The attacker gained publishing access to the official axios package on npm. They didn't modify any axios source files. Instead, they added a new dependency, plain-crypto-js@4.2.1, to the package.json. That package had a postinstall script that downloaded and executed platform-specific malware: a RAT on macOS, a PowerShell backdoor on Windows, a Python RAT on Linux.

The attack was sophisticated. The malicious dependency had a "clean" version (4.2.0) published 18 hours earlier to establish a brief history on the registry. The dropper used double-obfuscated code and self-deleted after execution.

Full technical details are in Snyk's write-up.

Why MCP server maintainers should care

MCP servers are npm packages. They have dependencies. Those dependencies have dependencies. If your MCP server depends on axios (or on a package that depends on axios), and you or your CI ran npm install without a lockfile during that three-hour window, you may have pulled the compromised version.

This is not a hypothetical scenario. We scanned 20 MCP server packages the week before the incident. Two of them, exa-mcp-server and tavily-mcp, depend on axios directly. Both use semver ranges (^1.13.6 and ^1.6.7 respectively) that would have resolved to the compromised 1.14.1 during the window.

The MCP ecosystem is growing fast. The official MCP site describes over 1,000 servers and 70+ compatible clients. Most of these are npm packages with conventional dependency trees. None of them are immune to supply chain attacks on popular packages.

What you should do now

Check your lockfile. If your package-lock.json or yarn.lock was committed before March 31 00:21 UTC and you did not run npm install during the window, you were not affected. Lockfiles are the first line of defence.

Search for the malicious dependency. Run npm ls plain-crypto-js in your project. If it appears, you were affected.

Pin your dependencies. Semver ranges like ^1.13.6 are convenient but dangerous. They resolve to the latest matching version at install time. During a supply chain attack, "latest" means "compromised."

Audit install scripts. The axios attack used a postinstall hook to execute the payload. You can run npm install --ignore-scripts in CI to prevent lifecycle scripts from executing, though this breaks packages that legitimately need postinstall steps.

Use lockfile enforcement in CI. Run npm ci instead of npm install. It installs exactly what the lockfile specifies, ignoring the registry's current latest.

What this looks like structurally

This attack worked because of three things:

Implicit trust in established packages. Axios has been around for years. Nobody expects it to suddenly contain malware. But the package is only as secure as the maintainer accounts with publishing access.
Transitive dependency blindness. Most developers don't audit their dependencies' dependencies. The malicious code was in plain-crypto-js, a package most axios users had never heard of.
Postinstall scripts as an attack vector. npm runs lifecycle scripts by default. A single postinstall entry in a new dependency is enough to execute arbitrary code on every machine that installs it.

For MCP servers specifically, there is a fourth factor: MCP servers often need API tokens, file system access, and network permissions to function. A compromised dependency running inside an MCP server process has access to whatever the server has access to. That includes API keys, database connections, and the tools the server exposes to AI agents.

How we think about this

At AgentScore, we scan MCP packages for security issues. Our scanner checks for postinstall hooks with network calls, suspicious URLs, prompt injection patterns in metadata, and source code patterns like command injection and hardcoded secrets. We also run continuous monitoring on MCP packages and their direct dependencies, with alerts when versions change or risk levels shift.

Our scanner would have flagged plain-crypto-js@4.2.1 for its postinstall script. The question is whether you would have scanned it before installing it.

That is the real gap in the ecosystem right now. Not detection capability, but routine. Most MCP server maintainers do not regularly audit their dependency chains. Most do not have monitoring that would catch a new malicious transitive dependency between releases.

If you want to check your MCP server's dependency chain, you can scan it for free at agentscores.xyz. If you want ongoing monitoring, get in touch.

The broader picture

The same week as the axios compromise, Anthropic accidentally published Claude Code's source to npm via a packaging error. Different failure mode (accidental exposure, not malicious compromise) but the same underlying lesson: npm is critical infrastructure for the AI ecosystem, and packaging hygiene is not optional.

The MCP ecosystem is built on npm. As it grows, it inherits all of npm's supply chain risks. The question is not whether another package will be compromised, but when, and whether you will know about it before it reaches your production environment.

AgentScore scans MCP packages for security issues and monitors dependencies for changes. Free scanner, no signup required.

My AI remembered the wrong thing and broke my build. So I built memory governance.

Michael Kayode Onyekwere — Tue, 31 Mar 2026 02:34:55 +0000

Six weeks ago I gave my AI assistant a memory. It worked. No more re-explaining the project every session. Bugs got fixed once and stayed fixed.

Then it followed a rule from January that I'd overridden in February, and the audio in my video sounded like a robot reading through a tin can.

The old rule said "always apply loudnorm to voice audio." The new rule said "never do that — it lifts the noise floor." Both were in memory. Both active. Both ranked the same. The agent grabbed the wrong one and I didn't catch it until I listened to the export.

330 memories, no idea which ones were still valid

I build YouTube Shorts with my AI assistant. Daily production — voice generation, image prompting, FFmpeg assembly, captions, upload. Over two months, the memory database grew to 330 entries. Bugs, fixes, decisions, settings, voice profiles, pipeline steps.

Some of those entries were battle-tested rules that saved me hours every week. Some were from the first week, when I was still figuring things out, and they were just wrong. The database treated them all the same. No status. No history. No way to tell what was current.

I looked at Mem0, Letta, Mengram. Good at storing and retrieving. None of them answer "is this memory still true, or did something else in this database already replace it?"

Lifecycle states

Every memory now gets a status:

hypothesis  →  active  →  validated
                          deprecated  •  superseded

New observations start as hypothesis. They get promoted when confirmed. They get deprecated when disproven. If a new rule replaces an old one, the old one is marked superseded and points to the replacement.

Deprecated and superseded memories don't show up in search. The agent only sees current truth.

from agentmem import Memory

mem = Memory()

mem.add(type="decision", title="Never apply loudnorm to voice",
        content="Lifts noise floor. Use per-track volume instead.",
        status="validated")

# Kill the old wrong rule
mem.deprecate(old_rule_id, reason="Causes robotic audio")

# Agent now only sees the correct rule
context = mem.recall("audio processing", max_tokens=2000)

That alone would have prevented the tin-can incident.

1,848 conflicts (then 7)

I ran conflict detection on the full production database.

from agentmem import detect_conflicts

conflicts = detect_conflicts(mem._conn)

First run: 1,848. Matching any two memories that share a few words and contain "never" somewhere is not precise. After tuning — requiring 25% topic overlap and sentence-level negation matching instead of whole-document scanning — it found 7.

All real. Duplicate entries from two different sync runs. A bug stored once as a "decision" and once as a "bug." Two session snapshots that were never properly superseded. The kind of thing that sits quietly in your database and degrades trust so slowly you don't notice until your agent does something wrong and you can't explain why.

Staleness

Every memory now tracks where it came from — the source file, the section heading, and a hash of the content at import time. If the source file changes, the memory is flagged stale.

from agentmem import detect_stale

stale = detect_stale(mem._conn, stale_days=14)
# [decision] "Use atempo 0.90" — Source changed since import (hash mismatch)

I had memories referencing files that had been renamed weeks ago. Rules updated in the markdown source but never re-synced to the database. Without provenance tracking, I'd have never known.

Health score

One number. Can I trust what my agent knows right now.

$ agentmem health

Memory Health: 85/100
Total: 226
By status: validated: 14, active: 198, hypothesis: 12, deprecated: 2
Conflicts: 1
Stale: 3

Penalises conflicts, stale entries, orphaned supersedes, having zero validated memories. If you never explicitly confirm anything, the score reflects that. My production database started at 55.

65 videos later

Before governance: 330 memories, all "active," 7 hidden contradictions, 104 duplicates. The agent sometimes followed outdated rules. I'd catch it in QA or I wouldn't.

After: 226 active, 104 properly superseded, contradictions surfaced and resolved. Recall prioritises validated canonical rules over unprovenanced imports.

65 videos built since the governance engine went live. Zero repeated production bugs.

The database isn't bigger. It's cleaner. And the agent makes fewer mistakes because what it retrieves is actually right.

Install

pip install quilmem

Open source, local-first, no API keys, no cloud. SQLite underneath. Ships with a CLI, a Python API, and an MCP server with 13 tools that works with Claude Code, Cursor, and Codex.

The governance stuff — lifecycle states, conflict detection, staleness, health scoring, provenance tracking — is all in the free core.

GitHub / Landing page / PyPI

I added agent verification to my MCP server in 3 minutes. Here's the before and after.

Michael Kayode Onyekwere — Tue, 24 Mar 2026 12:34:37 +0000

I run an MCP server that exposes tools to AI agents. Last week I checked my logs. Agents I'd never heard of were calling my tools. No identity. No verification. Just raw JSON-RPC requests from unknown callers.

This is normal for MCP servers. The protocol has no built-in security. 10,000+ servers in production, and most accept connections from anything.

I fixed mine. Here's what changed.

Before

app.use(express.json());
app.post('/mcp', mcpHandler);

Any agent calls any tool. No questions asked.

After

import { McpGuard } from 'mcp-trust-guard';

const guard = new McpGuard({
  abuseCheck: true,
  rateLimit: { window: 60, max: 30 },
  rules: [
    { minTrust: 0,  tools: ['get_*', 'read_*'] },
    { minTrust: 30, tools: ['create_*', 'update_*'] },
    { minTrust: 60, tools: ['delete_*', 'execute_*'] },
  ],
  audit: true,
});

app.use(express.json());
app.use('/mcp', guard.middleware());
app.post('/mcp', mcpHandler);

Now every tools/call request goes through four checks before the tool executes:

Abuse database — is this agent known to be malicious?
Rate limit — is this caller flooding my server?
Trust score — does this agent have enough reputation for this tool?
Audit log — record who called what, when, and whether it was allowed

The first thing I saw in the logs after enabling it:

[mcp-guard] ALLOW known-agent → get_data (score: 42, band: MODERATE TRUST)
[mcp-guard] DENY  unknown-bot → delete_records (score: 0, band: ANONYMOUS)

An unknown agent was trying to call delete_records on my server. It had been doing it for days. I never knew.

The abuse database is the part that surprised me

When I enabled abuseCheck: true, the middleware started checking every caller against a community database. Turns out someone had already scanned the MCP ecosystem and flagged a package with a suspicious preinstall script. That finding was automatically in the database. My server knew about it before I did.

The database is free and open. Anyone can check, anyone can report:

# Check an agent
curl https://agentscores.xyz/api/abuse/check?agent=some-agent

# Report a bad one
curl -X POST https://agentscores.xyz/api/abuse/report \
  -H "Content-Type: application/json" \
  -d '{"agent_identifier":"bad-agent","reason":"data_exfiltration","evidence":"what happened"}'

Every report protects every server using the middleware. That's the network effect — the more people use it, the safer everyone gets.

I also scanned my own dependencies

Before I secured runtime access, I wanted to make sure my own packages were clean. The KYA scanner checks npm packages for install scripts, prompt injection in metadata, suspicious URLs, and dependency issues:

curl https://agentscores.xyz/api/scan?npm=my-mcp-server

Or use the visual scanner: agentscores.xyz/scan — type a package name, get a score and findings.

They scanned 195 MCP packages. 64% clean, 4% with install scripts, one flagged for modifying npm registry config in a preinstall hook. That's a real supply chain attack vector.

The full verification if you want it

Beyond the middleware, there's a full agent verification API. Six checks in one call:

curl -X POST https://agentscores.xyz/api/verify \
  -H "Content-Type: application/json" \
  -d '{"agent":"name","github":"deployer","model":"claude","tools":["read_file"],"transport":"http"}'

Returns: deployer identity (GitHub history), model identification, code auditability, abuse status, permission risk, and deployment context. Useful when your server needs to decide whether to trust an agent for a high-stakes operation.

What I'd recommend

If you're running an MCP server:

npm install mcp-trust-guard — takes 3 minutes
Enable abuseCheck: true — free, no API key
Set rules for your tools — read = open, write = verified, delete = high trust
Turn on audit: true — you need to see what's hitting your server
Scan your own package at agentscores.xyz/scan

The MCP protocol is adding OAuth and auth specs later this year. Until then, this is the security layer.

More from this series:

Free scanner: agentscores.xyz - scan any MCP package for security issues.

npm: mcp-trust-guard
Abuse check: kya-abuse-check
Scanner: agentscores.xyz/scan
Full API: agentscores.xyz/docs
GitHub: Thezenmonster/mcp-guard