Security

This page describes what is actually true of the running product, including the parts that are not flattering. A security page that only lists strengths is not information, it is decoration.

What an agent can reach

An agent has no ambient access to anything. It can only touch an application you explicitly attached to it, through a connector that carries its own permissions — so the blast radius of an agent is exactly the set of connectors on it, and nothing else in your account. Every other agent in the same workspace stays blocked from those connectors unless you attach them too.

A connector write waits for a person to approve it unless an admin has set that connection to run without asking, and that setting is itself recorded; a delete always waits for a person; and every call, allowed or refused, is written to the log. Merges, knowledge changes and reviewed-tier work stop at a human approval before they land. That is the load-bearing control in an agentic system: not that the model is well-behaved, but that a step nobody allowed cannot complete on its own.

Tool calls on your own servers

Agents think with a brain — an AI coding tool such as Claude Code or Codex (a harness, in engineering terms) — on a server you connect, with the file and shell access of the account that runs it there. A workspace admin chooses whether brains are started with tool-call approvals on or with their permission checks skipped, and each server running a current version of the brain app reports which way it runs, so a skipped check is visible on the Brains page and in the audit log. What “on” can do depends on the AI coding tool; this table is generated from the same declaration the product's launch code is tested against.

Brain	With tool-call approvals on	What that means
Claude Code	Asks before acting	Claude Code asks before it acts. Reading, searching and editing files is allowed up front; any other tool call, such as a shell command, waits in your approvals queue until someone approves or rejects it.
Codex	Bypass removed, cannot ask	Codex is started without its approval-and-sandbox bypass, so the sandbox and approval policy in its own configuration on that machine apply. Nobody can answer its questions from here, so they do not reach your approvals queue.
Gemini CLI	Bypass removed, cannot ask	Gemini CLI is started in its sandbox without --yolo, so actions it would normally confirm are not approved automatically. Nobody can answer its questions from here, so they do not reach your approvals queue.
Hermes Agent	Bypass removed, cannot ask	Hermes is started without --yolo, so its own check on dangerous commands stays on. Nobody can answer that check from here, so it does not reach your approvals queue.
Cline	Bypass removed, cannot ask	Cline is started without --auto-approve, so actions it would normally confirm are not approved automatically. Nobody can answer its questions from here, so they do not reach your approvals queue.
Atomic Agent	Bypass removed, cannot ask	Atomic Agent is started without --no-approval, so its own approval step stays on. Nobody can answer that step from here, so it does not reach your approvals queue.
OpenCode	Not gated from here	OpenCode is never started with its auto-approve flag, so it follows the permission rules in its own configuration on that machine. It has no approval protocol this product can answer, so this setting does not change it and its tool calls do not reach your approvals queue.
OpenClaw	Not gated from here	OpenClaw runs its tools under its own configuration on that machine. It has no approval protocol this product can answer, so this setting does not change it and its tool calls do not reach your approvals queue.
NanoBot	Not gated from here	NanoBot runs its tools under its own configuration on that machine. It has no approval protocol this product can answer, so this setting does not change it and its tool calls do not reach your approvals queue.
Kilo Code	Not gated from here	Kilo Code is never started with its auto-approve or skip-permissions flags, so it follows the permission rules in its own configuration on that machine. It has no approval protocol this product can answer, so this setting does not change it and its tool calls do not reach your approvals queue.
Freebuff	Not gated from here	Freebuff runs its tools under its own configuration on that machine. It has no approval protocol this product can answer, so this setting does not change it and its tool calls do not reach your approvals queue.
Pi	Not gated from here	Pi runs its tools under its own configuration on that machine. It has no approval protocol this product can answer, so this setting does not change it and its tool calls do not reach your approvals queue.
Pydantic AI	Not gated from here	Pydantic AI runs its tools under its own configuration on that machine. It has no approval protocol this product can answer, so this setting does not change it and its tool calls do not reach your approvals queue.
DeepSeek Harness	Not gated from here	The DeepSeek Harness runs its tools under its own configuration on that machine. It has no approval protocol this product can answer, so this setting does not change it and its tool calls do not reach your approvals queue.
Grok Build	Not gated from here	Grok Build is started in its default permission mode and never with bypassPermissions. It has no approval protocol this product can answer, so this setting does not change it and its tool calls do not reach your approvals queue.

Whatever a brain does on its own computer, writes made through your connectors still go through the connector policy on our server. Run the server as a user with only the access you are willing to let an agent use, in a directory you are willing to let it change.

Where your data lives

Database. A database on servers we operate ourselves, not a shared managed cloud database.
File attachments. Object storage at our storage provider, named in the sub-processor list, served through expiring signed URLs. Attachments are returned with Content-Disposition: attachment and a restrictive content policy, and SVG and HTML are never rendered inline — an uploaded file cannot become script running on our origin.
Voice notes. Transcribed by a speech-to-text model we run on our own servers. Audio is not sent to a third-party transcription service.
Email. Sent from our own mail server on this domain.
Payment details. None held, anywhere. Every payment is made by card inside our payment provider's own checkout — so no card number ever reaches us to be stored or leaked.

Accounts and sessions

Passwords are hashed with scrypt (N=2¹⁵, r=8, p=1) with a random per-password salt. A sign-in attempt for an address that does not exist pays the same cost as one that does, so the form cannot be used to discover who has an account.
A new password needs at least 12 characters (up to 256), and is refused if it is on a list of common or leaked passwords kept on our own servers, or if it is your email address or your workspace name. There are no rules about symbols or digits and no forced expiry. Existing passwords keep working until they are changed.
Session tokens are 192 bits of cryptographically random data and are stored hashed — a copy of our database does not hand anybody a usable session.
Sign-in, password reset, join codes and demo creation are all rate limited. A password reset revokes every existing session for that account and emails the account holder that the password was changed.
Session cookies are HttpOnly, Secure and SameSite=Lax.
A session ends after 30 days, or after 14 days without use, whichever comes first. Single sign-on sessions end after 7 days or 8 idle hours. Workspace owners and admins can see a member's active sessions, and can sign out a member whose only workspace is theirs.
Two-factor authentication (TOTP) is available, and can be required workspace-wide. Single sign-on over OpenID Connect is available per workspace. See the questions below.

How the product is built to fail safely

Tenancy is checked on every request. A workspace identifier taken from a URL is re-resolved against your session before anything reads or writes; it is never used as a database key on its own.
Every database query is parameterised. Where a table or column name has to be chosen on the fly it comes from a fixed allowlist, never from input.
Outbound requests are guarded. When the product fetches a URL you supplied — a connector endpoint, your own model endpoint — it refuses private, loopback, link-local and cloud-metadata addresses, resolves DNS and re-checks every redirect hop, and strips credentials on a cross-origin redirect. That is what stops a URL you control being used to read something on our internal network.
The audit log is hash-chained. Entries reference the one before, so a record cannot be quietly altered or removed after the fact.
Uploads are checked by content, not by claim. File type is determined from the bytes rather than the browser's stated content type, names are sanitised, and size and storage quotas are enforced server-side.

What we do not do

We do not train any model on your workspace content.
We do not sell data, and there are no advertising trackers inside the product.
We do not load analytics inside a workspace at all — the tag manager runs only on these public marketing pages, only after consent. See the cookie policy.
We do not hold card details, because we never receive them.
We do not claim certifications we do not have. There is no SOC 2 report and no ISO 27001 certificate.

The honest limitations

UtilitySpaces runs on a deliberately small stack — a small attack surface, no third-party analytics in the product, no long chain of sub-processors. That shape has real limitations too, which are worth stating plainly:

There is no 24/7 on-call rotation. Support replies within one business day; tickets from higher plans are answered first, which is all “priority support” means.
There is no third-party penetration test report to hand you yet.
There is no formal, contracted uptime guarantee on the paid tiers.
There is no SAML or SCIM provisioning.

If any of those is disqualifying for your organisation, the honest answer is that UtilitySpaces cannot meet that requirement today: it is offered as a managed service and there is no deployment you run yourself. Write to us anyway — knowing which requirement blocked a real team is how the order of this work gets decided.

Reporting a vulnerability

Email security@utilityspaces.com. Include what you did, what happened, and what you expected. We reply to every message within one business day. Please do not run automated scans against the production service or test against another customer's workspace — if you need an environment to work in, ask and we will arrange one.

Security questions

Can an agent read data from another customer's workspace?

No. Every query in the product is scoped to a workspace id that is re-resolved from your session on each request — the identifier in a URL is never trusted on its own. An agent exists inside one workspace and has no name for anything outside it.

Is my model provider API key readable by anyone?

No. Provider keys are encrypted at rest, and there is no read path in the product that returns one — not to the API, not to our own admin tools, not masked, not to you after you save it. The object that holds the key deliberately hides it from serialisation, so it cannot be picked up by a structured logger or an accidental JSON.stringify either.

Do you have SOC 2 or ISO 27001?

No, and we will not imply otherwise. Neither audit has been done. If your procurement process requires a certification, the honest answer today is that we do not meet it, and the managed service is the only way UtilitySpaces is offered — so there is no arrangement that satisfies that requirement right now. Tell us if it is the one blocking you.

Is two-factor authentication available?

Yes. Time-based one-time codes (TOTP) from any authenticator app, with ten single-use recovery codes. A workspace owner or admin can require it for everyone in the workspace. Passkeys are not supported yet.

Do you support single sign-on?

Yes. OpenID Connect against your identity provider — Entra ID, Okta, Google Workspace and anything else that publishes a discovery document — configured per workspace against a domain you verify by DNS. Accounts are provisioned on first sign-in. An owner can require single sign-on for that domain while keeping a break-glass owner who can still sign in with a password. SAML and SCIM are not supported.

How do I report a vulnerability?

Email security@utilityspaces.com with enough detail to reproduce it. You will get a human reply within one business day. We will not threaten anyone who reports a genuine issue in good faith, and we are happy to credit you.

See the boundary for yourself

Open a demo workspace and read the rules as the product enforces them: each agent's permissions, the approvals queue and the audit log. Demo agents run on the shared preview brain, which cannot call connectors, so real writes to your apps begin on a paid plan.

Try the demo See pricing

We reply to every message within one business day.