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 answer to agent governance — and no front door.

0

Public quickstarts, SDKs, or API docs found on any Station70 property. The strongest policy story on the market is sitting behind a contact form. That zero is the entire DevRel opportunity.

The one scoreboard — product-shape facts only.

3
integrated components — policy engine · zero-knowledge vault · MCP gateway
12
policy dimensions one deny-by-default rule can key on
24
named downstream integrations on the page
0
public developer on-ramps — the gap this proposal closes

No traction, funding, or customer figure appears anywhere in this proposal — those are instrument, never invented. To a security buyer, a candid zero beats a soft claim.

Why now: two clocks, one window.

Whoever publishes the first credible agent-governance quickstart sets the default teams reach for.

The company is mid-pivot — and nobody owns the story.

Showing up now with docs, a quickstart, and one coherent developer narrative isn't decorating a finished story — it's writing it.

The wedge: connected ≠ allowed.

Every agent request is evaluated in real time against a stacked, deny-by-default policy — twelve dimensions, org over user — the secret released from a zero-knowledge vault only as a scoped, time-bound injection for that one call, high-blast-radius actions escalated to a human quorum, every decision in an audit trail.

Not raw per-service OAuth, not a convenience-first tool gateway, not DIY policy — and in Station70's own frame, not a password manager or enterprise PAM: "built for AI, not retrofitted from humans."

Field notes: proof-of-work, not promises.

The demo writes itself: agent exceeds scope → denied → human-approved → succeeds.

Honest read.

The category is trust — candor is the marketing.

One north star.

Weekly active agents completing policy-evaluated calls through Gatekeeper — calls that pass both the org policy stack and the user policy stack and complete successfully — weighted toward approval-gated and spend-capped calls.

Refused vanity metrics: signups, connectors configured, registered agents, page views, GitHub stars. Every baseline is instrument — measured once live, never asserted.

Seven initiatives, each bolted to a lever.

The load-bearing three.

Program roadmap: three arcs, six releases.

One non-vanity KPI and one exit gate per release — no release ships on vibes.

DevRel that pre-sells revenue.

Not a top-of-funnel awareness play — a proof factory feeding the existing sales-led motion.

The developer motion doesn't replace the enterprise sale. It feeds it.

An audience on day one.

85k

developers at dabl.club — an owned, attributed acquisition channel Colin already operates. Instant top-of-funnel most startups spend a year building.

Two commercial frames — kept separate on purpose.

Full 12-month build ≈ $1.6M; startup-friendly ramp ≈ $900K–1.0M. The managed-services upsell turns the motion self-funding.

Why Colin.

Conflict disclosure up front; fee and program budget always quoted as separate lines.

One yes.

Scope the pilot: a one-month, $6,000 fractional engagement that stands up the activation instrument, ships the flagship "connect your first downstream service through Gatekeeper in 5 minutes" quickstart, and reports one honest activation number.

Small enough to approve without a committee. Self-terminating on a measured baseline. The first move is one 30-minute call — everything larger is a renewal decision made after the number exists.

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