Security Guide · v1.7.5 Preview

Faraday-Gate — MCP Security Proxy

Faraday-Gate sits between your agent and every other MCP server you run. It spawns and proxies your existing tool servers, scanning every tool schema and every call before anything reaches VEKTOR memory — no changes to how you already work.

The problem

Every MCP server you connect is a trust decision. A tool's description and schema can change between sessions without you noticing — a supply-chain rug-pull. A poisoned web page or document your agent reads can plant instructions in memory that activate later, in a future context, when you least expect it. Research on agent memory corruption shows attack success rates above 80% with less than 0.1% data poisoning — you do not need to corrupt much of the memory, you need to corrupt almost none of it.

How Faraday-Gate solves it

Faraday-Gate initialises as part of the VEKTOR MCP server. On startup it reads your claude_desktop_config.json and spawns every other MCP server listed there as a child process — your file systems, databases, APIs, anything else you run, all proxied through Faraday-Gate before anything reaches memory.

Layer	What it does
`L0 static scan`	Every tool name, description, and input schema is scanned against a signature library the moment a server connects. CRITICAL severity blocks the tool outright, HIGH severity flags it.
`Phase C tool pinning`	SHA-256 hash of each tool's schema stored on first connect. A hash mismatch on reconnect means the server changed its tools since last time — a rug-pull alert, and the tool is blocked.
`Canary tokens`	Synthetic facts injected into memory at session start. If one appears in an outbound call, an exfiltration attempt is in progress.
`Taint propagation`	Compromised data labels are tracked across the memory graph — any memory derived from a tainted source inherits the taint, keeping contamination traceable.

Transparent proxy

From your agent's perspective, nothing changes — the same tools are available, the same calls work. Every interaction simply passes through Faraday-Gate's checks first.

The gate queue — human approval for high-risk actions

Some threat classes are not binary. Faraday-Gate cannot block them outright without also blocking legitimate behaviour, so instead it holds them. When a high-risk action is detected, it is queued with a gate_id and held for review rather than executed or blocked.

MCP Tool	Purpose
`faraday_status`	Returns the current session state — active threat log, canary status, gate queue, corpus info.
`faraday_update_goal`	Declares or updates your session's stated intent. Faraday-Gate uses this for semantic drift detection — a tool call that deviates from the stated goal gets flagged or gated.
`faraday_approve_action`	Approves or denies a gated action by its `gate_id`. Nothing fires without sign-off.

example

vektor mcp faraday_update_goal --goal "summarise Q2 sales notes"
# later, a tool call tries to read your email archive — flagged as drift
vektor mcp faraday_status
# shows the gated action and its gate_id
vektor mcp faraday_approve_action --gate_id abc123 --approve false

Audit trail

Every intercept, gate event, goal update, and session boundary is written to a persistent local SQLite database. The audit trail exists independently of whatever your agent framework logs — useful when reviewing what happened after a session, or for compliance reporting.

What Faraday-Gate does not protect against

Faraday-Gate addresses manipulated tool schemas, environment-injected instructions, and memory exfiltration attempts through outbound calls. It does not address attacks that happen before a session starts, attacks targeting model weights directly, or social engineering of the human operator — those need other defences. VEKTOR's local-first architecture does most of the heavy lifting on exfiltration risk: if your memory store never leaves your machine, there is nowhere for a poisoned instruction to exfiltrate to in the first place.

Getting started

Faraday-Gate ships in the v1.7.5 Preview build. Upgrade from v1.7.4 at any time:

bash

npm install -g ./vektor-slipstream-1.7.5-preview.tgz

Faraday-Gate initialises automatically when you start the MCP server — no config changes required to get the L0 scan and tool pinning running. The gate queue and goal tracking are opt-in: call faraday_update_goal at the start of a session to enable drift detection, or skip it and Faraday-Gate still runs without a goal to compare against.

Next steps

See Multi-Agent Systems for how Faraday-Gate fits into pipelines using the Collab Model Registry, the FAQ for common questions, or download the v1.7.5 Preview to get started.