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; every action it takes is attributable and recorded; and its credentials never reach the model or the logs. 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, cannot sign in, and cannot be phished or have credentials stolen, because there are none to 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 single Virtual Worker identity at the center, bounded by four labeled properties. Top left, non-login identity: no password, no sign-in, nobody can log in as the worker. Top right, deny-by-default role: Support Agent, Developer, or Inbox Manager, never admin, billing, or identity. Bottom left, self-ceiling delegation: a person can grant only the permissions they themselves hold. Bottom right, append-only transcript: every action is attributed to the worker and recorded, and the record is read-only. A caption states a worker can never exceed the access of the identity behind it.
A Virtual Worker is a governed identity bounded on four sides: it cannot sign in, holds a deny-by-default role, is granted only permissions its owner already holds, and leaves an append-only, attributed record of everything it does.

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, and nothing beyond it. 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.

A worker's identity fact grid in the editor, showing fixed attributes: Name Nova Reyes, Role Customer Support Agent, Status, Runtime, Container size, and Timezone. The role is a narrow permission role fixed to the worker; the worker is a named, attributable identity rather than a shared account.
Every worker is a distinct, named identity with a fixed permission role. Its actions are attributed to it alone, never to a shared account or a borrowed human credential.

Delegation is self-ceiling: a person can only grant a worker permissions they themselves hold. There is no path by which configuring a worker escalates anyone's access, and no way for a worker to end up with more than the person who set it up. Broad standing permissions are the most-cited cause of failed agent projects; 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. Delegation is self-ceiling: no one can grant a worker more than they hold themselves.

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 mirrored into your organization's history under a Virtual Workers view, and worker-sourced entries are append-only: they form an immutable, human-readable transcript of what the worker did, not a mutable log. Write actions are audit-logged with the worker's identity, the operation, and the time. A supervisor filters the sessions to a single worker and reads its full transcript; a compliance reviewer gets a real record rather than a guess.

Supervised Delegation for Administrators

After this section you will understand how a person can act as a worker for oversight without becoming it. An authorized administrator can open a delegated session that acts as a worker's own identity, for example to inspect or drive what the worker can reach, under a scoped, time-limited grant. The human's own authority is what permits it, the session is least-privilege and audience-bound, and the action remains attributable. This gives a supervisor a way to stand in a worker's shoes for review without handing a worker a human's credentials or a human a worker's standing access.

Where Credentials Live, and Why the Model Never Sees Them

After this section you will be able to answer where credentials are stored and how they are protected. A worker's linked credentials and channel tokens live in your organization's zero-knowledge, post-quantum secrets vault, encrypted on the device with hybrid post-quantum cryptography and unreadable to Backbuild. The protections a reviewer asks about:

  • The model never receives a plaintext secret. No tool returns one, because none exists. When a credential is needed to act, a trusted path outside the model substitutes the real value at the moment of use.
  • Redacted from every sink. Secret values are kept out of logs, the session transcript, backups, and the environment. A credential does not appear where it could be read back.
  • Encrypted in transit. Connections use current transport encryption, and the desktop stream a worker drives carries an additional hybrid post-quantum overlay.
  • Administrable. A worker's vault is visible to organization administrators, so a human can always audit and manage what a worker can use, and revoke it.

Where are credentials stored and how are they protected across logs, backups, and environment? In the zero-knowledge, post-quantum vault, encrypted on the device. The plaintext value is substituted only on a trusted path at the moment of use and is redacted from logs, transcripts, backups, and the environment. Connections are encrypted in transit.

Is there a human checkpoint on irreversible actions, and can it be bypassed? Yes, and no. Sending external email and pushing code always require a person, enforced at the server, and cannot be made automatic by any setting. The approver sees what the worker wants and why before deciding.

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 and disposable: provisioned for the work and torn down after, so a worker's runtime does not linger. A session that acts on behalf of a worker does so under a scoped, signed, time-limited grant that names who it acts for; a mismatch is rejected, and the grant is checked against a revocation list on every use, so tearing down a session refuses it even though it has not expired. The check fails closed: an error denies rather than allows.

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 capability it was not granted is denied no matter what a prompt says, and the approval floor on sending external email and pushing code holds regardless of any instruction the worker reads. Code a worker runs on its own machine is more constrained still, held to a default-deny allowlist that excludes sensitive families outright. An injected instruction can change what a worker tries to do; it cannot change what the worker is permitted to do.

Can the worker be tricked by prompt injection into acting outside its scope? It can be told to try, but the platform enforces its permissions and its approval floor independently of the model, so a denied capability stays denied and an irreversible action still requires a person. An injected prompt cannot widen a worker's actual reach.

Where to Next