SQL-powered app identity governance without APIs: what changes

At a glance

What this is: This is an analysis of how Baton-SQL lets teams extract identity and access data from SQL-backed applications without APIs, with the key finding that database schemas can become integration points for IAM and IGA.

Why it matters: It matters because many IAM, NHI, and lifecycle programmes fail where authoritative access data sits in legacy apps, and practitioners need a way to bring those systems into governance scope without waiting on application rewrites.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read ConductorOne's post on managing SQL-powered app identity data without APIs

Context

SQL-backed applications often sit outside modern identity toolchains because they expose data through tables rather than standard APIs. In IAM and IGA terms, that means the source of truth for users, roles, entitlements, and grants can remain operationally invisible even when the business depends on it.

ConductorOne’s Baton-SQL addresses that integration gap by treating the database schema itself as an ingestion path for access data. For teams running hybrid estates, the broader issue is governance reach, not connector convenience: if access cannot be read reliably, it cannot be reviewed, recertified, or lifecycle-managed with confidence.

Key questions

Q: How should security teams govern applications whose identity data only exists in SQL tables?

A: Security teams should treat SQL tables as authoritative identity sources when no API exists, then ingest those records into the IGA or IAM control plane through a controlled connector. The key is to preserve the meaning of users, roles, entitlements, and grants so reviews, offboarding, and provisioning use current data rather than manual exports.

Q: What breaks when legacy applications cannot expose access data through APIs?

A: Visibility, certification, and lifecycle control break first. If an application’s access records remain trapped in a database schema, identity teams often fall back to spreadsheets, tickets, and DBA intervention. That creates stale access reviews, delayed revocation, and inconsistent entitlement reporting across the estate.

Q: When is read-only database ingestion better than enabling provisioning?

A: Read-only ingestion is better when the team is still establishing trust in the data model, ownership, and mappings. It lets practitioners centralise access data without immediately risking write-back errors. Provisioning should come later, after the connector’s output has been validated against known accounts and lifecycle expectations.

Q: How do SQL-backed apps affect non-human identity governance?

A: They often store service-account roles, application tokens, and machine-facing grants in the same database structures as human access data. That means NHI governance can fail even when the identity platform is mature, because the authoritative record is still outside the control plane. Teams need ingestion coverage, not just policy coverage.

Technical breakdown

SQL database identity ingestion without APIs

Baton-SQL uses configuration-driven extraction instead of application-specific code. Teams define SQL queries to pull resource, entitlement, and grant records from relational databases, then use CEL transformations to map those results into a common schema. That approach matters because legacy and homegrown applications often expose identity data only through tables, not API endpoints. By making the database queryable at the identity layer, the connector turns structured storage into a governance feed without requiring developers to rewrite the application.

Practical implication: identity teams can inventory SQL-backed apps as governable systems instead of exceptions waiting for API work.

YAML and CEL as the connector control plane

The connector’s behaviour is driven by YAML configuration and Common Expression Language rules. YAML defines what to query, and CEL reshapes the output into Baton’s expected model. In operational terms, this shifts implementation from bespoke coding to schema knowledge and controlled expression logic. The gain is repeatability, but the trade-off is governance quality now depends on how accurately the config reflects each app’s data model and how carefully the transformations preserve entitlement meaning.

Practical implication: treat connector configuration as identity logic that needs review, testing, and change control.

Read-only ingestion with optional provisioning

Baton-SQL runs read-only by default, which is the safer starting point when teams are first mapping access from databases. Provisioning can be enabled through configuration, meaning the same connector can support visibility first and action later. That design is relevant to IAM because many organisations need discovery, certification, and offboarding before they are ready to allow write-back. The control question is whether the connector’s scope matches the maturity of the programme using it.

Practical implication: start with read-only discovery and only enable provisioning where lifecycle ownership is already clear.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SQL-only identity sources create a governance blind spot, not just an integration inconvenience. When identity and access records live in relational databases without APIs, IGA tools can miss authoritative entitlement data entirely. That breaks visibility, certification, and offboarding workflows at the source. The practical conclusion is that any app outside the ingestion layer is also outside the governance layer.

Database schema awareness has become part of identity engineering. Baton-SQL shows that modern identity programmes cannot rely on developers to standardise every legacy application before governance begins. The connector pattern shifts responsibility toward teams that understand schemas, queries, and access semantics. Practitioners should treat schema mapping as an identity control surface, not a one-off integration task.

Configuration-driven connectors change the operating model for hybrid IAM. If DBAs can maintain access integrations themselves, identity programmes can scale into legacy estates that would otherwise remain manual. That does not remove governance risk, but it narrows the gap between authoritative data and the control plane. Teams should view this as a way to extend lifecycle and review processes into systems that have been operationally unreachable.

Database-exposed access data is a named governance concept worth tracking: identity ingestion debt. This is the backlog created when critical access data exists, but not in a form the identity platform can consume. The longer that debt persists, the more recertification, least-privilege review, and offboarding depend on spreadsheets and side channels. Practitioners should measure how much of the estate still sits behind this kind of ingestion debt.

SQL-backed applications matter as much for NHI governance as they do for human IAM. Service accounts, application roles, and machine-facing entitlements often live in the same databases as workforce data. That means database connectors can help close blind spots that affect both human and non-human identities. The implication is that hybrid identity governance should be built around data location, not around identity type alone.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• The governance problem extends beyond discovery, which is why NHI Lifecycle Management Guide helps teams move from visibility to revocation discipline.

What this signals

Identity ingestion debt: legacy SQL applications create a control gap when access data exists but cannot be consumed by the IAM stack. That gap will matter more, not less, as hybrid environments keep expanding and M&A continues to bring in unstandardised systems. Teams that do not inventory these blind spots will keep recertifying incomplete datasets and calling it governance.

With 90% of IT leaders saying properly managing NHIs is essential for a successful zero-trust implementation, per Ultimate Guide to NHIs, database-driven access data cannot stay outside the control plane. SQL connectors are not the end state, but they are a practical way to bring unreachable systems into review, lifecycle, and least-privilege workflows.

The broader signal is that identity programmes are becoming data integration programmes as much as policy programmes. When one source system still needs custom exports or DBA intervention, the programme’s effective boundary is smaller than the architecture diagram suggests. Practitioners should expect this pressure to increase across both human and non-human access estates.

For practitioners

• Map SQL-backed systems to governance scope Inventory every internal application whose authoritative access data lives in a relational database, then classify whether it feeds certification, provisioning, or both. Prioritise systems where the database is the only reliable source of users, roles, entitlements, or grants.
• Treat connector configuration as controlled identity logic Review YAML and CEL mappings the same way you would review access policy changes. Test query results against known accounts and entitlements before trusting them for recertification or downstream provisioning.
• Start read-only, then expand scope deliberately Use read-only extraction for initial visibility and only enable provisioning after ownership, rollback, and approval paths are defined. Keep the connector’s write capability aligned with the programme’s lifecycle maturity.
• Use database connectors to reduce manual recertification debt Target legacy apps that still require spreadsheet exports or DBA assistance for access reviews. Replace those manual paths with repeatable ingestion so reviews and offboarding can operate on current entitlement data.
• Extend lifecycle governance into non-API estates Apply the same joiner-mover-leaver and revocation checks to database-driven applications that you use for API-connected systems. Where the database is the access source of truth, the connector becomes part of your control plane.

Key takeaways

• SQL-backed applications can hide authoritative identity data from IAM and IGA programmes when APIs are absent.
• Configuration-driven connectors reduce integration friction, but only if schema mapping and entitlement semantics are governed carefully.
• Teams should use database ingestion to extend lifecycle, review, and revocation controls into legacy estates that were previously outside the control plane.

Key terms

• Identity ingestion debt: The accumulated governance gap that appears when authoritative identity and access data exists in systems the control plane cannot read directly. It shows up as spreadsheet exports, manual reconciliations, and delayed reviews, especially in legacy application estates and hybrid environments.
• Schema mapping: The process of translating database fields into a standard identity model that IAM and IGA tools can consume. In practice, it determines whether users, roles, entitlements, and grants are preserved accurately enough to support certification, provisioning, and offboarding workflows.
• Read-only connector: A connector that extracts data from a source system without changing it. For identity governance, read-only mode is the safest way to centralise access information first, then decide later whether controlled provisioning or revocation should be enabled.
• Entitlement semantics: The meaning carried by an access record, not just its raw value. A role, grant, or membership can represent different authority in different applications, so governance tooling must preserve context when normalising data from SQL tables into a shared identity model.

Deepen your knowledge

SQL-backed application governance and non-human identity visibility are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are bringing legacy databases into scope for reviews and lifecycle control, it is a useful fit.

This post draws on content published by ConductorOne: Managing Identity for SQL-Powered Apps: No APIs Necessary. Read the original.