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.
At a glance
What this is: This is an analysis of how SQL-backed applications without APIs can still feed identity governance by mapping users, roles, entitlements, and grants directly from relational databases.
Why it matters: It matters because IAM and IGA teams still need complete access visibility and control in hybrid environments where legacy systems and custom apps do not expose standard integration paths.
👉 Read C1.ai's analysis of SQL-powered identity governance without APIs
Context
Identity governance fails when critical access data lives in applications that do not expose standard APIs. In hybrid estates, that gap often shows up in legacy on-prem systems, custom applications, and database-backed workflows where users, roles, entitlements, and grants are only visible in SQL tables.
The core challenge is not simply reading a database. It is converting application-specific identity data into a governable structure that supports access reviews, entitlement visibility, and orchestration across systems that were never designed to integrate cleanly with modern IAM or IGA platforms.
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. That gives IAM and IGA teams visibility before they try to automate changes, which is the right sequence when legacy apps cannot expose standard integration paths.
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. When roles and entitlements stay buried in application-specific tables, recertification, orchestration, and access review coverage become incomplete, especially in hybrid estates with many bespoke systems.
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. If the transformation layer does not accurately translate the source schema, the IAM platform may present a clean-looking view that does not match the real access structure.
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.
Technical breakdown
How SQL-backed identity data becomes governable
SQL-powered connectors work by querying structured tables that already contain identity and access records, then mapping those records into a normalised schema for downstream governance. In this model, the connector does not need a public API because the database itself becomes the source of truth for users, groups, roles, entitlements, and grants. Configuration rather than custom code defines which queries run and how results are transformed. That shifts integration from application development to identity operations, which is why these connectors can be deployed more quickly in legacy environments.
Practical implication: treat database schema mapping as an identity governance control point, not just an integration task.
Why configuration-driven connectors reduce integration debt
A configuration-driven connector replaces per-application code with declarative instructions, often using YAML plus an expression language to transform query results. This matters because each custom connector creates maintenance overhead, upgrade risk, and a long-term dependency on developers. By contrast, a generic SQL approach can be reused across many internal applications even when each schema is different. That makes it easier to centralise access data without waiting for application teams to build or expose APIs.
Practical implication: use configuration-led ingestion where legacy apps would otherwise force one-off connector sprawl.
What changes when provisioning is optional rather than assumed
Read-only extraction and write-back provisioning are different governance modes. Read-only connectors improve visibility and review coverage, while provisioning adds the ability to orchestrate access changes back into the source system when the configuration allows it. That separation is important in SQL-backed applications because not every database should be managed the same way. The governance model must define whether the connector is there to observe, reconcile, or actively change access, and those decisions should follow application risk and operational maturity.
Practical implication: separate visibility use cases from provisioning use cases before exposing SQL-backed apps to automated access changes.
NHI Mgmt Group analysis
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.
Configuration-led ingestion is a stronger governance pattern than connector-by-connector engineering. A database schema can be mapped into a standard identity model without writing bespoke code for every application. That changes the economics of coverage in hybrid estates, where custom apps, on-prem systems, and packaged software all present different data shapes. The practical result is broader control reach with less dependency on application developers. Practitioners should favour repeatable ingestion models that make identity data portable across systems.
Unified identity governance depends on how well the organisation normalises access data, not on whether every app exposes an API. The article’s central point is that a queryable database can still participate in governance if users, roles, entitlements, and grants are translated into a common schema. That is especially relevant in enterprise environments shaped by M&A, legacy platforms, and mixed technology stacks. Practitioners should measure governance coverage by the completeness of identity data ingestion, not by API availability alone.
SQL-powered identity governance is becoming a standard response to integration debt in hybrid IAM programmes. The more diverse the application estate, the less realistic it becomes to rely on uniform application interfaces. This pushes identity teams toward connector models that can handle both API-driven and non-API systems without changing the governance objective. The strategic implication is that identity architecture increasingly needs data portability at the source layer, not just policy at the control layer. Practitioners should plan for database-native identity ingestion as part of their core IAM fabric.
Entitlement visibility is only as good as the schema translation layer. If the connector misreads application-specific tables or omits a grant relationship, the governance view becomes incomplete even though the database is technically connected. This makes transformation logic, field mapping, and query scoping part of the control plane. Practitioners should validate schema mappings with the same care they apply to access review design, because inaccurate translation creates false confidence in coverage.
From our research library:
- 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
What this signals
Identity visibility is increasingly a data integration problem. Hybrid estates rarely fail because identity policy is absent. They fail because the data needed to apply that policy sits in incompatible application structures, which makes access governance depend on integration design as much as on control design.
Schema translation is now part of the governance layer. When identity data is extracted from relational databases, the quality of the mapping determines whether downstream reviews and orchestration can be trusted. That shifts attention from API availability to the completeness and accuracy of the identity data model.
For practitioners
- 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.
- Validate schema mappings before trusting reports Test each connector against real table relationships and edge cases so entitlement and grant reporting reflects the source system accurately rather than a partial database view.
Key takeaways
- Legacy and custom applications can still block identity governance when their access data exists only in SQL tables and not in APIs.
- Configuration-based ingestion can broaden governance coverage without forcing one custom connector per application.
- The practical control question is whether identity data is being normalised accurately enough for review and orchestration to be reliable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CSA Cloud Controls Matrix, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article is about centralising identity data and access orchestration across cloud and hybrid apps. |
| Recommendation — Apply IAM governance controls to normalise identity data across connected applications. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The post focuses on discovering and managing entitlements and grants from SQL-backed systems. |
| Recommendation — Use PR.AA-05 to ensure entitlements from database-backed apps are inventoried and governed. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SQL-backed identity data still depends on lifecycle control of credentials and access records. |
| Recommendation — Apply IA-5 to govern credential and access record lifecycle in systems feeding IAM tooling. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | The integration challenge is a discoverability problem across apps and their identity data surfaces. |
| Recommendation — Use API9 to improve inventory discipline for application interfaces and data access points. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Database-backed app access often reflects excessive grants that need visibility and review. |
| Recommendation — Review overprivileged application access and reduce grants before exposing them to governance workflows. | ||
Key terms
- Identity Data Normalisation: Identity data normalisation is the process of reconciling identity records, entitlements, and context into a consistent structure across tools. It matters because fragmented identity data creates blind spots, slows decisions, and weakens automation in both human and non-human identity programmes.
- Schema-Driven Connector: A schema-driven connector is an integration pattern that uses the structure of a database or application model to extract and map identity data without custom code. It is especially useful for legacy or internal apps where APIs are missing, unstable, or too costly to build.
- Entitlement mapping: Entitlement mapping is the process of connecting data assets to the roles, groups, tokens, or accounts that can access them. It is a practical control step because it reveals hidden overreach and makes it possible to reduce access based on actual exposure rather than assumptions.
- Connector Sprawl: Connector sprawl is the uncontrolled growth of APIs, plugins, and integrations that an AI agent can use to reach enterprise systems. The more connectors an agent has, the larger the trust boundary becomes, and the harder it is to prove that each path is necessary, approved, and observable.
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
👉 The full C1.ai post covers Baton-SQL configuration, schema mapping, and deployment examples
Deepen your knowledge
NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org