Signed-in access
Private company areas require a valid, signed-in session.
Control that stays with your team.
Zayvro signs people in, checks roles, and scopes access by company and user. Every run is recorded, and your team approves the actions that matter.
Controls the product has today.
These describe the current Zayvro product. They are not a certification, a deployment-specific guarantee, or a control that has not been verified.
Role-based permissions
Company member, company admin, and platform admin each see different paths.
Company and user scoping
Chat access is checked against both the company and the person using it.
Separate workspace per chat
Zayvro keeps the files and context for each chat in their own workspace.
Publish files only when you choose
Only files someone deliberately publishes appear as finished results.
Recorded work events
Every step and tool call is stored with the chat so your team can review it.
Controlled file access
Workspace files are read and downloaded through authenticated, scoped routes.
Human approval before key actions
Important actions pause for a person before anything is sent or changed.
Full run history
Each run keeps a record your team can open and check later.
Scope note
These are current product foundations, not a certification list or a universal deployment promise.
The boundary for each task is set with your team.
A general security page cannot describe every task. For each one, we set out the data, people, actions, decisions, and evidence involved before it goes live.
Data scope
Sources, record types, sensitive fields, and how long data is kept for the task.
Identity model
The people, service accounts, roles, and system owners involved in the task.
Action boundary
The difference between reading, preparing, changing, sending, and actions Zayvro should never take.
Human decisions
The choices that are too important or unclear to leave to Zayvro, and who they route to.
Evidence needs
The events, sources, approvals, and outputs your team wants to check after the work is done.
Launch outcome
A written summary of the boundary that your team can review together.
Permissions and approval points, made visible.
This is the pattern behind every task we set up: what is allowed, what needs a person, what is blocked, and what stays reviewable. Exact controls depend on the setup.
Allowed
Routine steps Zayvro may complete inside the agreed permissions.
Needs a person
Actions that pause for approval before anything important happens.
Blocked
Work Zayvro must never attempt for this task.
Reviewable
A record of what happened that your team can check after the run.
This is the control pattern we design toward, not a certification statement or a universal customer configuration.
Bring the real requirements, not a checkbox list.
We would rather find a gap during setup than imply a control exists before it has been checked.
Data scope
Sources, record types, sensitive fields, and how long data is kept for the task.
Identity model
The people, service accounts, roles, and system owners involved in the task.
Action boundary
The difference between reading, preparing, changing, sending, and actions Zayvro should never take.
Human decisions
The choices that are too important or unclear to leave to Zayvro, and who they route to.
Evidence needs
The events, sources, approvals, and outputs your team wants to check after the work is done.
A written boundary your team can review before launch.
Review one task's boundary with us.
Book an intro and walk through access, approvals, and run history for a real task from your world.
Book an intro