Who can access my data

Who can access my data? If you are signing up for TryOpenClaw, the short answer is that your data stays inside your own private instance, not in a shared environment with other users. That is the core boundary this service is built around.

That matters because OpenClaw agents often need real files, workflow inputs, and task context to do useful work. Before you trust a managed service with that data, you want to know who can see it, what the platform may touch, and where the limits are.

In the sections below, we will break down access inside the instance, the kinds of data that may be stored or logged, and the situations where those rules do not apply. The goal is simple: help you decide whether TryOpenClaw fits the level of privacy and control you need.

Your data stays inside your own private instance

In TryOpenClaw, your data stays inside your own private instance. That means the workspace, the agent activity, and the files you work with are separated from other users’ environments. For a TryOpenClaw user asking who can access their data before signing up, the practical answer is simple: access is scoped to your instance, not shared across the platform.

Inside that instance, access depends on the roles and actions you allow. You can log in and assign work to the agent, and the agent can operate on the data needed for that task. What matters is that the agent is running in your own environment, so it is not reaching into another customer’s workspace to complete its job.

This setup is useful when you want automation without giving up control. If you are using OpenClaw for CSV analysis, workflow automation, Telegram or Discord management, or content tasks, the files and prompts involved in those tasks remain tied to your private instance. That is the boundary TryOpenClaw is designed around: your environment, your work, your access.

It also changes the privacy question from “who on the internet can see this?” to “who and what is allowed inside my instance?” In a managed private cloud model, that is the right question to ask. It lets you separate the service layer from the data layer, which is especially important if you are testing AI automation with business files or internal workflows.

That said, private instance access is not the same as absolute invisibility. If you connect external tools, choose to share data with an agent, or store information in a workflow that you later expose, those actions create their own access path. The key point is that the default boundary is still your instance, and that boundary is what TryOpenClaw is built to preserve.

What TryOpenClaw can access to keep the service running

In short: TryOpenClaw can access the infrastructure needed to operate your instance, but it is designed so your data stays inside that private instance unless you deliberately move it elsewhere. That distinction matters. Service access is about keeping the environment available, stable, and recoverable; it is not the same as broad access to your agent data, workflow content, or files for unrelated use.

In practice, the platform may handle the parts required to provision, maintain, and repair your OpenClaw environment. That can include operational metadata, instance state, and the system signals needed for self-recovery, uptime monitoring, and support. The goal is to keep the service running without turning the platform into a shared workspace for your data.

Inside the instance, access is limited to what the instance itself needs in order to function. That means your agent work, stored inputs, and workflow outputs remain tied to your private environment rather than being pooled with other users. If a support action ever requires intervention, it should be directed at the service layer, not at using your data as a general-purpose resource.

It also helps to separate three things: the platform can operate the service, the instance can process your work, and any external connection you add can create a new access path. For that reason, the safest assumption is simple: if data is part of your private instance, it stays there; if you connect something outside it, that connection defines its own boundary.

How access differs between you, your agents, and the platform

In practice, access is split into three layers: you control the instance, your agents work inside it, and the platform only touches what it must to keep the service running. That distinction matters because it answers the real question behind “Who can access my data” without mixing up ownership, execution, and operations.

You, as the account owner, can sign in and manage what happens in your private instance. Your agents can read and act on the data you place there, because that is the environment they are meant to work in. The platform operates the hosted service, but it is not the same thing as your working space, and it should not be treated as a shared workspace with other users.

For most users, the practical rule is simple: if you put a file, prompt, workflow, or output into the instance, it is available to the people and agents you allow inside that instance. If you do not grant access to someone or something, they do not gain it by default. That is the main advantage of a managed private cloud setup for OpenClaw AI agents: the boundary is defined by your instance, not by a common pool.

What this means for daily use is straightforward. A developer can let an agent inspect a CSV, draft a workflow, or prepare content without exposing that work to other customers. A team can keep internal tasks in one environment while still using automation. And when you need to think about access, you can ask a cleaner question: is this person, agent, or connection inside my instance boundary, or outside it?

What Changes When You Use AI Tokens Or Connect External Tools

The main change is that access expands only to the systems you choose to connect. Inside TryOpenClaw, your agent can use the AI tokens available in your plan to run prompts and complete tasks, but that does not mean your data becomes visible to other customers. The practical boundary still starts with your private instance, then extends only to the external tool, API, or service you explicitly add.

If you connect something like a spreadsheet source, a messaging workspace, or an external API, the agent can work with the data needed for that workflow. That usually means the files, messages, or records involved in the task, not a free pass to everything you own elsewhere. In other words, the connection you create defines the scope of access, and you control which tools are available to the agent.

It also helps to separate processing from ownership. Using AI tokens means the agent can send prompts and receive results as part of the job, but the data is still handled within your instance workflow rather than being opened up to unrelated users. The same logic applies to external tools: if a connector is active, the agent can reach that connector for the task you set, but it does not gain broader access by default.

For daily use, that means you should think in terms of three layers: what lives in your private instance, what the agent is allowed to touch inside that instance, and what outside service you have connected on purpose. When those layers are clear, it becomes much easier to judge who can access your data in practice and where the boundary changes.

When access is intentionally limited or isolated

In TryOpenClaw, access is not broad by default. The service is built so your OpenClaw instance stays separate, and that separation matters when you are deciding who can see what. In practice, access is limited by the instance boundary, by the permissions you give inside it, and by any external tool you connect on purpose.

That means the platform does not need to behave like a shared workspace where every agent, user, or support process can look across other customers’ data. If a task stays inside your private instance, it stays inside that boundary. If you invite an agent to work on a file, a workflow, or a dataset, that access is still scoped to the instance and to the task you set.

Isolation also helps when you want to reduce accidental exposure. For example, a CSV analysis workflow can be kept separate from a community-management workflow, and a content workflow does not need to see anything that is not relevant to its job. This is useful for teams that want clear operational boundaries without having to build and maintain that separation themselves.

There are still limits to what this promise covers. If you connect a third-party service, share an API key, or let an agent reach an external system, then that outside system follows its own access rules. The same applies if you deliberately copy data out of the instance, export it, or hand it to another person. Isolation protects the managed OpenClaw environment, but it does not override choices you make beyond it.

So the practical test is simple: if the data is inside your instance and the action stays within the permissions you set, access remains limited; if the data leaves that boundary or you extend access elsewhere, the scope changes. That is the main reason this model is easier to reason about than a self-hosted setup with multiple moving parts and unclear handoffs.

What to check before you decide to store sensitive data

Before you store sensitive data, check three things: where it lives, who can act inside the instance, and what gets sent outside it. That is the clearest way to judge whether the setup matches your risk level, especially if you plan to use OpenClaw for internal files, customer records, research notes, or workflow data.

Start with the storage boundary. If the data stays in your private instance, it is handled differently from data that is copied into an external service, shared through a connected tool, or exported into another workflow. For sensitive material, that distinction matters more than the feature list.

• Confirm that the data remains in your own instance and is not shared with other customers.
• Review which users, agents, and connected tools have permission to read, write, or export it.
• Check whether logs, prompts, attachments, or outputs may contain parts of that data.
• Decide whether the data is sensitive enough to avoid external integrations entirely.

Next, look at the action boundary. Even when the data is stored privately, an agent can still process it, summarize it, or move it into another system if you allow that workflow. If you want tighter control, keep the task local to the instance and avoid broad permissions that are not needed for the job.

Finally, ask what happens when the setup changes. The usual exceptions are external tools, user-granted permissions, and any workflow that intentionally sends data outside the private environment. If one of those applies, the answer to who can access your data is no longer just “the instance” — it includes whatever you connected and authorized.