DEV Community: Tang Weigang

AgentLock's First Test Should Be Provenance, Not Prompt Filtering

Tang Weigang — Wed, 22 Jul 2026 02:06:38 +0000

Disclosure: This article was prepared with AI assistance and checked against the linked Doramagic project page, manual, and upstream README. It is an independent engineering interpretation, not official AgentLock documentation.

The tempting AgentLock demo is easy to write: put an injection in a web page, ask the agent to send an email, and check whether the call is blocked. That demo misses the more important variable. The same tool call can be safe or unsafe depending on where its parameters and session context came from.

The current upstream README models that variable explicitly. Context items are classified as authoritative, derived, or untrusted. The gate then combines three controls:

a session write-gate that blocks consequential writes after untrusted context enters;
parameter lineage that checks whether tool arguments trace to untrusted material;
deferred commit that re-decides consequential actions against the complete session provenance.

That is a better first test than comparing two prompt strings.

Install the package in a disposable environment and record the version before reading any benchmark result:

python -m pip install agentlock
python -m pip show agentlock

Then register a fake high-risk tool, such as send_email, and authorize the same call twice. In the first session, write only a user instruction and record the decision. In the second, add a web page or email as session context before authorizing the identical parameters. Keep the tool call text constant. The expected difference, if the policy covers the path, should be explained by provenance rather than wording.

The surrounding Doramagic manual gives a useful decision vocabulary for this test: ALLOW, DENY, and DEFER. DEFER is not a flaky failure. It is the outcome that says the current policy cannot safely decide without a reviewer or a higher tier. Treating it as an implicit allow is an integration bug.

There is a version trap here. The Doramagic manual documents an AgentLock v1.2.1 reference snapshot with 847 tests and a 99.5/A benchmark grade. The current upstream README lists v1.5.0, whose highlights include grant basis, execution confirmation, provenance on denials, and deferred-resolution logging, with 1141 tests. Those are different evidence snapshots. Record the installed package version and read the matching upstream release notes before making a security claim.

The README is also unusually direct about limits. A write-gate cannot stop persuasion achieved in model text without a tool call. It does not cover every harmful read. And selective action-class gating is only as sound as the trusted tool registrations behind it. A tool left undeclared can become an unreviewed gap; a tool classified too conservatively can make benign workflows unusable.

My acceptance record has six fields: package version, policy hash, session provenance, tool/action class, decision and reason, and receipt or replay result. “The injection was blocked” is a useful observation, but it is not a deployment proof. The useful question is whether the decision can be reproduced after the policy, context, and tool registration are inspected.

Sources:

Doramagic project page: https://doramagic.ai/en/projects/agentlock/
Doramagic manual: https://doramagic.ai/en/projects/agentlock/manual/
Upstream repository: https://github.com/webpro255/agentlock

The First Letta Run Should Test Memory Isolation, Not Just Recall

Tang Weigang — Tue, 21 Jul 2026 00:34:28 +0000

An agent remembering a detail is a demo. The first useful Letta test asks where that detail was stored, which session can read it, what tools share the boundary, and how the state can be removed.

There is a version trap before the first command. The upstream README says this repository contains the legacy Letta server and that active development moved to letta-ai/letta-code. The current CLI path is Node.js 22.19+ plus:

mkdir -p /tmp/letta-trial
cd /tmp/letta-trial
node --version
npm install -g @letta-ai/letta-code
letta --help

That is not the same installation as the Python repository snapshot, whose pyproject.toml reports letta 0.16.8 and Python >=3.11,<3.14. The Agent SDK is a third surface and can target cloud, local, or self-hosted backends. I record the exact surface and backend before interpreting any result.

My first run uses synthetic or disposable data and one test identity. I capture the provider/model, agent and session identifiers, memory write/read behavior, tool permissions, sandbox mode, and what remains after cleanup. A coherent answer is not evidence that memory is isolated. A successful tool call is not evidence that the same policy applies across the CLI, SDK, and server.

The Doramagic manual separates provider compatibility, hierarchical memory/data, agents/tools/sandbox, and server/REST API. That is a useful debugging order. Provider failures belong to one gate; cross-session state leakage belongs to another; MCP refresh or tool configuration belongs to another. Repeating prompts until the transcript looks right only hides which gate failed.

The project page keeps community evidence visible: reports involving encrypted Bedrock or VLLM credentials, cross-session memory poisoning, MCP schema/refresh behavior, context compaction, and provider error handling. These are review inputs, not a blanket security verdict. They are enough to justify a disposable first run before real data or a primary configuration directory enters the system.

My acceptance packet contains the install command, runtime/version, exact product surface, provider/model, test data location, raw output, memory boundary, failure log, and rollback action. “It remembers me” is the start of the test, not the end.

Manual: https://doramagic.ai/en/projects/letta/manual/

Upstream: https://github.com/letta-ai/letta

Browser-use's Real Risk Surface Is the Browser Session

Tang Weigang — Mon, 20 Jul 2026 02:20:25 +0000

The first browser-use test should not be “can the agent click the button?” It should be “what exactly did the agent get permission to see, change, and reuse?”

The project has three different surfaces: the Python library (Agent, Browser, ChatBrowserUse), Browser Use CLI 2.0 for coding agents, and the lower-level Actor API (BrowserSession, Page, Element, Mouse). CLI 2.0 uses a persistent daemon and direct Chrome DevTools Protocol communication. That can reduce orchestration overhead, but it also makes the daemon socket, session history, browser profile, and local process permissions part of the security review.

My first run is deliberately boring:

python -m venv .venv
source .venv/bin/activate
pip install browser-use
python -c "from browser_use import Agent, Browser, ChatBrowserUse; print('imports ok')"

Then I use a disposable profile and a test account for one read-only navigation. I keep the final URL, page title, model output, and any file or JavaScript action as evidence. A page opening is not proof of task correctness.

The version boundary matters. The manual records that v0.12.5 stopped installing litellm as a core dependency after a supply-chain incident. v0.12.8 added owner-only Unix socket permissions and refused evaluate() on restricted browser profiles. A copied tutorial that says “install everything and reuse Chrome” is hiding two decisions you still need to make.

The useful failure split is also concrete: blank Chromium can be a missing key or wrong model; stale imports are a documentation/version problem; Ollama empty structured output is a model compatibility problem; canvas hover may require a different action surface. Treating all of those as “browser automation is flaky” loses the diagnosis.

Manual: https://doramagic.ai/en/projects/browser-use/manual/

Your MCP Config Can Be Risky Before Any Tool Runs

Tang Weigang — Sat, 18 Jul 2026 23:56:06 +0000

Your MCP Config Can Be Risky Before Any Tool Runs

An MCP server does not need to execute a tool to create an operational problem. A local config can already expose a listener, carry a plaintext token, grant *-shaped tool scope, or pull an unpinned package.

ai-agentic-mcpscan turns that pre-runtime surface into a report. Its mcpscan CLI discovers local MCP servers, audits several agent-host config formats, scores exposure, credential hygiene, tool-scope breadth, and version pinning, and can emit JSON, HTML, or SARIF 2.1.0.

The useful first command is deliberately boring:

mcpscan inventory
mcpscan scan --root ~/project --json report.json --sarif results.sarif

Inventory tells you what the host appears to contain. Scan tells you which config facts deserve attention. Start in a disposable checkout and read the report before changing the host. The default static path is offline and read-only; --online is an explicit OSV/PyPI enrichment decision, not a harmless flag.

The mutation boundary is also explicit. mcpscan --fix is limited to selected over-broad tool-scope grants and backs up each file. It does not invent a secret manager or choose a safe package version for you. That is the right asymmetry: scope can be narrowed mechanically, while credential rotation and pin selection require context.

My acceptance rule is three artifacts, not one green command: the exact commit and Python version, the redacted report, and a before/after comparison showing the backup and the scope change. A clean static report still says nothing about runtime behavior, prompt injection, or whether the upstream project fits production.

This is an independent Doramagic reading of IRsoctierDT/ai-agentic-mcpscan, not a security certification. Source and manual: https://doramagic.ai/en/projects/ai-agentic-mcpscan/manual/

Tags: ai, security, mcp, devtools, python, opensource, codequality, devops

An MCP Server Is Not Safe Just Because It Started

Tang Weigang — Sat, 18 Jul 2026 00:03:42 +0000

The first useful question after adding an MCP server is not “did the process start?” It is “what did the host actually expose, and what can I roll back?”

modelcontextprotocol/servers is a reference-server monorepo covering filesystem, memory, git, fetch, everything, sequential thinking, and time. That makes it a map of MCP surfaces, not a production safety certificate. Doramagic lists npx -y @modelcontextprotocol/server-memory as a first entry point, but an install command is not runtime or permission evidence.

My first-use check is deliberately boring: create a temporary host configuration, use no real credentials, verify the host transport and Node/Python runtime, then read back the tools, resources, and prompts the host actually discovers. Test one allowed action, one out-of-scope action, and a rollback to the previous configuration. Record the package/version, host, allowed paths, observed capabilities, and failure output.

The boundary matters most for filesystem and repository-facing servers. “It can read a file” is not acceptance unless the allowed root, denied path behavior, and recovery path are recorded. Doramagic has recorded source, Quick Start, and sandbox-install checks for this pack; community evidence still needs a refresh, so this post does not claim every server/host/version combination works.

Project page: https://doramagic.ai/zh/projects/servers/
Manual: https://doramagic.ai/zh/projects/servers/manual/
Upstream: https://github.com/modelcontextprotocol/servers

Disclosure: this is an independent Doramagic resource package, not an upstream release, endorsement, or security certification.

Your AI Coding Policy Needs a Receipt, Not Just an AGENTS.md

Tang Weigang — Thu, 16 Jul 2026 23:43:28 +0000

An AGENTS.md file can explain a rule. It cannot prove that an agent saw the rule, that a proposed action was evaluated, or that a rejected change left a usable recovery trail. That is the useful question behind coding-ethos.

coding-ethos splits the problem into policy, agents, hooks, and code intelligence. coding_ethos.yml describes the mechanics; ETHOS.md and the coding-ethos standards carry the values; AGENTS.md and CLAUDE.md describe agent contracts. The hooks runner receives lifecycle events, routes them to the relevant evaluator or MCP tool, and normalizes the result.

The v0.3.0 line is interesting for three concrete reasons: policy extension seams let downstream rules plug in without rewriting the compiler; routing is centralized instead of duplicated in every hook; and remediation evidence is persisted in the code-intel store. A denied action should be testable as a structured verdict plus a remediation payload, not just a red log line.

My first-use check is deliberately small: run uvx coding-ethos against a disposable repository, exercise one allowed action and one denied action, read the rule id and evidence payload, retry after remediation, then remove the temporary configuration and verify rollback. A visible MCP tool list is not proof of enforcement, and a legacy path that bypasses hooks/runner can silently drop evidence.

The Doramagic pack also records community reports about Bubblewrap provisioning, git amend policy, MCP stdio coverage, and agent-proxy work. Those are source-backed checks to revisit, not claims that Doramagic reproduced every issue. Project notes: https://doramagic.ai/en/projects/coding-ethos/manual/

Disclosure: this is an independent Doramagic capability pack, not an official coding-ethos release or endorsement.

agent-workspace-linux Is Not Computer Use: Verify the Workspace Boundary First

Tang Weigang — Thu, 16 Jul 2026 01:33:36 +0000

Most computer-use failures start before the model acts: the agent is operating inside the user's real browser, clipboard, focus, or files. agent-workspace-linux takes the opposite route. It creates an agent-owned Linux desktop backed by Xvfb and openbox, with a separate browser and clipboard.

The first run should be boring and observable. Install the Linux dependencies from the upstream README, then run agent-workspace-linux doctor. Use workspace start --dry-run before workspace start --ack-hidden-workspace --purpose "QA run". Open the viewer, launch one test app, save workspace observe --screenshot --output /tmp/ws.png, and finish with workspace stop.

Do not call the viewer a security boundary. --permissions or AGENT_WORKSPACE_PERMISSIONS is the hard ceiling for networks, mounts, and apps; without bubblewrap, those policies may only be declared. The project is pre-1.0, and issues #21 and #22 cover live-control and clipboard risks. I would use it first for GUI QA or disposable browser profiles, not production credentials.

Project: https://doramagic.ai/en/projects/agent-workspace-linux/
Manual: https://doramagic.ai/en/projects/agent-workspace-linux/manual/
Upstream: https://github.com/agent-sh/agent-workspace-linux

Independent Doramagic resource pack; not an official upstream release or endorsement.

Sverklo Is Not Just Grep with Embeddings: Verify the Code-Memory Evidence Chain

Tang Weigang — Wed, 15 Jul 2026 01:57:05 +0000

Many coding agents do not fail because a model forgot a sentence from the previous chat. They fail because the agent has no context layer that can explain where a code fact came from, how wide it applies, and whether it is still fresh. Sverklo is interesting as an engineering hypothesis: a local-first MCP server that combines repository indexing, symbol graphs, dependency tracing, diff-aware review, and persistent memory. The useful question is not whether it sounds like an intelligent search box. It is whether an agent can receive repository context that a human can replay and verify.

The upstream entry point is npm install -g sverklo, with Node.js >= 24 as the stated runtime. A successful install only proves that the CLI can be found. It does not prove that the index is complete, that the current repository is being served, or that the MCP client is calling the intended tool. I would start in a disposable test repository instead of binding the first run to a production workspace or the global registry.

I would make the first acceptance run observable at four layers. First, file discovery: does the index include the expected paths, honor ignore rules, and produce a plausible file count after reindexing? Second, code structure: can lookup find a known symbol, and do refs, deps, and impact return relationships rather than a list of filenames? Third, context delivery: does the context tool provide a useful onboarding bundle, and does a supplied token budget produce a smaller PageRank-pruned repository map? Fourth, the memory ledger: can a memory with a project scope, kind, related file, and time metadata be recalled, and does changing that file make the memory visibly stale?

Sverklo is not described as a single vector retriever. The Doramagic manual maps its retrieval surface to BM25 keywords, ONNX embeddings, and a PageRank symbol graph fused across signals. Search hits expose found_by, which gives the operator a way to tell whether multiple retrievers agree. There is an important boundary here: exact strings still belong to Grep/Read. Sverklo is better suited to exploration, dependency graphs, refactor blast radius, and semantic questions. Sending every query through embeddings would make the workflow less predictable and contradict the server's own MCP guidance.

An acceptance script can stay small and repeatable:

Create a temporary repository with a few modules, a test, a README, and one intentionally broken dependency.
Run sverklo init, register the project, and wait for indexing. Record the Node version, project name, index timestamp, and file count.
Call context for onboarding and pass a small budget; check whether the returned map actually contracts with the budget.
Use lookup on a known symbol, then use refs, deps, and impact to trace callers, dependencies, and change scope.
Write one file-pinned decision with remember, edit that file, and inspect sverklo://context or recall for an explicit stale signal.
Run review_diff on a small change and confirm that the result contains both readable Markdown and structured findings with path, line, and severity anchors.

The lifecycle is where a seemingly healthy setup can mislead an automation. Sverklo stores registered projects in ~/.sverklo/registry.json. The manual records issue #74: reindex can finish while leaving lastIndexed stale, so the timestamp in sverklo list is advisory rather than proof that the current index is fresh. After reindexing, automation should register again or read the index status and file evidence directly. Issue #73 reports that unregister takes the internal project name, not an absolute path. A worktree cleanup script should therefore resolve the name from sverklo list before unregistering.

MCP naming has another quiet production boundary. Sverklo already exposes internal sverklo_ tool prefixes. If a host also prefixes tool names using the server key, a name such as sverklo_sverklo_impact can appear. A connected badge is not enough. After integration, enumerate the tools and make one real call to context, lookup, or status so the host's names and response shape are verified.

My operator rule is to treat Sverklo as an observable local code-context candidate, not as an agent brain that becomes trustworthy after installation. Before putting it in a real workspace, retain four kinds of readback: index scope and freshness, symbol/dependency results, stale-memory behavior, and structured diff-review output. Without those artifacts, the only defensible claim is that the CLI started.

This is an independent Doramagic capability pack, not an official Sverklo release or endorsement. Project page: https://doramagic.ai/en/projects/sverklo/; Human Manual: https://doramagic.ai/en/projects/sverklo/manual/; upstream: https://github.com/sverklo/sverklo.

OpenViking Is Not Just a Memory Folder: Verify Hierarchical Context Delivery First

Tang Weigang — Tue, 14 Jul 2026 01:32:42 +0000

OpenViking is interesting because it puts memory, resources, and skills behind one file-system-shaped context model for agents. That is a useful hypothesis, but an installation that completes does not prove the context database is ready to hold real agent memory.

The documented entry point is pip install openviking. I would still start in an isolated directory with three traceable fixtures: one short memory, one resource file, and one skill description. After ingestion, check whether the directory hierarchy and URI remain stable. Then compare a shallow retrieval with a deeper retrieval and inspect how much context is actually delivered at each level. The question is context delivery, not whether a demo returned one similar chunk.

The project frames its design around a file-system paradigm, hierarchical context delivery, and self-evolving context. That creates three concrete engineering questions: can the hierarchy express relationships between resources, does retrieval move from summaries to deeper evidence, and what happens when a new memory conflicts with an old one? A single successful search is not evidence that long-term memory is safe.

The upstream issue trail gives useful first-run boundaries. A reported openviking-memory.ts autoRecall bug needs reproduction; a malformed memory can poison a semantic queue; and multi-user memory isolation needs an explicit test rather than an assumption. I would not start with real conversations or treat self-evolution as trusted automatic writes. Use synthetic records with an owner, source, and timestamp so isolation and rollback are observable.

My first acceptance sequence would be: install openviking; confirm Python and host compatibility; ingest one memory with source and owner fields; run one shallow and one deep retrieval; revoke or delete that record and query again; then inject one malformed record and check whether the failure is isolated instead of stopping the whole processing queue. Save the command output, returned URI, retrieved text, and error response at every step.

The evidence boundary matters. The Doramagic capability pack supplies a quick start, manual, context pack, pitfall log, and eval route. It does not prove that OpenViking was installed or run on this machine. OpenViking also does not replace a permission model, tenant isolation, retention policy, or human correction loop.

My operator rule is to treat OpenViking as an observable context-database candidate, not as an automatic replacement for an agent's memory layer. It earns a real workspace only after hierarchical retrieval, provenance, user isolation, revocation behavior, and malformed-data recovery are all recorded.

This is an independent Doramagic capability pack, not an official OpenViking release or endorsement. Project page: https://doramagic.ai/en/projects/openviking/; Human Manual: https://doramagic.ai/en/projects/openviking/manual/; upstream: https://github.com/volcengine/OpenViking.

Notion MCP: Verify Page Access Before You Trust the Tool List

Tang Weigang — Mon, 13 Jul 2026 01:28:36 +0000

The first failure mode in a Notion MCP integration is rarely a missing tool. It is assuming that a visible tool name implies access to the whole workspace. makenotion/notion-mcp-server exposes the official entry point npx @notionhq/notion-mcp-server, while the independent Doramagic capability pack puts page access checks, workspace boundaries, and tool verification before any serious workflow.

I would treat the first run as a permission-routing test, not as a successful plugin installation. Start with a temporary workspace or test page. Confirm that the host points at the intended MCP server, confirm that the Notion integration has access to that page, and prove the access with a read-only call. A page visible in the Notion UI is not evidence that the integration token can read it.

The source map gives a useful debugging route. src/init-server.ts and scripts/start-server.ts describe startup; src/openapi-mcp-server/mcp/proxy.ts maps the OpenAPI description into MCP tools; src/openapi-mcp-server/openapi/parser.ts handles tool parsing; and src/openapi-mcp-server/auth/ plus client/http-client.ts define authentication and request boundaries. When a tool appears but a call fails, inspect the layer: host configuration, auth, OpenAPI translation, or the Notion API's permission response.

My first verification sequence would be deliberately small: run npx @notionhq/notion-mcp-server only through the documented entry path, read one test page, compare the returned page id with the expected id, then try one minimal update. Record the actual response and the page permission state after every step. Do not use a team knowledge base, private pages, or a production integration token as the first test fixture.

There is an important evidence boundary here. The pack does not prove that Notion MCP has been installed, run, or successfully called on this machine. Its quick start, Human Manual, and eval files are routes for validation, not runtime output. The pack also flags configuration, installation, runtime, and permission risks, so the official quickstart should be reproduced in an isolated environment. A process that starts is not proof that the target page is readable, and readable is not proof that an agent can safely write.

My operator rule is simple: give the agent one test page first, then expand the grant. Put the page id, workspace, integration permission, and exact error response into the acceptance record. Only connect a working knowledge base after read, minimal write, and revoked-permission failure are all observable.

This is an independent Doramagic capability pack, not official Notion documentation or an endorsement. Project page: https://doramagic.ai/en/projects/notion-mcp-server/; upstream: https://github.com/makenotion/notion-mcp-server.

Graphiti Is Not Just Another RAG Layer: Keep Time and Provenance

Tang Weigang — Sun, 12 Jul 2026 03:59:32 +0000

The hard part of agent memory is often not retrieving a similar sentence. It is deciding whether that sentence is still true. Graphiti approaches the problem as a temporal context graph: entities, relationships, and facts carry validity windows, and facts can be traced back to the episode that produced them.

That changes the first engineering question. A preference, project configuration, customer relationship, or operational state can be true today and replaced tomorrow. A vector-only retrieval path can still return the old statement because it is semantically close. Graphiti combines semantic retrieval, BM25 keyword matching, and graph traversal, then keeps a path back to the source node used in the result.

I would not treat it as a drop-in memory plugin. The official entry point is pip install graphiti-core. The quickstart also involves a Neo4j or FalkorDB connection, index and constraint initialization, episode ingestion, and hybrid search. A wrong database name, driver URI, LLM endpoint, embedding model, or cross-encoder setting can turn an infrastructure mismatch into a misleading “memory did not update” symptom.

The ontology surface matters too. Graphiti supports custom Pydantic models, while its MCP server includes typed entities such as Requirement, Preference, Procedure, Location, Event, Organization, and Document. That schema is part of the extraction and query contract. It is not a decoration to add after the first demo.

My first verification pass would stay isolated: install the package; prove the Neo4j/FalkorDB connection and database name; add one episode with a known timeline; run a hybrid query; and verify that the result can be traced to its source node and distinguished from a superseded fact. Until write, retrieval, provenance, and contradiction behavior are observable, I would not connect production conversations or a real agent host. The Doramagic pack flags installation and permission risks as high-priority checks for exactly this reason.

This is an independent Doramagic capability pack, not official Graphiti documentation or an endorsement. Project page: https://doramagic.ai/en/projects/graphiti/; Human Manual: https://doramagic.ai/en/projects/graphiti/manual/; upstream: https://github.com/getzep/graphiti.

FastMCP: tool discovery is not authorization

Tang Weigang — Sat, 11 Jul 2026 00:45:39 +0000

FastMCP makes it easy to expose Python functions as MCP tools, resources, and prompts. The production question is not whether a client can discover a tool, but what that discovery is allowed to trigger.

My validation order is deliberately boring:

Start with a side-effect-free function and verify server, client, and host discovery.
Test input/output contracts, authentication, timeouts, exception mapping, and recovery.
Only then consider filesystem, network, credential, or production-write permissions.

A working protocol path is evidence that the transport works. It is not evidence that the permission model is safe. Each real tool needs a bounded capability, a reproducible example, and a failure case that has been observed.

Project: https://doramagic.ai/en/projects/fastmcp/
Human manual: https://doramagic.ai/en/projects/fastmcp/manual/
Upstream: https://github.com/PrefectHQ/fastmcp