Of Record

For security and IT leaders at companies where everyone builds

An approved connection for every app your people build.

Your rules go into every builder's agent, so what they build already fits your stack. Before their app reaches a database, Salesforce or any internal system, the owner of that system approves it, and the app gets its own scoped credential.

Book a demo
  • Runs in your cloud
  • Behind your SSO
  • Works with Claude Code, Cursor, Codex
Register of connectionsEmployee-built apps and the systems they reach. As found.
Example: five employee-built apps, the system each one reaches, who approved it, and the access it uses. The example animates from unapproved to approved.
App reachesApproved byAccess
Discount desk → Salesforcenobodya rep’s own permissions, copied
Invoice reconciler → NetSuitenobodypasted token, no scopes
Call digest → Gongnobodytoken of someone who left in March
Ticket triage → Slacknobodyadmin bot, every channel
Lead enrichment → HubSpotnobodytoken committed to the repo
Awaiting approvalApproved and scoped: 0 of 5

Heard in discovery

In their own words.

From our interviews with the people who end up answering for these apps. Roles and company sizes are real. Names are withheld. Translated from Hebrew.

Someone built a dashboard and shared it with people from the business and CS. He used his private token. It doesn’t scale.

Platform director, 700-person company

If I build a dashboard on my Salesforce access and he sees what I built, is that fine or not fine?

R&D AI lead, 300-person company

There were loads.

AI transformation lead, 500-person company, after a sweep for personal API keys. Nothing was done.

The problem

Approved by nobody.

Building is no longer the hard part. An app someone built last Tuesday now reaches Salesforce on a pasted token, a person’s own permissions, or an admin account. No one approved that access or scoped it, and it keeps working after the builder leaves. Most teams find out from one of four messages.

Exhibit A

The token.

Your endpoint scan finds a personal BigQuery token inside a dashboard someone built and shared with the whole CS team.

Exhibit B

The bill.

Finance asks who spent three thousand dollars on tokens last month. Nobody can say what it did.

Exhibit C

The departure.

Someone in Finance built the reconciliation tool only they understood. They left in March. It still runs on their key.

Exhibit D

The rewrite.

Someone built a working portal at home in Claude and asks IT to bring it in. Identity, the database, permissions and security were never part of it, so it gets rebuilt from scratch.

Introducing

Of Record

Every app your people build is built on your rules, reviewed by the people you name, and kept in one register. Every connection it makes is approved by the owner of that system and runs on the app’s own credential. The app stays your code, in your cloud.

How it works

Four entries in the record.

Builders never open a console. Their agent gets two tools, init and deploy. All four entries happen on the way.

Entry 1

Build on your rules

Your stack, architecture principles, identity provider and data rules go into every builder’s agent. The agent warns and adjusts while they build, so the app already fits and nothing has to be rewritten.

Entry 2

Ship by risk

Automated checks run before every deploy. A team tool with no sensitive data takes the green lane and ships on its own. Sensitive data or in-app permissions send it to the reviewers you name.

Entry 3

Approve every connection

The owner of each system approves what the app reaches, with exact scopes. The app gets its own credential, or each viewer’s own access, so a shared app shows people only what they can already see.

Entry 4

See the whole portfolio

One live register replaces the spreadsheet: every app, its owner, users, data and cost. When a builder moves on, ownership passes before their access does, and anything can be switched off.

What the builder seesClaude Code
> Start a discount approval tool for the sales team
  init "Discount Approval Desk"
✓ Your rules applied: auth, data, integrations
✓ Declared: Salesforce (per-user), Gong (shared)
! Gong access requested from Shira G. on Slack

> Ship it
  deploy
✓ Secrets scan
✓ Agent config: CLAUDE.md, .mcp.json, hooks
✗ Rule: never log customer PII
  fixed by the agent, re-running
✓ Live behind Okta at discount-desk.tools.yourco.com
  • Deploys into your cloud, behind your SSO
  • Works with Claude Code, Cursor and Codex over MCP
  • The app stays your builder’s code, never imported
  • Review lanes by risk, approval chains per system

The research

135 apps in five months. One person watching them.

That was one company we sat down with. These are the numbers the others showed us.

18months

How long one builder set their personal API keys to last. A sweep at the same company later found loads of them. Nothing was done.

Field interview
1connected app

In one company’s Salesforce, everything people ran through Claude showed up as a single app called “Claude.” Nobody could tell who did what.

Field interview
3engineers

Of time nobody budgeted. One company estimated each builder spends half an hour a day keeping their tools alive. At 50 builders, that adds up to three full-time engineers.

Field estimate, our arithmetic
2×the leak rate

Commits co-written with Claude Code leak secrets at twice the GitHub baseline. Your builders are using it today.

GitGuardian, State of Secrets Sprawl 2026

19 interviews16 companies60 to 1,600 employeesAugust to October 2026Names withheld

Form OR-3 · Self-check

Could you answer these about your company today?

  • How many apps are running, and who owns each one?
  • Whose credentials does each one use to reach your systems?
  • Who approved that access?
  • What happens to an app when its builder leaves?

If any box stays empty, that is where we start. We work through all four with you on the call.

Book a demo

Questions on file

Before you book.

Do builders have to change how they work?

No. They keep Claude Code, Cursor or Codex. Their agent gets two tools, init and deploy, and builders never open a console.

What about apps people already built at home, in Claude or Lovable?

They come in through the same door. Each one is entered into the register and run through the same checks, and the builder’s agent gets the list of what has to change before it can ship.

Does every app need a full review?

No. You set the lanes. A team tool with no sensitive data ships on its own. Anything with sensitive data, permissions inside the app or a public address goes to the reviewers you name, such as architecture, DevOps and security.

Who approves a connection?

The person who owns that system. You set a chain per system: CRM requests go to the CRM owner, financial systems to finance, and anything not on your approved list to IT and security. Requests arrive on Slack or email.

How much will my team have to maintain?

You set the rules once and review what crosses a line. Builders and their agents handle the fixes. The register shows what every app does, who uses it and what it costs, so nothing runs as a black box.

Where does it run?

In your own cloud account, behind your own identity provider. The apps deploy there too, at an address on your domain.

We already have an MCP gateway. Is this the same?

A gateway sees the calls an agent makes. We cover the app the agent builds: which systems it connects to, on whose credential, and who approved it.

Is it available today?

We’re early. On the call we show the product on examples from your own setup, and tell you plainly whether it fits.

Enter your connections into the record

See it on your own apps.

We map your apps to the systems they reach, then show you the product on your own examples. If there is no list yet, that is the first finding.

Book a demo
  • Live product
  • With a founder