Topic starter
08/06/2026 5:07 pm
TL;DR: C1.ai says identity data trapped in SQL-backed legacy and custom applications can still block IAM and IGA programmes when APIs are absent, and Baton-SQL maps users, roles, entitlements, and grants directly from databases without custom code. The governing problem is not database access alone but bringing non-standard identity data into lifecycle control without connector sprawl.
Editorial analysis by NHI Mgmt Group, based on content published by C1.ai: “Managing Identity for SQL-Powered Apps: No APIs Necessary”.
Key questions
Q: What should teams do when identity data exists only in SQL tables and there is no API?
A: Start by inventorying the systems that hold users, roles, entitlements, and grants in relational databases, then map those fields into a common governance schema.
Q: Why does a lack of APIs create governance risk for legacy applications?
A: Because identity control depends on seeing the full access model, not just on authenticating users.
Q: What are the main failure modes of database-based identity integration?
A: The biggest failures are incomplete table mapping, missed grant relationships, and connector sprawl that nobody maintains.
Practitioner guidance
- Map SQL-backed applications into a governed identity schema Inventory legacy and custom applications whose access state lives only in relational databases, then define a consistent mapping for users, roles, entitlements, and grants so those systems can participate in IAM and IGA processes.
- Separate read-only visibility from provisioning logic Decide which SQL-backed applications should be monitored only, and which should support write-back access changes, because not every source system should allow the same operational mode.
- Reduce per-application connector sprawl Prefer configuration-based integrations over custom code when many internal apps share the same identity governance need, especially where developers are not available to maintain one-off connectors.
Bottom line: Legacy and custom applications can still block identity governance when their access data exists only in SQL tables and not in APIs.
What's in the full article
C1.ai's full post covers the operational detail this post intentionally leaves for the source:
- Sample Baton-SQL configurations for common database-backed applications
- The YAML and CEL mapping approach used to transform SQL query results into Baton schema
- How the connector is deployed in secure environments and where provisioning can be enabled
- The open-source repository, documentation, and example query mappings for implementation teams
👉 Read C1.ai's analysis of SQL-powered identity governance without APIs →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/06/2026 7:08 pm
SQL-backed applications expose an identity governance blind spot when APIs are absent. The governance problem is not that these systems are older, but that their access state is trapped in structures the IAM stack cannot easily consume. When users, roles, entitlements, and grants live only in database tables, identity visibility becomes application-specific rather than enterprise-wide. That leaves review, certification, and orchestration uneven across the estate. Practitioners should treat inaccessible identity data as a governance gap, not a technical inconvenience.
A few things that frame the scale:
- 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
A question worth separating out:
Q: When should organisations use SQL-based connectors instead of building custom APIs?
A: Use SQL-based connectors when the application is already queryable, the identity data is structured in tables, and the cost of engineering a bespoke API would slow coverage across many systems. That approach is most useful where the priority is fast governance reach across legacy and internal applications.
👉 Read our full editorial: SQL-powered app identity governance without APIs: what changes
This post was modified 4 days ago by NHI Mgmt Group