Skip to content

How Gasket works

Follow a single refund through Gasket: who sends what, when a person is involved, and when the real system is finally touched. Eight messages, every one of them real API behavior.
Agent
Gasket
Person
System
  1. 01

    POST /v1/actions · stripe.refund.create · 240

    Key checked, agent found, environment and status checked.

  2. 02

    evaluate policy → rule 2: require approval > 50

    Action recorded as act_… with the rule and policy version. One usage unit charged.

  3. 03

    201 · status pending_approval

    The agent stops and tells the user it's waiting.

  4. 04

    approval.requested

    Shown in Approvals; sent to webhooks subscribed to it.

  5. 05

    Approve

    First decision wins. The action becomes authorized.

  6. 06

    GET /v1/actions/act_… → authorized

    Polled, or learned from a webhook. Free.

  7. 07

    refunds.create (agent's own key)

    Only now does anything happen in the real system.

  8. 08

    POST /v1/actions/act_…/result · succeeded

    The record now holds the request, decision, approver and outcome.

Where it fits

What Gasket is not.

Knowing the edges is how you know where to put it.

Not an agent framework
Keep LangGraph, the Agents SDK, your own loop, or Claude Code. Gasket is one HTTP call or one MCP server inside whatever you use.
Not a proxy to your systems
Gasket doesn't call Stripe or GitHub for you today. Your agent does, after Gasket says yes, with its own access.
Not a prompt guardrail
Gasket doesn't read model output for bad words. It decides on structured operations, with rules you can audit.
Not a log you reconstruct later
The decision is made and written before the action happens, with the rule that made it.

See it with your own request.

Free account, $0.50 of credit, five minutes.