Identity Resolution
SL-10Mapping database users back to the person behind them. Accountability under the Act runs to people, not to credentials — a service account running a mass read is only actionable once you know whose process it was.
8 database users cannot be attributed to a person
svc_reporting_3, svc_scheme_sync, svc_reporting_44, svc_scheme_sync_20, svc_notify_9, svc_notify_14, svc_warehouse_etl_2, svc_reporting_34. Until proxy identity mapping or application user context is configured, activity by these accounts cannot be tied to anyone — which means it cannot be investigated properly either.
Database users seen
67
High confidence
51
Weak or unresolved
16
Rows by unresolved users
4.91 L
Attribution confidence
Each account is rated by its weakest observed session.
- high51
- medium0
- low8
- unresolved8
How resolution works
Three mechanisms, applied in order of reliability.
- highApplication user contextThe application passes the end-user identity through with the connection. Highest confidence, requires application support.
- mediumProxy identity mappingThe connection pool records which enterprise identity requested each session. Reliable where the pool is instrumented.
- mediumFederated authentication tracesCorrelating database sessions with SAML or OIDC assertions by time and source. Works, but degrades under load.
- lowService account ownership registerA recorded owner for each machine identity. Not attribution of an action, but attribution of responsibility — which is what accountability actually requires.
67 database users
1–25 of 67
1 / 3