Skip to content

App registry: inventory worker-built apps

An app registry is an inventory with one record per worker-built app, so IT can see which apps exist, who owns each one, what data it touches and when it was last reviewed. It covers agents and automations too, and each record names the owner as a role, the person in it and a named successor. Start with a spreadsheet and manual discovery, register sandbox workspaces once per builder, and make registering quick and worth doing: it should unlock hosting, sign-in or data access. No registry yet, and nobody to run one? Start with what to do if nobody owns this today.

Who this is for

IT managers, platform teams and security leads who need to know what apps exist and who answers for them. You get the minimum fields by tier, where to find unregistered apps, the registration flow, the health checks, and where to keep the registry and how to protect it. Reading time: about 8 minutes.

What must every registry record contain?

The app registry template has every column, says who fills each one (the builder, the intake form, a formula or a named role) and which tiers require it, and has CSV downloads. A builder types 12 core fields; the rest come from intake, formulas and reviewers. The groups below summarize the template, so you can see the load before you build anything; if they ever differ, the template wins. The tiers and the gate matrix stay on the risk-tiers page; the registry records their results.

Field group Sandbox Team Important Critical
Identity and purpose workspace ID, builder app name, purpose, team same same
Ownership the builder app owner (role and person), a named successor + named backup who has run the app, business and technical reviewers, data-owner sign-off for Confidential or Restricted data + security reviewer and a graduation plan
Tier and the six answers not needed until an answer rises above Sandbox tier, the six answers, the flags same same
Platform, hosting, data and users platform and private workspace + location, source, users, where secrets are held same same
Checks — an exposure scan's date and result, if IT scans Team apps + business review, technical check and exposure scan dates and result same
AI feature, agent identities and grants — if used (an extension sheet: version, trifecta check, eval threshold and last pass) if used if used
Downgrades, exceptions and floor breaches an open floor breach, with its fix-by date if used, with expiry or fix-by date same same
Status and dates status, attestation and re-attestation dates (the platform time-boxes each sandbox app to 90 days) + last review, next review, retire-by, kill criteria same + last quarterly access review
Support self-supported team-supported assisted, with a runbook link IT-supported
Audit, records and legal — the audit-scope flag, and the audit fields if yes (an extension sheet) + retention and disposal for every app same

Three fields carry more weight than the rest.

  • The owner is a role, the person in it, and a named successor. The role is the durable field: a person's name alone goes stale the day they change jobs (app ownership). The person is recorded by directory account, because that's what you match against leaver lists and identity-provider exports. Clear ownership is the outcome people using software catalogs say they want most, in vendor-originated research1.
  • Agent and automation identities. Record the identity an agent runs under and every grant, token, scheduled job and MCP server registration, with an owner role and, if it runs as a person, that person's account. An agent running on a person's own grant with no registry entry is the gap leaver handling misses (when the builder leaves). OWASP lists improper offboarding of non-human identities first in its 2025 list2, and in the 2025 Salesloft Drift token theft the advice was to revoke every token of the integration. A registry that lists every grant lets you find each one to revoke without a hunt.
  • The audit-scope flag and its fields. If the app produces control evidence, holds privileged access or touches financial reporting, the record gains the audit fields and the app is routed to the compliance owner. The flag never changes the tier (the audit-scope flag), and there's no minimum tier for audit-scope apps: the compliance owner's change-management and evidence requirements apply at whatever tier the app is, Team included.

How do I find the apps to register?

Assume you'll find most apps by hand at first. Start with sources every business has, and add automated sources when you have the tooling. Vendor guidance describes automated checks (a daily check for apps owned by former employees, inactivity notices and quarantine of non-compliant apps)3, but that vendor's starter kit is no longer maintained, and nobody has published how accurate automated population is. Adopt the capabilities you can run, and treat their accuracy as something to test (A-026 below).

Sources every business has:

  1. Spend and expense data. New subscriptions to AI app builders and automation tools often appear here first.
  2. Your identity provider's app list, if it has one: the applications people sign in to with company credentials.
  3. A one-off census: ask each team what it built or relies on, with an amnesty, as described in find the worker-built apps you already have. Repeat it yearly.
  4. Help-desk tickets that mention an app nobody in IT recognizes.

Sources some businesses have:

  1. A platform's admin inventory. Some AI app builders and low-code platforms list apps, owners and sharing settings on business plans; personal and low-tier plans often don't. Check what yours exports before you rely on it.
  2. Identity-provider reports of OAuth consent grants and service accounts, which show tools and agents nobody registered.
  3. Organization-level source hosting and cloud accounts: listings of repositories, deployed projects and hosted sites.
  4. An exposure scan of your own domains and storage, which finds apps on the internet that were never registered.

None of these can see an app on a builder's personal account, which is one reason for never-do 3 and why the census asks about personal accounts directly.

Depends on your circumstances (C5)

If nobody owns identity or access today, discovery is spend data plus the census. Don't plan around identity-provider reports until someone owns identity; the starter sequence covers the first 30 days.

How should registration work?

Registration is a form, not a queue. Two rules make people use it.

  1. Make it fast. The record the intake form creates is the registry entry. The builder types 12 core fields, and the form fills the answers and flags. Registration takes about 10 minutes once the form has skip logic (A-031); expect 15–20 minutes the first time.
  2. Make it unlock something. Registered apps get approved hosting, company sign-in, access to approved data, a help-desk route and a named place to ask for help. Unregistered apps get none of those. Workers route around friction4, so if registering is slower than not registering, you'll rebuild the shadow IT you started with.

Register a sandbox workspace once per builder, ideally created automatically by the platform. The workspace record holds the builder's attestation date and a re-attestation date; the platform enforces the 90-day time-box on each sandbox app. App-level registration starts the moment any answer rises above Sandbox: the first share, the first data beyond a Q1(a) answer, the first internet reach or the first write to anything shared.

How often is a record reviewed?

By tier: the cadence is in the operate gate. Don't copy it into registry rules; make the registry compute next_review_on from the tier and send the owner a reminder. A review re-answers the six questions, checks the owner, the person in the role and the successor are still current, and lists every grant.

What registry health checks should I run?

Run these on a schedule and publish the results to the enablement lead. They're how you find out the registry has drifted.

  • Orphans: apps whose app_owner_person is no longer an active directory account, or whose successor field is empty.
  • Leaver matches: every person field, and every grant that runs as a person, matched against the latest leaver and mover list.
  • Overdue reviews and scans: next_review_on in the past, or an Important or Critical app whose last_exposure_scan_on is older than your scan schedule.
  • Discovered but not registered: apps found by the sources above with no record.
  • Agent grants without an owner: grants and tokens in the identity provider that no record lists (where you have those reports).
  • Self-signed data use: a data-owner sign-off by the app's own owner, which separation of duties forbids.
  • Tier mix: the share of apps in Critical (we expect under 10%) and in Important or above (we expect 35% or less). If the share is higher, revisit the questions before adding review capacity (Critical means co-ownership).
  • Downgrade share: the share of Important and Critical answers on an owner-signed downgrade (standard downgrade 3 counted separately). If it's above about 15%, the questions are wrong (the downgrade path).
  • Open exceptions and floor breaches: exceptions past their expiry, and floor breaches past floor_breach_fix_by, where the as-found answer now applies.

Don't: run a registry that's only filled in by hand, or that takes weeks

Manual registries go stale, and a stale registry is worse than none because people trust it. Pair the fields discovery can see (owner, platform, sharing, grants) with an automatic check where you have one, and the yearly census where you don't, and report the discovery gap. An unreviewed spreadsheet in a decision path is a documented failure (AP17)5. And if approval is slow, builders skip it: publish the median registration time, and treat a long wait as a defect in the process.

Don't: let agents run on a person's grant with no entry

An agent without a registry entry can't be handed over, revoked or reviewed. It keeps working, or stays open, after its builder has gone (AP19)6.

Where should the registry live?

Start with the simplest place that works, and move when the volume or the audit needs justify it. Choose by capability, not by product.

Where Choose it when Limits
A shared spreadsheet or table with the template's columns You have no platform team and fewer apps than one person can review each quarter. The no-platform default Manual upkeep; no workflow or reminders unless you add them
An IT service management tool or configuration database You already run one for services and the help desk, so routing from the record is free Heavier to set up; keep the fields few so builders don't need a login to read it
A service catalog or developer portal You already run one and many apps are in version control Works best for apps built as code; needs a champion to keep it current

Protect the registry itself, wherever it lives. It lists every grant and token scope, where secrets are held, internal URLs, reviewers and the apps in audit scope, so it's a map for an attacker, and for audit-scope apps it's inventory evidence. Require company sign-in to open it. Edit rights: the enablement lead and the IT/platform owner edit the whole record; the other roles that fill fields (the app owner, the data owner, the business, technical and security reviewers, IT for scans, and the compliance owner) submit their fields through a form or a workflow step, or edit only their own columns; builders submit through intake. Turn on version history. Never store secret values. Restrict the AI and agents extension sheet more tightly than the rest if your tool allows it.

Depends on your circumstances (C7). If several business units already build independently, keep one registry schema and one tier model across them, and let each unit keep its own view.

Record where the registry lives

Record where the registry lives, once, using the decision record template.

Illustrative composite

Title: Keep the app registry in a shared table, seeded by a census and reconciled monthly · Status: accepted · Date: YYYY-MM-DD · Owner: enablement lead (a role)

Context. Staff build apps on several AI app builders and automation tools. Nothing records who owns them.

Decision. One shared table with the template's columns, seeded by a census and spend data, reconciled monthly by the enablement lead with the platform and identity exports the IT/platform owner adds. Registration is required for hosting, sign-in and data access. The table needs company sign-in; the enablement lead and the IT/platform owner edit the whole record, and other roles submit their own fields through a form; version history is on; it holds no secret values.

Alternatives considered. A configuration database (rejected for now: no one has time to set it up before the pilot). A manual list with no reconciliation (rejected: goes stale).

Consequences. We list owners, orphans and overdue reviews monthly, and move to the service-management tool if the table outgrows that or an auditor asks for workflow evidence.

Review by: six months from the date above.

Assumptions and evidence

  • A-001 (Low): we expect builders to register their apps if registration is quick and unlocks something they want; test this by comparing registrations with apps found by discovery.
  • A-031 (Low): we expect the intake form that creates the record to take under 10 minutes once it uses skip logic; test this by timing five builders.
  • A-026 (Low: vendor guidance only): we expect automated population, where you have it, to name owners and detect leavers accurately enough to rely on; until you've tested it, manual discovery is the default. Test this by comparing the registry's owner for 20 sampled apps with the owner each team names, each quarter.
  • A-044 (Low): we expect agent and automation identities to be inventoriable cheaply enough to support registration and leaver handling; test this by counting agents found running on grants with no registry entry.

Evidence: mostly vendor and government guidance, a standards-body risk list and incident reports; no independent, quantified post-mortem of an AI citizen-developer program, and no measurement of automated discovery's accuracy. Public-sector rules require an inventory of AI use cases and named accountability (OMB M-25-21)7; Singapore's government announced an agent registry that tracks owner, permitted actions and activity, reported by news only and early8. Facts on this page are as of October 2026.

  1. Spotify Backstage Insights, published via the CNCF (2022 research): the top desired outcome is to maintain clear ownership of software. https://contribute.cncf.io/techdocs/analyses/2023/backstage/insights-summary [vendor], accessed 2026-10-21. ↩

  2. OWASP, "Non-Human Identities Top 10" (2025), NHI1 Improper Offboarding. https://owasp.org/www-project-non-human-identities-top-10/ [primary], accessed 2026-10-21. ↩

  3. Microsoft, tenant hygiene guidance: a daily check for resources owned by former employees, inactivity notices and quarantine; the starter kit is no longer actively maintained. https://learn.microsoft.com/en-us/power-platform/guidance/coe/after-setup-tenant-hygiene [vendor], accessed 2026-10-21. ↩

  4. PagerDuty, survey report on unauthorized AI tool use at work (2026). https://s206.q4cdn.com/635206389/files/doc_news/PagerDuty-Report-Finds-Two-Thirds-66-of-Office-Professionals-Have-Used-Unauthorized-AI-Tools-at-Work-2026.pdf [vendor], accessed 2026-10-21. ↩

  5. Reinhart-Rogoff critique (2013): an unreviewed spreadsheet in a decision path, whose errors drove a policy debate. https://peri.umass.edu/publication/does-high-public-debt-consistently-stifle-economic-growth-a-critique-of-reinhart-and-rogoff/ [research], accessed 2026-10-21. ↩

  6. OWASP Citizen Development Top 10, CD-SEC-09 "Asset Management Failures" (2022; the orphan risk persists). https://owasp.github.io/www-project-citizen-development-top10-security-risks/content/2022/en/CD-SEC-09-Asset-Management-Failures [primary], accessed 2026-10-21. ↩

  7. Office of Management and Budget, memorandum M-25-21, "Accelerating Federal Use of AI through Innovation, Governance, and Public Trust" (3 Apr 2025). https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-21-Accelerating-Federal-Use-of-AI-through-Innovation-Governance-and-Public-Trust.pdf [primary], accessed 2026-10-21. ↩

  8. Malay Mail, "Singapore rolls out AI agent registry as govt expands use of artificial intelligence in public service" (2 Jun 2026). https://www.malaymail.com/amp/news/singapore/2026/06/02/singapore-rolls-out-ai-agent-registry-as-govt-expands-use-of-artificial-intelligence-in-public-service/222229 [news], accessed 2026-10-21. ↩