Station70 · DevRel proposal

Gatekeeper

The policy engine is built. The developer on-ramp was never poured.

opencolin · collin@dabl.club · dabl.club (~85,000 developers) · 2026-07-17

A finished product with no front door.

0

That's how many ways a developer can try Gatekeeper today without booking a sales call. The strongest policy engine on the market is invisible to the people who would wire it in.

Deep product, sealed off.

3
integrated components: a policy engine, a zero-knowledge secrets vault, and an MCP gateway
12
conditions a policy rule can check — who's asking, what it costs, what time it is, whether a human approved
24
integrations already listed on the site — GitHub, Slack, Stripe, AWS, and more
0
public quickstarts, SDKs, or API docs — the missing front door

One thing you won't find in this deck: revenue, traction, or customer counts. None are public, so none are claimed — the pilot exists to measure the first real number.

Why now: two clocks, one window.

Whoever publishes the first credible agent-governance quickstart becomes the default. That slot is still open.

Gatekeeper is telling two different stories right now.

That's not a criticism — it's the opening. The new story doesn't have an owner yet. This proposal is an offer to write it.

The wedge: connected is not the same as allowed.

Every request an agent makes gets checked against policy in real time — who's asking, on what resource, at what spend, needing whose approval. The secret leaves the vault only for that one approved call, and every decision lands in an audit trail.

That's what raw OAuth tokens, tool gateways, and hand-rolled scripts don't do — and in Station70's own words, what password managers and enterprise PAM can't retrofit: "built for AI, not retrofitted from humans."

I didn't just read about the product. I ran it.

The demo writes itself: agent oversteps → blocked → human approves → done.

The honest read.

This is a trust product. Being this honest about it is the marketing.

The one number that matters.

Weekly active agents making calls through Gatekeeper that pass policy and complete — counted with extra weight when the call needed a human approval or a spend cap.

In plain terms: are real agents doing real, governed work every week? What we refuse to count: signups, connectors configured, page views, GitHub stars. And we won't quote a target until we've measured a baseline.

Seven programs, one job each.

The three that carry the weight.

Three phases, six releases.

Every release has one success number and a gate to clear before the next one starts. Nothing ships on vibes.

DevRel that feeds sales instead of replacing it.

This isn't an awareness play. It's a factory for the three things enterprise deals are missing today.

Developers don't replace the enterprise sale. They walk it in the door.

Two ways to buy, kept deliberately separate.

For scale: a full year-one DevRel build runs ≈ $1.6M; a leaner ramp ≈ $900K–1M. Managed services can make the whole motion pay for itself.

An audience on day one.

85k

developers at dabl.club, the audience I've built and run for years. Distribution most startups spend a year buying, available from week one — with every click traceable to an outcome.

Why Colin.

Any conflicts get disclosed before they start, and fees are always quoted separately from program budget. No surprises.

The ask: one small yes.

A one-month, $6,000 pilot: wire up the measurement, ship the five-minute quickstart, and report one honest number — how many developers actually got to a working governed call.

Small enough to approve without a committee. If the number is bad, you walk away with the data. If it's good, everything bigger is a renewal decision. First step: one 30-minute call.

Connected ≠ allowed. Let's pour the on-ramp.

collin@dabl.club · github.com/opencolin

Gatekeeper DevRel proposal · Station70 · 2026-07-17
1 / 18
← → to navigate · Esc for the full proposal