App Inventory in Entra
You review your app inventory in entra by auditing registered apps and enterprise service principals. This review shows which external tools and internal workloads hold permissions in your tenant. Teams often set up directory roles to track user logins and group assignments. Still, broad directory roles can leave internal databases and servers exposed to risky commands. How app inventory in entra works Every tool that talks to your directory creates two core identity objects. The first object
Just-in-Time Access + Microsoft Entra ID (Azure AD): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You review your app inventory in entra by auditing registered apps and enterprise service principals. This review shows which external tools and internal workloads hold permissions in your tenant. Teams often set up directory roles to track user logins and group assignments. Still, broad directory roles can leave internal databases and servers exposed to risky commands.
How app inventory in entra works
Every tool that talks to your directory creates two core identity objects. The first object is the global app registration, which defines the base profile. The second object is the local service principal, which lives inside your specific tenant. Your team grants roles and permissions to that local service principal object.
When an engineer or script logs in, the directory checks the service principal. It verifies the assigned user group, the role, and the basic sign-in rules. Admins review these records to find unused tools, expired secrets, and broad tenant permissions. A clean directory list helps you spot old registrations and remove stale user assignments.
Teams also check consent logs to see which users approved third-party tools. If a tool asks for broad read or write scopes, admins can revoke that grant. Regular checks keep your tenant directory clean and limit who can sign in.
Why directory checks are not enough for runtime safety
Directory inventories solve the first half of the security problem. They tell you which apps exist and which users can log into them. They also show when a user or workload last requested an identity token. This visibility is vital for basic identity governance and compliance audits.
Still, the directory stops watching as soon as the login step finishes. Once an engineer or workload gets a valid token, it opens a direct session. The directory cannot see the database queries or shell commands that run next. A valid login role does not stop someone from dropping a production table.
Just-in-Time Access + Microsoft Entra ID (Azure AD): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Shared database roles and broad server keys make this blind spot much worse. Multiple apps or team members often share one back-end database user account. When something breaks, your server logs only show the shared account name. You cannot tie a specific SQL statement back to the person who ran it.
Closing the gap between identity and runtime actions
To fix this, teams must link directory identities to every live command and query. You should verify the user identity on each request, not just at login time. Instead of handing out static database passwords, map directory groups to granular runtime rules.
Teams also need controls that inspect traffic while the session is active. If a query returns sensitive fields like emails, phone numbers, or card numbers, masking rewrites matched fields in results. High-risk commands should pause and wait for a peer to approve them first. This approach turns static directory records into active runtime protection for your systems.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between an app registration and an enterprise app?
An app registration is the global definition of a software tool. An enterprise app is the local service principal instance inside your tenant that holds permissions.
How often should teams audit their directory app list?
Most security teams review their tenant list at least once every quarter. You should remove unused service principals, rotate expiring secrets, and revoke broad consent grants.
Can directory roles restrict specific SQL queries inside a database?
No, directory roles only control who can log in and get a token. They do not inspect or block individual SQL statements during an active database session.