Security & trust
A connected system may technically permit an action without giving Voyager organizational authority to take it. Voyager keeps access, understanding, preparation, approval and execution as separate control decisions, with external effects gated by both provider permissions and your policy.
Technical capability and organizational authority are not the same thing.
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.
Voyager reaches only the context the workspace, role, membership and connection scopes allow.
Refund requestSupport case, order and Stripe charge. Not payroll or unrelated accounts.
External effectNone
Voyager can use allowed context to determine what changed without receiving permission to execute the downstream action.
Refund requestThe order arrived six days late and the refund policy applies.
External effectNone
Voyager can draft, calculate, organize or prepare proposed work while the consequential decision remains with a person.
Refund requestA $240 refund and a reply to the customer, drafted.
External effectNone
A material action can stop at an explicit request so an accountable person decides whether it should proceed.
Refund requestAbove $200, the support lead decides.
External effectOnly after approval
Only work inside granted authority can continue without another approval step. That authority can be much narrower than Voyager's technical capability.
Refund requestSmall late-delivery refunds, if your policy grants that authority.
External effectWithin granted authority
Illustrative example. Which actions sit at each level is set by your policy, per action, role and amount.
Governed external action
Messages to customers, payments, bookings, purchases and record changes in connected systems are the actions that matter most. Each one needs both the provider permission and your authority policy, and each is recorded with who authorized it.
Illustrative example. Names, amounts and thresholds are placeholders for your own policy.
Pause and revoke
Administrators can pause a Worker, automation or integration without deleting it, and revoke a connection or a delegated authority at any time.
Stops a Worker, automation or integration from acting without deleting it. Its configuration and history stay in place, and it resumes when you decide.
Withdraws a connection or a delegated authority at any time. Nothing further happens through it, and what already happened stays in the audit record.
Boundaries
An action has to clear each boundary around it: the tenant and context, the access a role or connection holds, the provider scope and the approval policy.
Business, personal and family contexts use scoped ownership and permission boundaries rather than one unrestricted data pool.
Workspace, role, membership and connected-service permissions determine which context a user or integration can access.
An integration operates inside the provider permissions and Voyager capabilities granted to that connection. Connecting a provider does not imply unrestricted read-write access.
A material action can require explicit human approval even when Voyager is allowed to understand the context and prepare the proposed work.
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.
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.
Control domains
What Voyager provides in each area. Deployment-specific requirements are confirmed during a security review.
Organization and workspace isolation is the primary trust boundary. Inside it, access is granted through roles and scopes, and administrators can see and change who holds it.
Approval policies decide which actions proceed, which wait and who decides. Some decisions, such as hiring, compensation and termination, stay with accountable people regardless of policy.
Privacy, retention and lifecycle are configured controls, and Business, Personal and Family information keep separate boundaries.
Voyager Workers, automations and integrations act only within the authority granted to them. AI work records its sources, and model use is governed by policy and visible in audit.
Messages to customers, payments, bookings, purchases, record changes in connected systems and other effects outside Voyager are the actions that matter most. Each one needs both the provider permission and your authority policy, and each is recorded with who authorized it.
An audit trail answers who did what, when and on whose authority. Health views show when an integration, webhook, automation or Worker is degraded, so a failure is seen rather than discovered later.
SECURITY ANSWERS
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.
