Sentinel Agent

Inspiration

Two chronic pains on every engineering team live in Slack. First, status tracking is a tax — standups, "any update on X?", nagging people to move Jira tickets. Second, security problems hide in plain sight — someone pastes a package.json or an install command into a channel and nobody notices it pins a library with a known CVE. We wanted one agent that quietly solves both: track work from the signals people already produce, and catch vulnerabilities the moment they're mentioned.

What it does

Sentinel is an autonomous Slack agent that maps goals into tasks and guards your dependencies in real time.

• Goal breakdown — @Sentinel plan <goal> uses an LLM to split a high-level goal into a tracked task list (each job numbered from task-1).
• Passive git tracking — it watches your repo through the GitHub MCP server; creating a branch named after a task (feature/task-1) flips that task to in progress and credits the author. No manual updates.
• Live vulnerability audits — any pasted dependency, package.json, or requirements.txt is cross-referenced against the National Vulnerability Database via a purpose-built MCP server, then flagged in-thread with a severity-colored card (CVE id, CVSS score, fix version).
• One-click fix PRs — every alert has an "Open fix PR" button that branches, bumps the dependency to its patched version, and opens the pull request through the GitHub MCP server.
• Conversational Q&A — @Sentinel ask <question> answers grounded in the live task board plus relevant workspace messages retrieved through Slack's Real-Time Search API, citing its sources.
• Interactive task board, daily digest, and a personal App Home dashboard round it out.

How we built it

Node.js + Slack Bolt over Socket Mode (outbound-only, no inbound port). The planner and Q&A run on a pluggable LLM (Gemini or Claude). We lean hard on all three challenge technologies:

• MCP — a custom NVD MCP server (stdio) for CVE lookups, plus GitHub's hosted MCP server (streamable HTTP) for branch tracking and fix PRs.
• Real-Time Search API — assistant.search.context powers both passive chat-engagement tracking and the ask command.
• Slack AI capabilities — agent view, Block Kit, and the App Home tab.

State lives in SQLite (Node's built-in node:sqlite, zero extra deps). Deployed as a background worker on Render via Docker.

Challenges we ran into

• The obvious @modelcontextprotocol/server-github npm package is deprecated and has no list_branches tool — branch tracking silently didn't work until we switched to GitHub's hosted MCP server over HTTP.
• Slack's RTS action_token is ephemeral and must be used from the live event that produced it, not a stored one — we had to thread it through carefully.
• Our Q&A cited unrelated messages because RTS returns loosely-related hits; we fixed it with a citation-grounding protocol so only messages the model actually used are surfaced.
• Moving to SQLite exposed primary-key collisions (goals created in the same millisecond, per-goal task-1 reuse) that the old JSON store silently tolerated — solved with UUIDs and a hidden unique id behind the friendly task-N label.
• Picking the correct CVE fix version across multiple affected ranges (not just whichever appeared last).

What we learned

Practical MCP integration patterns (stdio vs hosted HTTP transports), the real constraints of the Real-Time Search API, how to ground an LLM's citations so it doesn't hallucinate sources, and how much Block Kit polish (colored severity cards, progress meters, confirm dialogs) changes how "real" an agent feels.

What's next

Richer git signals (PR merged → task done), transitive lockfile scanning, broader vuln sources (OSV, GitHub Advisory), and per-channel severity policy.

Built With

• anthropic-claude
• block-kit
• docker
• github-api
• google-gemini
• javascript
• mcp
• model-context-protocol
• national-vulnerability-database
• node.js
• real-time-search-api
• render
• slack
• slack-bolt
• socket-mode
• sqlite