Identity & access
Workspace, role, membership and connected-service permissions determine which context a user or integration can access.
SECURITY & CONTROL
Let Voyager understand broadly without granting broad authority.
The control model separates what Voyager can understand, what it can prepare, what needs approval and what it is allowed to execute. Provider access and organizational authority remain explicit.
Tenant and context boundaries
Business, personal and family contexts use scoped ownership and permission boundaries rather than one unrestricted data pool.
Approval boundaries
A material action can require explicit human approval even when Voyager is allowed to understand the context and prepare the proposed work.
Governed history
Approval and governed-action flows are designed to retain the history needed to understand what was proposed, approved or executed in the features where those flows apply.
Connected-service scope
An integration operates inside the provider permissions and Voyager capabilities granted to that connection. Connecting a provider does not imply unrestricted read-write access.
Evidence over labels
Security controls and deployment requirements are described at the level Voyager can currently evidence. Voyager does not convert planned controls or architectural options into present-tense compliance claims.
AUTHORITY LEVELS
Separate access to context from permission to change the world outside Voyager.
A useful intelligent system may need substantial context to understand an event correctly. That does not mean it needs permission to send the external message, change a commitment, spend money or execute another consequential action.
UNDERSTANDVoyager can use allowed context to determine what changed without receiving permission to execute the downstream action.PREPAREVoyager can draft, calculate, organize or prepare proposed work while the consequential decision remains with a person.APPROVEA material action can stop at an explicit request so an accountable person decides whether it should proceed.EXECUTEOnly work inside granted authority can continue without another approval step. That authority can be much narrower than Voyager's technical capability.
SECURITY ANSWERS
Questions security and procurement teams should be able to answer precisely.
Does connecting a service give Voyager unrestricted access to it?
No. Provider permissions, granted scopes and the Voyager connector capabilities enabled for the deployment define what the connection can access or change.
Can Voyager understand information without being allowed to act on it?
Yes. Understanding, preparation, approval and execution are separate authority levels. A workflow can allow deep analysis while keeping the resulting action manual or approval-gated.
Does Voyager currently claim SOC 2, ISO 27001, HIPAA or PCI compliance?
No. Voyager does not currently claim those certifications or compliance statuses on this site. A status will only be claimed when it has actually been achieved, is applicable and can be supported by current evidence.
How are business, personal and family contexts handled?
Voyager is designed around scoped contexts, ownership and permissions so separate business, personal and family information is not treated as one unrestricted pool.
What should a security or procurement team ask for?
Ask for the controls and deployment evidence relevant to the specific workflow, connected systems and authority level being evaluated. Voyager will distinguish current evidence from deployment-specific requirements or future work rather than collapsing them into a generic security claim.
CLAIMS DISCIPLINE
No certification by implication.
Voyager does not currently claim SOC 2, ISO 27001, HIPAA or PCI compliance on this site. Security and procurement conversations should be based on the controls, evidence, provider scopes and deployment requirements that actually apply to the use case being evaluated.
Discuss security requirements →Enterprise deployment model →