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.
How Broad Creation Rights Expand the Trusted Attack Surface
When organisations let many users create AI service accounts, endpoints, or plugins, they are effectively allowing new trust relationships to be introduced without the same scrutiny applied to established assets. That matters because AI services often combine identities, tool access, data access, and automation in one place. If the creation path is weak, a malicious or careless actor can add something that looks routine but behaves like a foothold, a bypass, or a hidden dependency.
For AI services, the risk is less about one bad object and more about the growth of unmanaged surface area. A created user may inherit permissions, a created endpoint may expose a new integration path, and a created plugin may extend what the AI can read or do. Each of those can become a governance blind spot if ownership, approval, and review are not tightly defined. OWASP’s OWASP Non-Human Identity Top 10 is useful here because the same trust problems that affect machine identities also appear when AI-adjacent objects are created too freely.
In practice, many security teams discover the problem only after an unusual plugin, service identity, or endpoint has already been treated as part of the normal environment.
How It Works in Practice
Broad create permissions usually fail through a simple pattern: the platform allows new objects to be added faster than it can reliably explain who created them, why they exist, what they can reach, and when they should be removed. In an AI service, that can mean a developer creates a plugin for convenience, a team spins up a new endpoint for testing, or an automation account is created with enough scope to keep working long after the original need has passed.
The security issue is that “create” is not just an administration action. It is an authorization boundary that can be used to introduce new identities, new code paths, and new policy exceptions. If creation is broad and review is weak, an attacker who gains a low-privilege foothold may not need to escalate in the usual way. They may instead create something legitimate-looking that grants durable access, routes requests through a controlled endpoint, or embeds malicious behaviour inside an approved workflow.
That is why the control challenge is not only permission design but also lifecycle control. Organisations need to know which create operations are allowed, which are provisional, and which require additional approval. They also need enough logging to answer basic questions after the fact: what was created, by whom, what it was connected to, and whether it still matches the original business purpose. NIST SP 800-53 Rev. 5 control families around access enforcement, auditing, and system integrity are relevant here because they address the need to constrain action, record it, and verify that the resulting state remains trustworthy.
- Creation rights without review tend to turn temporary exceptions into standing infrastructure.
- Created plugins and endpoints can expand the attack path even when no password is stolen.
- Inventory and ownership become security controls, not just operational housekeeping.
Where this guidance breaks down is in highly dynamic environments that cannot distinguish sanctioned automation from uncontrolled object sprawl.
When Creation Flexibility Becomes a Governance Problem
Tighter creation controls often increase operational friction, so organisations have to balance speed against auditability. That tradeoff becomes more visible in AI platforms because experimentation is common and teams may expect self-service by default. The governance problem begins when self-service is treated as a blanket permission rather than a bounded exception with purpose, scope, and expiry.
One important edge case is delegated administration. It can be appropriate for platform teams or approved builders to create AI objects, but only if the resulting objects remain visible, attributable, and removable. Another edge case is plugin ecosystems, where the creation of a harmless-looking integration can still introduce data leakage, command execution, or a trust shortcut into the AI workflow. Industry guidance is not fully aligned on how much pre-approval every AI artefact should require, but there is broad agreement that untracked creation makes assurance harder, not easier.
Another common misunderstanding is assuming that “non-production” creation is low risk. In AI systems, test endpoints, experimental plugins, and temporary service users often persist into operational use because they already work. That is how weak creation governance becomes a durable trust issue rather than a short-lived admin convenience. The more directly a created object can read data, call tools, or influence responses, the more strictly it should be governed.
For readers who want a broader control baseline, NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls provides the governance structure that helps separate approved creation from uncontrolled expansion.
At scale, the hardest failure is not an obvious breach but the quiet normalisation of unreviewed objects that no one can confidently account for later.
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 MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Broad create rights expand unmanaged non-human objects and trust relationships. |
| NHI-03 — Privilege and Access Scope | Creation can inherit or widen access beyond intended scope. | |
| NHI-05 — Lifecycle and Revocation | Unreviewed created objects often persist after their original purpose ends. | |
| Recommendation — Inventory newly created AI identities and plugins, then assign accountable ownership immediately. Restrict creation scopes so new AI objects inherit only the minimum access they need. Revoke stale AI-created objects quickly and tie removal to an enforced lifecycle. | ||
| MITRE ATT&CK | T1136 — Create Account | Attackers may create legitimate-looking accounts to establish persistence. |
| T1583 — Acquire Infrastructure | Created endpoints and plugins can provide attacker-controlled infrastructure paths. | |
| Recommendation — Detect and investigate unauthorized account creation as a persistence indicator. Map suspicious endpoint or plugin creation to T1583 and hunt for staging activity. | ||
| CIS Controls v8 | 6 — Access Control Management | Broad creation rights are an access governance problem requiring enforcement. |
| 8 — Audit Log Management | Creation activity must be recorded to preserve accountability and traceability. | |
| Recommendation — Limit who can create AI users, endpoints, and plugins, and review those rights regularly. Log creation events with actor, object, and policy context for later review. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorization | Creation permissions directly alter who can establish trusted access paths. |
| DE.CM-7 — Monitoring for Unauthorized Activity | Unusual creation of users, endpoints, or plugins is a detectable control signal. | |
| Recommendation — Apply PR.AC-4 to tightly authorize which teams may create AI-facing resources. Monitor creation patterns for unauthorized or anomalous AI resource provisioning. | ||
Practitioner Guidance
What to prioritise: Treat create permissions as a trust-design decision, not an admin convenience. The first question is whether the created object can reach data, invoke tools, or inherit policy in a way that changes the system’s effective attack surface.
What to verify: Confirm that every creation path has an owner, an approval model, and a deletion path. If the organisation cannot explain who may create what, under which conditions, and how it is reviewed after creation, the control is not mature enough for AI-facing environments.
What practitioners underestimate: The most dangerous objects are often the ones created for testing, integration, or temporary use. Those objects tend to bypass scrutiny because they resemble normal delivery work, yet they are frequently the easiest place for persistence or hidden access to survive.
Practitioner takeaway: Broad create rights are risky because they convert new objects into ungoverned trust, so the practical goal is not simply to reduce permissions but to keep every created AI artefact attributable, reviewable, and removable.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
