Roles & responsibilities
Kaizen has two roles, and both come from your Kamiwaza account. There is no separate Kaizen user directory, no second password, and no way to grant yourself a role from inside the app.
Member
Everyone who can sign in is a member. Members can:
- run Search and Chat across everything their platform permissions allow;
- upload Documents and ask questions grounded in them, privately;
- build Collections and single- or multi-step Prompts;
- create Projects and invite named colleagues;
- share a chat with a named recipient;
- build, test, and share agents in Agent Studio;
- create and run Tasks they own when the delegated-workload release gate is available;
- change their own preferences, including compression settings.
A member's reach is bounded by their platform permissions, not by Kaizen. Every tool an agent runs on a member's behalf executes with that member's identity, so an agent can never see or do more than the person who asked.
Administrative capabilities
Two trusted paths grant administrative capabilities.
Kamiwaza Platform Admin retains the complete Kaizen Admin area and can also inspect bounded platform workroom metadata through the member API and authorized agents. The metadata inventory remains read-only and is not a separate Admin-area page.
Kaizen App Admin is the owner of the current workroom. This capability configures the Kaizen deployment without granting platform-wide inventory:
- model roles and connector exposure;
- platform-tool and package policy;
- deployment settings and feature availability;
- agent publication and lifecycle;
- content-free health and usage views.
Either path grants the Kaizen operator surface. A person holding both receives the same operator controls plus the Platform Admin inventory capability. Neither capability grants private chats, documents, or tasks.
What neither role can do
Some boundaries hold regardless of role:
- Nobody can widen document access from inside Kaizen. Source permissions come from the connected system and the platform.
- Nobody approves an unattended write by owning it. Task ownership is not approval; see Approvals & the write guard.
- Nobody borrows another participant's authority in a shared room. Each turn runs as its initiating participant only.
- Nobody reads another member's sandbox. Workspaces are bound to actor and conversation together.
Where a role is enforced
| Surface | Gate |
|---|---|
Member API (/api/*) | Validated platform identity envelope; email is the document-ACL principal |
Platform inventory (/api/platform/*) | Kamiwaza Platform Admin; metadata only |
Authorized workroom overview (/api/workrooms/{id}/*) | Target appears in the caller's live Core workroom list |
Kaizen operator API (/api/ops/*) | Current-workroom owner role |
| Tool execution | The initiating member's permissions, re-resolved per target workroom |
| Scheduled runs | Current member consent plus registered workload and exact per-effect authority |
Read Identity & the platform envelope for how the identity itself is established and why request bodies are never trusted.