A platform is not enforcing identity controls if one user can create unlimited agents, post as another account, or leave secrets accessible in a shared store. Inflated agent counts, unexplained content, and token exposure are all symptoms that the application cannot reliably separate human action from machine identity. Those are governance failures, not just bugs.
When an AI platform’s identity controls are only cosmetic
Real identity controls should change what the platform allows, records, and exposes. If those guardrails are hollow, the symptoms show up in behaviour: one user can spin up unlimited agents, act through another account, or find credentials and tokens sitting in places that other users or services can read. In practice, the platform is failing to distinguish who is acting, on whose authority, and with what scope.
That is why inflated agent counts, unexplained content, and shared-secret exposure matter. They are not just interface bugs; they are evidence that the application is accepting activity without reliably binding it to a verified identity, a constrained role, or a defensible audit trail.
What real identity enforcement should look like in an AI platform
A platform with genuine identity enforcement should be able to prove three things at runtime: who initiated the action, which agent or service is allowed to perform it, and whether the action stays inside the approved boundary. That usually means unique user attribution, separate identities for agents or services, restricted delegation, and secrets that are isolated rather than broadly reachable. The Ultimate Guide to NHIs is useful here because it frames the core distinction between a named user, an agent identity, and the secret material that enables access.
When those controls are real, one account does not silently become many agents, one token does not unlock unrelated actions, and shared stores do not become de facto credential warehouses. A separate agent registry, scoped credentials, and explicit delegation boundaries make the control surface visible enough to verify.
By contrast, if the platform only labels objects as “agents” while letting any user create, reuse, or impersonate them without meaningful checks, the identity layer is performative. The Agentic AI Identity Guide helps anchor the practitioner view of lifecycle, delegation, registration, and retirement, which are the places where cosmetic controls usually fail first.
Why the warning signs point to governance failure, not just bugs
These symptoms usually appear together because they share one root problem: the platform has no enforceable ownership model for identity-bearing actions. If a user can create unlimited agents, the platform has no effective registration or quota boundary. If an agent can post as another account, delegation or impersonation is not being constrained. If secrets remain in a shared store, the system has not separated convenience from privilege.
The Top 10 Agentic AI Identity Issues is a good companion reference for this pattern because it treats overprivilege, shared credentials, and human use of agent access as governance failures with security impact, not isolated defects. Likewise, the Identity Convergence Guide is helpful when teams need to understand why workforce, machine, and agent identities must be managed as distinct but connected populations.
Once the platform can no longer show clear accountability for who acted and what it was allowed to do, every downstream control becomes weaker. Logging may still exist, but it no longer proves attribution. Authorization may still be configured, but it no longer limits effective power. That is the difference between a working control and a control facade.
Risk and Threat Considerations
When identity controls are superficial, the main risk is blast radius. A single compromised user session or leaked token can be turned into many agents, broader posting authority, or access to secrets that should have been isolated. In an AI platform, that creates a fast path from weak attribution to impersonation, data exposure, and automated abuse.
Failure mechanism: The platform accepts actions from an agent or token without reliably binding them to a verified owner, bounded role, or separate secret boundary, so authorization can be bypassed through reuse or impersonation.
Impact: Attackers or careless users can create unbounded agents, post under another identity, exfiltrate tokens from shared stores, and turn one compromised foothold into broad operational misuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Unbounded agent actions and impersonation reflect excessive privilege boundaries. |
| NHI-02 — Secret Leakage | Shared stores exposing tokens or credentials is direct secret leakage. | |
| Recommendation — Restrict each agent to the minimum actions and scopes it actually needs. Isolate, rotate, and remove secrets from shared-access locations. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Posting as another account and unrestricted agent creation are identity and privilege abuse signals. |
| Recommendation — Bind each agent action to a verified identity and enforce scoped authorization. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token exposure and shared secret access are credential lifecycle failures. |
| IA-9 — Service Authentication | AI platforms often rely on service or workload identities for agent-to-system actions. | |
| AC-6 — Least Privilege | Unlimited agents and cross-account posting indicate privilege boundaries are not enforced. | |
| Recommendation — Manage issuance, storage, rotation, and revocation of authenticators. Authenticate services separately and prevent shared credential reuse. Limit each identity to the smallest set of permitted actions. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Identity controls failing in an AI platform are access-control failures. |
| A.8.5 — Secure authentication | Impersonation and token misuse show weak authentication handling. | |
| Recommendation — Define and enforce access rules for users, agents, and secrets. Use strong authentication and validate each actor before allowing action. | ||
Practitioner Guidance
What to verify: Check whether every agent has a unique owner, a distinct runtime identity, and a revocation path that actually disables it. If the platform cannot answer “who created this, who can act through it, and what secret lets it operate,” the identity control is not trustworthy.
Decision rule: If an agent can act, post, or authenticate without a separately enforceable identity record and scoped secret, treat the platform as failing identity governance until proven otherwise. Do not accept UI claims of “managed access” when the underlying objects are still shared or reusable.
Practitioner takeaway: Real identity control is proven by containment and attribution, not by labels. If a platform cannot prevent shared secrets, impersonation, and uncontrolled agent creation, its identity model is operationally weak even if the product claims otherwise.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org