How does Miiwa decide who can run a Miiwa Agent?
A Miiwa Agent is runnable only when it is published in the correct workspace and its workspace and user assignments resolve to visible for the authenticated user.
In Miiwa, seeing an agent is not merely a dashboard filter. The platform resolves workspace and user assignments to decide which published deployments are visible, and the run path checks that decision again before it loads the graph or spends a credit.
Which assignment layers does Miiwa evaluate?
- Published deployment
- The versioned Miiwa Agent that can be assigned and run. Draft Studio projects are not part of the runnable-agent list.
- Workspace assignment
- The baseline rule that enables or disables a deployment for members of one workspace, with optional pinning and ordering.
- User assignment
- An explicit allow or deny rule for one user and deployment inside that same workspace.
- Runnable agent
- A published deployment that survives assignment resolution for the authenticated user and still belongs to the active workspace.
Which rule wins when assignments disagree?
| Workspace assignment | User assignment | Result |
|---|---|---|
| Enabled | None | Visible from the workspace assignment |
| Disabled or absent | Allow | Visible from the user assignment |
| Enabled | Allow | Visible; user presentation settings can refine the workspace defaults |
| Enabled or disabled | Deny | Hidden and not runnable |
| Absent | None | Hidden |
Why does Miiwa check access again at run time?
A list can become stale between display and execution. Miiwa therefore calls the runnable-agent assertion in both the prepare and execute paths. If the deployment is no longer assigned, the request fails before graph loading, integration checks or workflow execution.
The assertion also compares the deployment workspace with the active workspace. A deployment identifier from another tenant cannot become runnable simply because a client submits it in a request.
Do pinning and ordering change access?
No. Pinning and sort order decide how already-runnable agents are presented. Miiwa sorts pinned agents first, then by the resolved order and title. Those fields cannot turn a denied or unassigned deployment into an allowed one.
What happens when an assignment changes?
Assignment mutations invalidate the runnable-agent cache immediately, with a short time-based backstop. Entry points that can hold an older binding still reassert the assignment at execution; the workspace MCP surface, for example, checks again before a tool call starts a run.
A practical assignment checklist
- Publish the intended workflow version into the correct workspace.
- Choose whether the agent should be enabled for the workspace or only allowed for named users.
- Add explicit denies for exceptions that must not inherit the workspace baseline.
- Use pinning and order only after the access decision is correct.
- Test with a normal user account, not only an Admin session.
- Revoke an assignment and confirm that both discovery and execution fail as expected.
In Miiwa, assignment is an execution boundary: workspace enablement creates the baseline, user allow can add a narrow exception, user deny wins, and the result is checked again when work starts.
Common questions
- Can a user run a Miiwa Agent by guessing its deployment ID?
- No. The assigned-run paths resolve the authenticated user and active workspace, then assert that the deployment is runnable for that exact combination before loading or executing its workflow.
- Does disabling a workspace assignment override a user allow?
- No. A specific user allow can make the deployment visible even without an enabled workspace baseline. A specific user deny, however, always hides it.
- Does pinning a Miiwa Agent give a user permission to run it?
- No. Pinning and sort order only affect presentation after access has been resolved. They do not replace a workspace enablement or user allow.