What breaks when organisations allow broad access to create users, endpoints, or plugins for AI services?

Broad create permissions can let an attacker establish persistence, introduce malicious functionality, or build alternate access paths that are hard to spot. In AI environments, those actions can blend into normal development activity. The practical failure is not just unauthorised access. It is the loss of visibility into which identities, components, and policies are now part of the trusted attack surface.

Why This Matters for Security Teams

Broad create permissions are dangerous because they let any trusted actor expand the environment without review. In AI services, that means new users, endpoints, plugins, and integrations can become durable parts of the control plane, even when they were created for a short task. The result is persistence, shadow access paths, and policy drift that traditional access reviews often miss. NHI Management Group’s research on the 52 NHI Breaches Analysis shows how quickly overlooked identity and access sprawl becomes an operational security issue, not just an admin concern.

This risk is amplified in agentic environments because autonomous systems can chain creation privileges into further access, tool registration, or hidden execution paths. The OWASP Non-Human Identity Top 10 treats uncontrolled NHI lifecycle changes as a core exposure because machine identities often outlive the intent behind their creation. In practice, many security teams discover the problem only after a new service account, plugin, or endpoint has already been used to persist access or bypass normal approval flows.

How It Works in Practice

When create permissions are broad, the security model shifts from controlling access to controlling expansion. A user who can create AI endpoints can often create new authentication boundaries, new callback URLs, or new service principals that inherit trust from the platform. A user who can create plugins can introduce code paths that call external systems, exfiltrate data, or impersonate legitimate workflow steps. A user who can create users can manufacture durable access that looks internally authorised unless creation events are tightly monitored.

In mature environments, the response is to separate creation from approval and to treat every created object as a new trust decision. That usually means limiting creation rights to a small administrative set, enforcing workflow-based approvals, logging all create actions as security events, and requiring post-creation validation before the object is allowed to interact with sensitive data or production tools. The NIST SP 800-53 Rev 5 Security and Privacy Controls supports this through access enforcement, configuration management, and auditability expectations. For AI-specific identity risk, the Ultimate Guide to NHIs and the JetBrains Marketplace AI Plugin Campaign illustrate how quickly plugin ecosystems can turn creation rights into a distribution path for malicious capability.

• Restrict create permissions to tightly scoped administrative roles.
• Require approval or ticket linkage for each new user, endpoint, or plugin.
• Validate the object against policy before it can be used in production.
• Monitor creation events for unusual volume, naming patterns, or ownership changes.
• Revoke or disable objects that are not continuously justified.

These controls tend to break down in self-service developer platforms with weak ownership boundaries, because creation can happen faster than review, and the resulting objects may inherit trust automatically.

Common Variations and Edge Cases

Tighter creation control often increases operational overhead, requiring organisations to balance speed for engineering teams against the risk of uncontrolled expansion. That tradeoff is real, especially in sandbox environments, CI/CD systems, and AI experimentation zones where broad creation is common. Best practice is evolving, but current guidance suggests that low-risk labs may allow broader creation only when they are isolated, heavily logged, and unable to reach production secrets or customer data.

The hardest edge case is when creation is delegated to automation. A pipeline, assistant, or agent may legitimately need to create users or endpoints, but that does not mean the permission should be permanent or broadly shared. In these cases, organisations should prefer just-in-time elevation, short-lived service credentials, and strong ownership tagging so every created asset has a human or system sponsor. The Replit AI Tool Database Deletion case is a reminder that creation power without guardrails can become destructive very quickly. The DeepSeek breach also shows why hidden or exposed components created outside normal review can widen the trusted attack surface before anyone notices.

Where organisations rely on broad create rights for productivity, the practical fix is not blanket prohibition. It is narrowing who can create, forcing every creation through policy, and making every new identity or integration visible enough to be reviewed, revoked, and traced back to a responsible owner.

Related resources from NHI Mgmt Group

• What breaks when organisations do not control AI connectors to corporate data sources?
• What breaks when organisations do not control evaluation access to security tools?
• What breaks when organisations leave default readable access on sensitive Active Directory groups?
• What breaks when API access for AI workflows is handled through manual registration and credential setup?