Accounts and operations
Organization membership, billing, instance identity, hostname, provisioning state, readiness, and service entitlements.
Security & data boundaries
Know where
the boundaries are.
Enterprise agents need explicit boundaries for infrastructure, credentials, execution, and context. Mesh separates these concerns so you can evaluate where your data goes and which authority each agent holds.
INSTANCE BOUNDARYAGENT PERSPECTIVE
RUN WORKSPACE
MESH HOSTINGAccounts · billing · deployment
Service metadataProvision & observe healthConversations stay below
Your organization
Dedicated Mesh
DatabaseEncryption key
Agents · conversations · memory
Connector & model credentials
Another organization
Dedicated Mesh
DatabaseEncryption key
Agents · conversations · memory
Connector & model credentials
This shows where data is placed, not who is prevented from reading it. Privileged Texture operators who run the hosting infrastructure can access stored content today. Separate databases do not imply dedicated database servers.
Privacy at the source
Knowing a fact isn’t
permission to share it.
Mesh tracks who contributed information and the audience allowed to receive it. Private source material is checked against everyone who can receive the destination conversation, before context assembly and again before the reply is sent.
A fact from a private DM stays out of a public-channel response unless sharing is explicitly authorized for that audience. Mentioning the same person or topic does not grant access. Amendments and summaries retain the restrictions of their sources; incomplete audience evidence blocks reuse.
These controls govern Mesh conversations and memory. Connected tools and external services still need their own access controls. Privileged infrastructure access is a separate boundary.
Explore agent perspectives →Where the data goes
Hosting metadata above.
Agent context inside.
The work itself
Agent personas, conversations, memory, prompt snapshots, and run records. Connector and model credentials are encrypted in the instance database.
Inference and execution
Model providers receive the context sent for inference. Connectors deliver messages. Workspace providers process the work you authorize. Their handling policies also matter.
Privacy today, stated plainly
What we can promise.
And what we can’t yet.
These statements describe the hosted beta as it runs now. We’ll update them when stronger protections ship, not before.
- Who can access stored content
- Conversations, memory, personas, prompts, model responses and tool results are stored in your instance’s database without application-level encryption today. Privileged Texture operators who run the hosting infrastructure can access that stored content. Hosted Mesh is not a zero-access or end-to-end encrypted service.
- What is encrypted today
- Mesh encrypts connector and model credentials with your instance’s own key before storing them. Our database provider encrypts storage at rest, which protects disks, not queries. Application-level encryption of conversation content is planned, not shipped.
- Support access
- By default, support starts from hosting metadata: instance health, versions and provisioning status. A customer-controlled, audited grant for support to view specific content is not available yet, so please avoid sending secrets or private content in support requests.
- Providers that process your data
- Your model provider receives the context sent for each request. Slack delivers messages to and from your agents. An execution provider such as Modal processes the work you authorize. Each provider’s own retention policy applies. With managed AI, requests go to OpenRouter under a key Texture provisions for your instance. With managed execution, sandboxes run on Texture’s Modal account.
- What the hosting service keeps
- Account and membership details, organization name and hostname, billing records, region and size, provisioning state and health. Managed-service usage quantities, costs and budgets when enabled. Agent conversations stay inside your instance.
- Retention and recovery
- Retention after cancellation, backup history and restore objectives are being confirmed and will be published before they are promised. Until then, keep your own copy of anything you can’t afford to lose.
Three boundaries to evaluateArchitecture / current beta
Instance to instance
Each hosted instance has its own runtime, database credential, and encryption key. Customer context is not stored in the shared account-and-billing database.
Agent to agent
Actors, conversations, and memory belong to a particular agent’s perspective. Shared hosting does not automatically grant an agent another agent’s knowledge.
Run to workspace
Execution can acquire a remote workspace for one run and release it afterward. A workspace is an explicit resource—not implicit permission to use the hosting machine.
Built ≠ finished
Evaluate the beta
with eyes open.
These are architectural controls, not a security certification. Scope credentials and data to the work you are comfortable testing.
IMPLEMENTED
Separate state and durable records
Per-instance resources, perspective-owned state, encrypted stored credentials, prompt snapshots, model-call records, and run outcomes.
CURRENT LIMITATION
Workspace access needs careful scoping
Execution controls depend on the backend: Fly workspaces have open egress; Modal supports restricted outbound policy; the execution broker requires an allowlist policy. Scope credentials and repository access for the work each agent performs.
PLANNED
Offline deployment qualification
A qualified offline deployment bundle and local execution worker remain in development. Evaluate the configured backend’s network policy, credential lifecycle, retention, and recovery behavior for your workload.
Evaluating Mesh for sensitive work?
Discuss your access, retention, recovery, and review requirements before moving production data into the beta.