They should move account creation, role assignment, and other privilege-changing actions out of the model’s direct control. Those steps need separate approval, logging, and policy enforcement so the model can request work without being able to complete side effects silently. Otherwise, a successful task can hide an unauthorized identity change.
When a model can create accounts or privileges inside a workflow
The safe design principle is to treat account creation and privilege changes as security actions, not ordinary workflow output. A model can draft the request, but a separate policy engine or approval path should decide whether the change is allowed. That separation keeps a successful task from becoming an invisible identity change.
Once a model can trigger side effects directly, the main question is no longer only whether the output is correct. It is whether the workflow can still prevent unauthorized access, preserve attribution, and expose the change to review before it takes effect. That is especially important when the action creates a durable account, elevates a role, or grants access to production systems.
In practice, teams should design the workflow so that the model can propose or stage the action, but not complete it alone. The approval point, audit trail, and authorization policy should sit outside the model boundary so an operator or control layer can inspect the request, confirm intent, and stop privilege drift before it becomes operational access.
Where workflows break down in practice
The most common failure is mixing business completion with security completion. If the workflow says “task done” when the model has merely requested an account or role, teams can miss the fact that access has been changed without human review. That creates a false sense of completion and weakens accountability for who granted what, to whom, and why.
A second failure is overbroad automation scope. Models often operate well enough to follow a happy path, but privilege changes are boundary-crossing events that should be constrained by explicit policy. If the model can select targets, choose roles, or decide when elevation is justified, it can also amplify a prompt error, bad upstream data, or malicious instruction into an access change.
A third failure is weak logging and exception handling. If the workflow does not preserve a clean record of the request, approver, policy decision, and resulting change, teams lose the ability to reconstruct whether the change was intended, mistaken, or abused. The safer pattern is to log the request separately from the enforcement decision and from the final identity state change.
Keeping model-driven workflows useful without handing over authority
The right control model is staged execution: the model may identify the need for access, but a distinct control plane must authorize, enact, and record the change. That distinction matters even when the underlying task is legitimate, because the security risk comes from the side effect itself, not just from malicious intent. Privileged Access Management Guide is useful here because it frames approval, session control, and zero standing privilege as the practical guardrails around elevated access.
Teams should also separate routine workflow success from privilege success. A model can successfully complete a business action and still be blocked from creating standing access, assigning high-risk roles, or issuing long-lived credentials. That is the core idea behind the safer designs described in Just-in-Time Access and Zero Standing Privilege Guide: grant access only when needed, for a limited time, with an explicit control path.
When the workflow touches cloud permissions, the same pattern should apply to entitlement review and escalation path control. Cloud PAM and CIEM Guide is a good fit for understanding how to right-size permissions and watch for escalation paths that a model should never be able to create on its own.
Risk and Threat Considerations
When a model can create accounts or privileges directly, the risk is not just accidental overprovisioning. It also gives an attacker a clean way to turn a good-looking workflow into unauthorized access, persistence, or privilege escalation, especially if the model accepts weak prompts, poisoned context, or manipulated upstream data.
Failure mechanism: The model performs an access-changing action without a separate authorization gate, so a normal workflow can silently create durable identity changes, overprivileged roles, or new trust paths that bypass human review.
Impact: Unauthorized accounts or privileges can persist after the original task is finished, expanding blast radius, weakening auditability, and creating a hidden foothold for later misuse or lateral movement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Model-created privileges are a direct identity and privilege abuse risk. |
| Recommendation — Separate access grants from agent execution and require independent approval before privilege changes. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Workflow-created accounts can become overprivileged identities if not constrained. |
| Recommendation — Enforce least privilege and prevent the workflow from creating standing high-risk access. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Privilege-changing workflows need restrictive authorization boundaries. |
| AU-2 — Event Logging | Account and privilege changes need auditable records outside the model. | |
| IA-5 — Authenticator Management | Workflow-created accounts often involve credentials or authenticators that need lifecycle control. | |
| Recommendation — Limit workflow components to the minimum permissions needed to request, not grant, access. Log approval, enforcement, and resulting identity changes separately for review and traceability. Control credential issuance and rotation through a separate managed process. | ||
Practitioner Guidance
What to verify: Confirm that the model can only request access changes, not commit them, and that the final decision is enforced by a separate authorization service with its own logs. If the model can both propose and apply the change, the control is not really separated.
Decision rule: If the action changes identity, role, session, secret, or standing access, require approval and policy enforcement outside the model path. If the action only prepares a request, it can stay in workflow automation.
What practitioners underestimate: The dangerous part is often not the initial account creation, but the durable access that remains after the workflow is over. A model that can create access once may leave behind standing privilege that outlives the task and is hard to notice later.
Practitioner takeaway: Let the model ask for access, never silently grant it. The control objective is to keep privilege changes observable, attributable, and reversible before they become part of the system state.