Security

Private by architecture. Explicit about every boundary.

Enterprise agents touch sensitive knowledge, business systems, documents, conversations, and code. Before access begins, Veyl fixes the execution environment, provider exposure, identity, permissions, retention, and deletion terms in writing.

Run where the organization approves

Veyl supports customer-controlled infrastructure and approved dedicated environments. Veyl Private extends that model to private cloud, on-premises, and scoped local appliance deployments. The architecture is agreed for the specific organization rather than hidden behind a general statement that data is private.

• Customer-controlled environment. Models, agents, evaluations, and tools run on infrastructure the organization owns or administers.
• Approved dedicated environment. A single-tenant system is created for the organization and governed by agreed access, retention, and deletion terms.
• Configured local appliance. Where required, Veyl can scope a complete local deployment with compute, model serving, knowledge, agents, and the reliability layer.

Every external provider is a declared boundary

If a hosted model, data service, or tool receives customer context, that exposure is named before use. Veyl does not describe a workflow as local or private while silently sending part of it elsewhere.

The approved architecture records provider identity, credentials, retention settings, data classes, allowed destinations, and the exact part of the workflow that crosses the boundary. Fully local deployments keep model context inside the approved environment.

Agents receive only the authority they need

Each workflow has named roles, tools, data sources, actions, human checkpoints, and stop conditions. Access is least-privilege, time-bounded where appropriate, revocable, and tied to the deployment identity that was evaluated. An agent does not inherit authority from a general model score.

Private evaluations stay private

Customer-derived scenarios remain isolated to that organization. They are not published, resold, shared across customers, or used for training without separate written permission. The reusable asset across engagements is Veyl’s method and software, not another customer’s proprietary work.

A reviewable current posture

Veyl is currently pre-SOC 2. For scoped work, organizations can review the concrete controls governing access and execution directly:

• Approved environment and written data-flow boundary before access
• Named users, least privilege, revocable credentials, and access logging
• Isolation between organizations and between evaluation runs
• Exact deployment and provider identity recorded with each result
• Named subprocessors disclosed before use
• Written retention and deletion terms with completion records
• Incident notification commitment in engagement terms
• Security questionnaire answers and data-flow documentation on request

Customer-controlled or local execution can materially reduce exposure. It is not a substitute for a certification the organization requires. Buyers with an existing SOC 2 report as an absolute vendor gate cannot engage Veyl under the current posture.

What changes require another decision

A new model, tool, role, permission, provider, knowledge source, policy, or workflow may invalidate prior evidence. Veyl maps those dependencies so only current evidence grants operating authority. Unknown impact does not silently inherit approval.