A low-code app lets users act as its creator when it connects to a database or service with the creator's own embedded credentials. Every user's request then runs as that person, so users can reach data they should not, and logs show only the creator. Fix it with dedicated service identities and per-user checks.
What the pattern looks like
OWASP calls this Account Impersonation (CD-SEC-02). Creators embed personal credentials, shared service accounts or database connections to get quick access. Anyone using the app implicitly uses that identity.
OWASP's first scenario is simple. An analyst builds an app that views database records and logs into the database as themselves. Every action by every user queries the database as the analyst. A malicious user can view, modify or delete records they were never meant to touch, and the database logs show only the trusted analyst.
Why it is hard to see
- Audit trails point at one person, so the real actor is concealed.
- The creator may have broad access for their own job, which the app inherits.
- The same embedded connection can span several environments.
- Code assistants can produce login or session logic that looks fine but stores credentials weakly or creates service accounts nobody governs.
How to check an app
- Open the app's connection list and note the identity on each connection.
- Ask whether that identity is a person, a shared account or a dedicated service identity.
- Compare the identity's permissions with what the app needs.
- Ask whether the app passes the end user's identity downstream or always uses the stored one.
- Look at where form submissions are stored and whose account owns that storage.
OWASP's second scenario is a form app that saves responses to the developer's personal email account, so users have no idea where their data goes.
Choosing a better design
| Design | Result | Fit |
|---|---|---|
| Creator's personal login embedded | All users act as creator | Avoid |
| Shared team account | Shared blame, hard to audit | Avoid for sensitive data |
| Dedicated service identity, narrow scope | Clear actor, small blast radius | Good default |
| End user's own identity passed through | Per-user access and logs | Best when supported |
Where per-user pass-through is not possible, add authorization checks inside the app so each user sees only their own records.
What to put in policy
- No personal credentials in connections for apps with more than one user.
- Service identities have a named owner and a rotation date.
- Apps that store data name the owning account in the registry.
- A leaver's connections are reviewed the same week as their other access.
For the offboarding side, see personal login or service account for an automation connection.
Where Safeguard fits
Safeguard's agent identity capability gives AI agents their own identities rather than borrowed ones, which applies the same principle. Platform-hosted connections are still reviewed in the platform's admin console.
Quick check
Is a shared service account good enough?
It is better than a personal login but weak for audit, because actions cannot be tied to a person. Use a dedicated identity per app with a named owner.
How do I find embedded personal logins?
Export each platform's connection list and filter for connections whose identity is a named employee.
Sources
Last reviewed: 19 October 2026.
