how do i evaluate a citizen developer platform for governance

Summary

• Evaluate a citizen developer platform by how it enforces governance, not by how easy it is to build: the test is whether every app a business user ships automatically inherits your existing identity, access controls, and audit.
• Insist that enforcement lives at the data engine, not in application code. If governance is something each app has to implement, a citizen developer can forget it or route around it; if it's enforced where the query runs, they can't.
• Require two things about identity: each app runs as its own governed principal, and the app can also act on behalf of the signed-in user after single sign-on, so each person sees only the data their permissions allow.
• Check the admin controls and audit trail: who can create and deploy apps, which permissions apps may request, and whether every action is logged with a clear identity.

how do i evaluate a citizen developer platform for governance

Judge the platform on one question: does every app a non-engineer builds automatically inherit the governance you already run, or does each app become a new place where access rules have to be re-implemented and can be forgotten? A governed platform gives each app a real identity, resolves data access against central permissions, keeps credentials out of app code, and records what happened, all without asking the builder to wire it up. The clearest signal is where enforcement happens. If row filters, column masks, and privilege checks run at the query engine, an app physically can't read around them; if they live in application logic, a citizen developer can skip them by accident. Evaluate identity, authorization, credentials, permission scopes, audit, and admin control, and treat "governed by default" as the bar.

What does governance mean for a citizen developer platform?

Citizen developers are business users and domain experts (analysts, operations leads, line-of-business teams) who build applications with low-code or AI-assisted tools rather than through traditional software engineering. That's the point: they understand the problem and shouldn't have to know Git, CI/CD, or infrastructure. Governance is what keeps that speed safe. It means the apps they ship stay inside the same access controls, identity model, and audit trail as every other workload touching your data, so a business user building an app can't accidentally expose data they were never allowed to share. Without it, citizen development becomes a sprawl of ungoverned tools holding copies of sensitive data.

Key governance criteria to evaluate

Score any platform against these before you trust it with production data. Describe the criteria; the vendor names are beside the point.

Governance criterion	What to require
App identity	Each app runs as a governed principal with explicit grants, not an anonymous process holding a static key.
Per-user authorization	After single sign-on, an app can act as the signed-in user, so data resolves to that person's permissions.
Unified authorization engine	One central layer decides access for apps, notebooks, dashboards, and agents alike, with no separate app data path.
Non-bypassable enforcement	Privilege checks, row filters, and column masks run where the query executes, so app code can't route around them.
Credential management	The platform vends connection credentials; secrets never live in application code.
Scoped least privilege	Apps declare the permissions they need, and admins can cap which permissions are grantable.
Audit trail	Every action, by the app identity or a user, is logged with clear attribution for compliance.
Admin control at scale	Admins govern who can create and deploy apps and can apply policy to many apps at once, not one review at a time.

How Databricks Apps approaches governance

Databricks Apps is built so governance is inherited, not rebuilt per app.

• Two identities per app. Databricks creates a service principal for each app to handle shared tasks like scheduled jobs and logging, and you grant that principal only the Unity Catalog privileges it needs. The app can also authorize on behalf of the signed-in user after single sign-on, so sensitive screens resolve to each user's own permissions. See app authorization.
• Unity Catalog is the authorization engine. Every read and write goes through Unity Catalog, which applies GRANT and REVOKE, row filters, column masks, and attribute-based policies at the SQL engine. Apps can't bypass it, and the same rules cover notebooks, dashboards, and agents.
• Credentials stay out of code. The platform injects the app's credentials at runtime and manages connection secrets, so builders never handle them.
• Scopes enforce least privilege. An app declares the OAuth scopes it needs and users consent; an app scoped only for SQL access can't reach other services even if the signed-in user could. Workspace admins can restrict which scopes are available.
• Actions are audited. App and on-behalf-of user actions are captured in audit logs, with the system.access.audit system table as the record for compliance.
• Admins govern creation and set policy at scale. Entitlements control who can create and deploy apps, and App Spaces let admins define resource access, data access, and permitted scopes once so every app in the space inherits them.

FAQs

What's the most important governance question to ask?

Where enforcement happens. If access controls run at the query engine, apps built by non-engineers inherit them automatically and can't route around them. If governance is left to application code, every app is a chance to get it wrong.

How does a governed platform give business users access without oversharing?

By resolving data against identity. The app runs as its own principal for shared work and, for user-specific views, acts on behalf of the signed-in user, so each person sees only what their permissions allow, enforced centrally.

Do citizen developers have to configure security themselves?

They shouldn't. On a governed platform the controls are inherited: Unity Catalog applies permissions, row filters, and column masks at query time, credentials are managed by the platform, and admins set what apps may request.

How do admins keep control as the number of apps grows?

Through entitlements and group- or space-level policy. Admins decide who can create and deploy apps and can define access and permitted scopes once for a whole set of apps, so governance scales without a per-app review bottleneck.