Security and Governance

A worker that can log into systems and take actions is exactly what a security reviewer scrutinizes, so Backbuild treats a Virtual Worker as a first-class, governable identity rather than a convenience. Each worker is a distinct, managed non-human identity that cannot log in; it is deny-by-default and least-privilege; it can never escalate to organization administration, billing, or member and role management; its runs are attributable and recorded; and its linked sign-ins are sealed in your vault and confined to the worker that uses them. After this page you will be able to answer a vendor-security review: what identity a worker runs under, what it can and cannot do, how its actions are audited, where its credentials live, and how it is isolated.

The governance controls below apply to every worker, on every plan, and are enforced at the server. They are not a paid add-on and cannot be switched off by a setting.

A Managed Non-Human Identity, Not a Shared Account

After this section you will be able to answer what identity a worker runs under. Each Virtual Worker is its own distinct identity in your organization, created when the worker is hired. It is a non-login identity: it has no password and cannot sign in, so there is no sign-in to phish or steal. A worker is never a shared service account and never a person's borrowed login. This is what a modern non-human-identity review asks for: every autonomous actor is a governable identity of its own, so its access is set and reviewed centrally and its actions are attributed to it and no one else.

A worker is a governed identity It cannot sign in no password and no interactive sign-in It holds one narrow role Support Agent, Developer, or Inbox Manager; never administration, billing, or identity management A fixed permission ceiling only what the three worker roles carry Append-only transcript the worker's entries cannot be edited
Four properties bound every Virtual Worker: it cannot sign in, it holds one narrow role, its permissions never go beyond what the three worker roles carry, and its transcript entries cannot be edited.

Deny by Default, and Never an Administrator

After this section you will be able to state the ceiling on a worker's permissions. A worker holds one of three narrow roles, Support Agent, Developer, or Inbox Manager. Your administrators can also add it to a group or department, but one that would give it any permission outside those three roles is refused. The model is deny by default: a capability the worker was not explicitly granted is denied, so its reach cannot quietly grow. Certain families are excluded outright and can never be granted to a worker:

  • Organization administration. A worker cannot change organization settings or manage the organization itself.
  • Billing. A worker cannot touch billing, subscriptions, or payment.
  • Identity and access management. A worker cannot manage members, roles, or permissions.

These exclusions are a hard boundary in the platform, not a policy a setting could relax: no worker role includes an administrative, billing, or access-management capability, and there is no switch that adds one.

The ceiling is fixed by the platform, not by the person who configures the worker: whoever sets its role or adds it to a group or department, an administrator included, can give it only permissions the three worker roles carry. When a worker's role is set, the platform does not compare it with the configuring person's own permissions, so give the permission to manage virtual workers only to people you would trust with everything a worker role can do. Broad standing permissions are a common way agent projects go wrong; Backbuild's answer is to make the narrow, per-role, deny-by-default grant the only option.

What identity does a worker run under, a shared account or a borrowed credential? Neither. Each worker is its own distinct, managed, non-login identity that cannot sign in. Its actions are attributed to it alone.

Can a worker escalate to organization administration, billing, or identity management? No. Those families are excluded from every worker role and cannot be granted. Whoever configures a worker, the most it can hold is what the three worker roles carry.

Attributable and Recorded: The Audit Trail

After this section you will be able to produce a record of everything a worker did. Every worker action is attributable to the worker's identity and recorded. Its prompts and its own responses are kept as conversations marked Virtual Worker, and the worker's entries are append-only: once written they cannot be edited, so the transcript records what the worker did rather than a mutable log. Write actions are audit-logged with the identity that performed them, the operation, and the time, so a compliance reviewer gets a real record rather than a guess.

Acting as a Worker

After this section you will understand how a person or a tool can work with exactly a worker's access. The person who hired a worker, or someone it is shared with as Can edit, can create a session that acts as the worker through the REST API, so a script or a command-line tool works with the worker's own permissions and no more. A Can edit share is enough on its own, whatever the person's role, so share a worker as Can edit only with people you would let act as it. Creating one requires that the person signed in within the last few minutes. The session lasts seven days unless a longer life is asked for, and never more than a year; each person holds at most one such session per worker, and creating a new one revokes the previous one. Creating it is audit-logged, and everything done with it is attributed to the worker. A worker's own account still cannot sign in interactively.

A chat can act as the worker too. In Chat or Ask AI, the person who hired a worker and people it is shared with as Can edit can set a chat's Run on to the worker. The chat then runs in one of the worker's own slots, on that slot's linked account and with what that slot can reach, which can be more than the person could reach on their own. Each time a chat takes a slot it is audit-logged with the person who started it. Share a worker as Can edit only with people you would let direct its work.

A Worker's Inbox Has One Owner

After this section you will be able to answer who controls a worker's mail. A worker's inbox is owned by the worker, and whoever owns the worker holds owner rights on it. Beyond the worker and its owner, nobody reads it unless the inbox is delegated to them, and being able to see the worker does not change that. A person can give a worker only an inbox they own, never one that is merely delegated to them, never one another worker holds, and never a sign-in address such as their own account email, because a worker must never receive anyone's sign-in or account recovery mail. When an inbox stops being a worker's it returns to the worker's owner. Anything a person does in a worker's Email tab is recorded as that person's action, not the worker's. See A Worker's Inbox and Calendar.

Where Credentials Live and Who Can Reach Them

After this section you will be able to answer where credentials are stored and how they are protected. A worker's linked sign-ins live in your organization's zero-knowledge, post-quantum secrets vault, in the vault bound to the worker, encrypted with hybrid post-quantum cryptography. An API key linked instead of a sign-in is encrypted by Backbuild before it is stored, outside the zero-knowledge vault. The protections a reviewer asks about:

  • No tool reads a secret out. The secrets tools a worker can use list, describe, and manage vault entries, but none of them returns a stored value; where a task needs one, they hand back a placeholder instead.
  • Linked accounts stay inside the worker's container. When a container worker starts, each linked coding-agent account is restored into its container for the coding tool in its slot. Only that slot can read it, never another slot, it is not saved in the persistent home folder, and it is left out of the session logs the container uploads. The coding tool and the work it does run as the same slot, so treat a linked account as reachable by that slot's work: link accounts dedicated to the worker, never a person's own, and use Unlink to cut one off.
  • Encrypted in transit. Connections use current transport encryption. A worker's terminals add a hybrid post-quantum channel; its desktop stream is protected by TLS.
  • One vault item per account. Each AI account a worker links through a provider sign-in is sealed in a vault item of its own, so refreshing or revoking one account never touches another.
  • Managed by people. The vault a worker uses is the one bound in its Configure wizard, step 4, and Change vault replaces it; Unlink in step 5 removes an account from the worker's pool.

Where are credentials stored and how are they protected across logs, backups, and environment? A linked sign-in is in the zero-knowledge, post-quantum vault, in a vault item of its own, and an API key linked instead is encrypted by Backbuild before storage. No tool returns a stored value. A container worker's linked accounts are restored only into its own container, for its own slots, and are not saved in its home folder or its uploaded session logs. Connections are encrypted in transit.

Is there a human checkpoint on irreversible actions? Sending external email and pushing code are locked to Always supervised by the server, a worker's help desk runs come back as internal drafts, and a workflow transition marked human-only is never taken by a worker. A worker that runs coding agents in a container acts through its tools while it works, so read Autonomy and Approvals for exactly where that leaves you.

Isolation Between Tenants and Sessions

After this section you will be able to state how a worker is confined. A worker runs strictly inside your organization's boundary, under per-organization access control, and cannot cross into another tenant. When a worker operates a container, that container is isolated from every other container and from private network ranges, and closing it releases the machine. Every session that acts for a worker names the worker it acts for and expires; one that has been revoked is refused even before it expires.

Resistance to Prompt Injection

After this section you will understand why a worker cannot be talked out of its bounds. A worker reads outside content, ticket text, web pages, email, so the natural worry is that a crafted message tricks it into acting beyond its scope. The defense is structural rather than persuasive. A worker's permissions are enforced by the platform, not by the model's willingness to comply: a tool its role does not allow is denied no matter what a prompt says, the tools a run may use can be narrowed by a skill but never widened, and nothing in a ticket or a message can add one. A workflow transition marked human-only stays with people. What an injected instruction can still do is steer the worker within what it is allowed, for example toward a reply on a ticket it is working. For a worker that runs in a container, what it is allowed includes reaching the public internet and reading what its container holds, so keep secrets out of its container and the repositories it works on. That is why the narrowest role, tight workflow states, and review of its first runs matter.

Can the worker be tricked by prompt injection into acting outside its scope? It can be told to try, but the platform enforces its permission role independently of the model, so a denied tool stays denied and a human-only transition stays with people. An injected prompt cannot widen a worker's actual reach; within that reach it can change what the worker does, so keep the reach narrow.

Where to Next