An AI agent deleted a production database last week. The HN post got 860 points. FlowLink is a Show HN response that implements interception at the Model Context Protocol (MCP) layer. It sits between agents and tools to block destructive commands before they execute.
FlowLink operates as a protocol-level proxy. You reconfigure your agent’s MCP client to point at FlowLink instead of directly at your tools. FlowLink parses every tool call, applies policy rules, and either forwards the call, blocks it, or queues it for human approval. The agent continues to operate without modification.
MCP Protocol Interception Point
MCP defines a JSON-RPC protocol for tool calls. When Claude Code wants to execute a shell command, it sends:
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "execute_command",
"arguments": {
"command": "rm -rf /var/lib/postgres"
}
}
}FlowLink intercepts this before it reaches the actual tool server. The Shield Engine parses the arguments object and runs pattern matching against 100+ destructive command signatures. If it matches rm -rf, DROP TABLE, git push --force, chmod 777, or similar patterns, the call is blocked or routed to the approval queue.
The proxy responds to the agent with one of three MCP-compliant responses:
Safe command (forwarded):
{
"jsonrpc": "2.0",
"result": {
"content": [{"type": "text", "text": "Command output here"}]
}
}Blocked command:
{
"jsonrpc": "2.0",
"error": {
"code": -32000,
"message": "Command blocked by Shield Engine: destructive pattern detected"
}
}Pending approval:
{
"jsonrpc": "2.0",
"result": {
"content": [{
"type": "text",
"text": "Command queued for approval. Queue ID: abc123. Waiting for human decision."
}]
}
}Pattern Matching Without False Positives
The Shield Engine uses a multi-layer detection system:
Command structure parsing: Tokenizes shell commands and SQL statements to understand intent, not just string matching. rm -rf ./temp is different from rm -rf /.
Context-aware rules: A DROP TABLE in a migration script might be safe. The same command in an ad-hoc query is high-risk. FlowLink checks the tool name, agent identity, and execution context.
Allowlist overrides: You can mark specific patterns as safe for specific agents. If your CI agent needs to run git push --force on feature branches, you define a rule scoping that permission.
The implementation is built in Rust with native MCP protocol support.
Policy Engine Architecture
The source describes per-agent, per-tool rules. Example: “Claude can read but not delete.” Policies control:
- Agent identity (which LLM or coding assistant)
- Tool scope (which MCP tools this applies to)
- Action rules (allow, block, require_approval)
- Conditions (pattern matching, argument constraints)
The policy format is not documented in the source material. FlowLink evaluates policies to determine whether to forward, block, or queue each command.
Approval Queue Mechanics
When a command requires human approval, FlowLink sends a notification via Telegram and waits for a decision. The agent receives a pending status immediately. FlowLink holds the MCP connection open while waiting for approval.
Async model: The agent’s MCP client waits synchronously for the response. FlowLink maintains the connection state and returns the final result (approved execution or rejection) once a human decides. If no approval arrives within the configured timeout, FlowLink closes the connection with an error response.
Failure modes: If Telegram is unreachable, FlowLink blocks the command and logs the failure. If the approval database is down, all require_approval commands are blocked until recovery.
Audit trail: Every approval request, decision, and timeout is logged with full context. Logs include the agent identity, the command, the approver identity, and the timestamp.
Zero-Trust Token Scoping
Agents never receive raw credentials. FlowLink issues scoped, time-limited tokens instead. The source describes this as a zero-trust secrets model.
Token lifecycle:
- Agent requests access to a tool (e.g., Postgres)
- FlowLink checks policy: does this agent have read or write access?
- FlowLink generates a scoped token with limited permissions
- Token is valid for a limited time window
- Token is passed to the tool on the agent’s behalf
- After expiration, the token cannot be reused
Scope examples:
- Database token:
SELECTonly, specific schema - Git token: read-only, specific repository
- Cloud API token: list resources, no delete permissions
The agent never sees the token. FlowLink holds it and injects it into tool calls transparently.
Deployment Shape
FlowLink runs as a self-hosted binary. The source claims setup takes 2 minutes and works with Claude Code, Cursor, Copilot, and any MCP-compatible agent.
Deployment options:
- Sidecar: One instance per agent, running on the same host
- Centralized proxy: One instance for all agents, with network routing
- Per-environment: Separate instances for dev, staging, prod
The MCP protocol is stateless, so the proxy can scale horizontally. If you run multiple instances behind a load balancer, approval queue state must be shared via an external store like Redis or Postgres.
Configuration: You install the binary, write a config file, and point your agent’s MCP client at the proxy instead of the real tool servers.
Trade-offs and Failure Modes
| Aspect | Benefit | Risk |
|---|---|---|
| Transparent proxy | No agent code changes | Single point of failure for all tool calls |
| Pattern matching | Catches known destructive commands | Misses novel attack patterns |
| Approval queue | Human oversight on high-risk ops | Latency kills agent autonomy |
| Scoped tokens | Limits blast radius | Token rotation adds complexity |
| Rust performance | Low overhead per call | Smaller ecosystem for plugins |
Known failure modes:
- Policy bypass: If an agent can call a tool directly (network routing misconfiguration), the proxy is bypassed entirely.
- Approval fatigue: If too many commands require approval, humans start rubber-stamping without review.
- Pattern evasion: An agent could obfuscate a destructive command (e.g., base64 encoding) to bypass regex matching.
- Token leakage: If the agent logs the tool response and the response includes the token, the token is exposed.
Observability Hooks
FlowLink provides a full audit trail of every agent action. The source mentions end-to-end encryption (E2EE) for sensitive data in transit.
You can monitor:
- Tool call patterns
- Block rate
- Approval queue depth
- Command execution history
The audit trail is queryable and includes the full MCP call payload for debugging.
Technical Verdict
Use FlowLink when:
- You run AI coding assistants (Claude Code, Cursor, Copilot) with access to production systems
- You need a fast, low-friction guardrail without rewriting agent code
- You want centralized policy management across multiple agents
- Your tool calls are infrequent enough that proxy latency (typically 5-20ms per call) is acceptable
Avoid FlowLink when:
- Your agents already run in sandboxed environments with OS-level restrictions
- You need sub-millisecond tool call latency (high-frequency trading, real-time control systems)
- Your threat model includes agents that can bypass network proxies
- You want guardrails that inspect the agent’s reasoning process, not just the tool calls
The MCP proxy approach is a practical middle ground. It is not a replacement for sandboxing, least-privilege IAM, or code review. It is a speed bump that catches the most common destructive commands before they execute. The approval queue adds human oversight without requiring agents to understand approval workflows.
The zero-trust token model is the most interesting piece. By never giving agents raw credentials, you limit the blast radius of a compromised agent. If an agent is tricked into exfiltrating data, it can only exfiltrate what its scoped token allows.
The main risk is policy bypass. If an agent can reach tools directly, the proxy does nothing. You need network-level enforcement (firewall rules, service mesh policies) to ensure all tool traffic flows through the proxy.