Private places to work
Each Claw works in its own isolated workspace. Runtime services are reached through WorkClaw's authenticated routing layer, not exposed as public computers for anyone to poke at.
SecurityBuilt for agents that can actually do work
WorkClaw gives AI assistants real tools, memory, files, browser access, and connected apps. Our security model is designed around that reality: isolate the work, check access, control the network, encrypt sensitive data, and leave a reviewable trail.
Private workspace
Files, memory, and runtime state stay scoped to the right Claw.
Authenticated route
Requests pass through identity and ownership checks first.
Controlled network
Browser and web access run through policy and review points.
Team encryption
Sensitive records are protected with team-specific keys.
The control layers
Security is built into how a Claw works
The important part is not one magic lock. It is the set of boundaries, checks, and records around every place a Claw can act.
Access checked at every handoff
Requests are authenticated, routed to the right team, and checked against ownership rules before they reach a Claw or its workspace.
Networking is controlled
Browser and web traffic passes through a managed network control layer so teams can review where activity went without publishing the internals of that enforcement.
Sensitive fields are encrypted
Credentials and other sensitive fields use team-specific encryption. A team's protected data is encrypted for that team, not treated as one shared application secret.
Runtime access is hardened
Claw runtimes run with constrained operating-system access, reduced privileges, and defensive profiles that limit what a compromised process can do.
Activity leaves a trail
Important actions, network events, and operational changes are logged so the system can be reviewed, investigated, and improved over time.
How we think
Useful autonomy with clear limits
WorkClaw is built for professionals who want agents to handle real work, but still need to know where access starts, where it stops, and what happened afterward.
1
A Claw should have enough access to do useful work, not unlimited access by default.
2
Human approval belongs around sensitive actions, credentials, and external communications.
3
Security controls should be understandable to customers without becoming an implementation map.
4
Logs should help teams answer what happened without turning private work into public exposure.
Transparency without oversharing
We show the posture, not the attack surface
A good security page should help customers evaluate trust. It should not publish a checklist of exact internals for someone else to test against.
What we explain publicly
The categories of controls we use: isolation, authentication, encrypted storage, controlled networking, auditability, monitoring, and operational review.
What we share during review
Security questionnaires, architecture summaries, vendor details, and compliance materials can be provided to customers under the right review process.
What we keep private
Exact network rules, internal host details, secret-handling mechanics, and operational playbooks are intentionally not published on the open web.
Security reviews
Need a deeper review?
We can support customer security reviews with appropriate materials, including architecture summaries and compliance updates.