AccessGuard AI

An autonomous AI security analyst in Slack that stops risky access before it becomes a breach—reviewing requests across 5 MCP servers with explainable, one-click decisions.

Comment

Inspiration

Every IT admin answers the same question a dozen times a day: "Should this person get this access?" It sounds simple, but answering it properly means jumping between HR, the identity provider, the SIEM, the ticketing system, and a pile of policy docs. Most real breaches don't come from clever attackers — they come from access that shouldn't exist: a contractor with no MFA, an admin account nobody de-provisioned, a "temporary" grant that never expired.

I wanted to collapse that entire workflow into a single question you ask in Slack — and to find out how far the Model Context Protocol (MCP) could go for real multi-system orchestration.

What it does

AccessGuard is an autonomous AI security analyst that lives in Slack. Ask it "Should Rahul receive Production Database access?" and it decides — on its own — which systems to query, gathers the facts across five MCP servers (HR, IAM, Audit, Ticket, Policy), computes an explainable risk score, and replies with a recommendation, reasoning, confidence, and one-click Approve / Deny / Grant Temporary / Investigate buttons. It also runs investigations, finds admins without MFA, and lists temporary access expiring today — via @mentions, slash commands, an Assistant panel, and a Home-tab dashboard.

How I built it

  • TypeScript monorepo (npm workspaces): a Slack Bolt app (Socket Mode) plus five independent MCP servers built on the official MCP SDK.
  • The agent is a pure MCP client — it never touches the database. Every fact comes from an MCP tool call.
  • An autonomous tool-calling loop: the LLM (via OpenRouter) is given all ~40 MCP tools and decides which to call and in what order. The reply shows the real tool-call trace.
  • A deterministic risk engine does the scoring, exposed as a tool the agent must call:

$$\text{score} = \min!\Big(100,\ \max\big(0,\ \textstyle\sum_i w_i\big)\Big)$$

where each $w_i$ is a fixed weight (no MFA +30, foreign login +25, contractor +20, manager approval −20, …). The LLM writes the narrative and picks tools, but it can never invent the number — so a Critical risk can't be talked into an "approve."

  • SQLite via Node's built-in node:sqlite (zero native dependencies), seeded with a believable ~30-person org.

Challenges I ran into

  • Keeping the AI honest. Making the agent genuinely autonomous without letting it hallucinate a risk score was the core design tension. The fix — treating the deterministic engine as a mandatory tool and overriding any score the model returns — is the thing I'm most proud of.
  • OpenRouter only implements the Chat Completions API, not the newer Responses API, so I had to rewire the reasoning layer to work with both providers.
  • Tooling friction: pnpm was blocked by machine permissions (fell back to npm workspaces), and native SQLite builds are painful on Windows — Node's experimental node:sqlite (behind a flag) saved me.
  • Slack's newer surfaces (Assistant container + Home tab) needed manifest changes, new scopes, and a reinstall to light up.
  • Deployment was the real slog. Fly.io and Railway now require a credit card. I landed on Render's free tier, which meant adding a tiny HTTP health server (Socket Mode opens no port), plus an uptime pinger to stop the free instance from sleeping — and it's memory-tight running six Node processes at once.

What I learned

  • MCP is a genuinely clean way to model federated enterprise systems — swapping a mock for a real backend is just a new server behind the same tool contract.
  • The most trustworthy AI decision is one where the AI doesn't actually make the decision. It gathers evidence and explains; a deterministic engine owns the verdict.
  • Slack's agent surfaces (Assistant, Home tab, Block Kit) are more capable than I expected.

Honest limitations & what's next

  • The five MCP servers currently share one seeded SQLite dataset — they demonstrate the orchestration pattern, not five separate production backends. The natural next step is backing each with a real system (Okta, Workday, Splunk, ServiceNow, and an OPA-style policy engine) behind the identical tool interface.
  • Data is mocked (~30 employees) for a reliable demo.
  • Because it uses Socket Mode on a free host, it needs to stay running; a production deploy would be properly hosted and scaled.
  • Next up: conversational in-thread follow-ups ("why?", "now check his manager"), access-recertification campaigns, and anomaly detection on the audit stream.

Built With

Share this project:

Updates