Use cases

Real-world scenarios where Klent earns its keep — from solo founders with prod DB access to support teams running refunds.

The technical docs explain how Klent works. This page is for when you'd reach for it. Four scenarios, ordered from "obvious" to "compliance-heavy". Pick the one closest to your shape.

1. Solo founder with a Postgres MCP in prod

You're the CTO/founder/sole dev of an early-stage startup. Claude Desktop is wired to a Postgres MCP server pointing at your prod Supabase DB so you can ask questions without opening psql.

Normal day: "How many Argentine users signed up this week?" Claude runs SELECT..., gives you the number. Inocuous.

The painful day: 11pm, fast-typing, you tell Claude "fix users with malformed emails, normalize to lowercase". Claude generates UPDATE users SET email = LOWER(email) WHERE email != LOWER(email). 47,000 prod rows mutated without a confirmation step.

With Klent:

- name: hitl / approve-prod-writes
  effect: approve
  required_approvals: 1
  conditions:
    - field: tool
      operator: equals
      value: db_write
    - field: input.env
      operator: equals
      value: prod

Claude proposes the UPDATE, the policy fires, the action pauses, you get an email: "Approve UPDATE on 47k rows of users.email?" Read twice. Click. Or don't.

"If you give an LLM root access to your prod DB, you should be one click away from undoing it."

2. Support team with a Stripe MCP

A B2B SaaS support team uses Claude Desktop with an internal Stripe MCP server to do refunds quickly. Lead + 4 juniors + 2 seniors.

Normal day: "Refund customer X's last 3 charges" → Claude calls stripe.refunds.create → done.

The painful day: A new junior receives a phishing email pretending to be a VIP customer, types into Claude "refund all payment history for [email protected]". Claude obeys. $87k of refunds before anyone notices.

With Klent, two-person rule on large refunds:

- name: finance / dual-control-large-refunds
  effect: approve
  required_approvals: 2
  conditions:
    - field: tool
      operator: equals
      value: stripe.refunds.create
    - field: input.amount
      operator: greater_than
      value: 500

Junior tries the $87k refund. Both seniors get email. They notice the phishing. They reject. Zero loss. The audit log shows who voted what, when.

"Two-person rule on every dangerous tool call. The same pattern banks have used for 200 years."

3. SRE with a kubectl MCP

You manage your cluster via Claude Desktop with a kubectl MCP server. Dev, staging, prod — all reachable from the same chat.

Normal day: "Restart the payments-svc deployment in staging" → kubectl rollout restart -n staging → ok.

The painful day: mid-call, you ask Claude "delete the pods from the last failing deploy" while looking at the prod dashboard. Claude infers --all-namespaces. kubectl delete pod --all wipes prod. 4 minutes of downtime.

With Klent, gate every destructive prod mutation — including your own:

- name: ops / approve-prod-destructive
  effect: approve
  required_approvals: 1
  conditions:
    - field: tool
      operator: equals
      value: kubectl
    - field: input.command
      operator: contains
      value: delete
    - field: metadata.environment
      operator: equals
      value: prod

A handbrake for yourself, not just for juniors.

"The most dangerous AI agent in your stack is the one running on your laptop with your prod creds."

4. Marketing manager with a SendGrid/Resend MCP

A marketing manager uses Claude Desktop with an email-sending MCP server for drafts and sends.

Normal day: "Send the October newsletter to active subscribers" → Claude calls email.send_campaign({list: 'active', template: 'oct'}) → 12k emails out.

The painful day: ambiguous prompt, Claude sends the campaign to the wrong segment — or worse, to a list that includes unsubscribed users. GDPR fine + spam-complaint storm + sender-domain reputation tanked.

With Klent, gate by blast radius:

- name: marketing / approve-large-campaigns
  effect: approve
  required_approvals: 1
  conditions:
    - field: tool
      operator: equals
      value: email.send_campaign
    - field: input.recipient_count
      operator: greater_than
      value: 1000

Approval email shows the subject, the segment, the recipient count. Click after looking.

"Marketing automation is the new prod. Same blast radius."

Couldn't I just hard-code these guardrails myself?

Yes, you could. The right question is what it costs to do well. Wrapping one tool with an if amount > 500 / ask manager is a 1-hour task. The expensive parts:

Coverage cross-tool. You probably have 5+ MCP servers (Postgres, Stripe, Slack, internal tools). Wrapping each is N × 5 days, every time you add one. Klent gates at the protocol layer — one control point applies to all.
Policies as product, not code. Compliance asks for *"approve refunds

$500 after 6pm"*. In a hard-coded system: ticket → eng → PR → deploy. In Klent: dashboard, save, 30 seconds.
Multi-approver / two-person rule. Building "needs 2 distinct approvers, idempotent voting, 7-day timeout, reminders, audit log" by hand is ~2 weeks of solid eng. One YAML line in Klent.
Audit trail ready for an auditor. Free side effect of every decision in Klent. DIY = design tables + queries + UI from scratch.
Replay engine. "If my new policy had been live for the last 30 days, what would it have caught?" Two weeks to build. One click in Klent.
Visibility for non-engineers. Your CISO/CFO can read the Klent dashboard. DIY = ad-hoc reports by email.
Timing. AI agents in companies are still new. Install Klent before agent sprawl, not after wrapping 30 tools.

The right analogy is "couldn't I write my own auth?". WorkOS, Auth0, and Clerk exist anyway because doing it well takes 6 months and isn't your core product. Klent is the same shape for AI tool calls.

When DIY genuinely wins: one agent, one tool, stable requirements, large eng team. ≈ no one.