Skip to content
PWR

Reference

Security and permissions

Roles, tenant isolation, credential encryption, run sandboxing, the tool gateway and approvals in PWR, with known residual risks.

This page describes the security controls PWR has today and, just as plainly, what they do not cover. PWR holds no security certifications and has not completed a third-party audit. A summary is on the Security page.

Status: The controls below are implemented and regression-tested, and the code has been through internal independent reviews with findings fixed. PWR is pre-launch: no production environment is deployed yet, and every GitHub-related control has been verified against a simulated GitHub only.

Roles and permissions

Access is by organization membership with five roles: owner > admin > developer > reviewer > viewer. The full matrix is in Account creation. Points that matter for security:

  • Roles are enforced by the API on every request.
  • A project's validation command and workspace source decide what code runs on the execution side, so only admins and owners can set them. Treat granting the admin role as granting the ability to run commands in your project's execution environment.
  • Who can approve and who can merge is set per project (defaults: reviewer and admin).
  • Every mutating action is written to an append-only audit log with the actor and a request id.

Tenant isolation

Every organization-scoped request checks membership. A request for another organization's resource returns 404, including runs, events, artifacts and usage. Isolation is enforced in the API layer; database row-level security is not in place yet.

Credential encryption

  • Provider keys and integration secrets are encrypted at rest with AES-256-GCM, bound to the organization and the record.
  • Secrets are write-only. PWR Studio shows a fingerprint, never the value.
  • Only the execution worker can decrypt a model-provider key, and only for a run.
  • A model-provider key cannot be bound to an integration, so an admin cannot redirect it to a host they control.
  • Logs are redacted and request bodies are not logged.

How runs are isolated

  • The API never executes your code. Code runs only in worker-managed sandbox processes.
  • Each run gets a disposable workspace, its own home and temp directories and its own process group, all removed afterwards.
  • The sandbox runs with a scrubbed environment, CPU, memory, process and file-size limits, and a wall-clock timeout. File tools are confined to the workspace.
  • A credential broker keeps the real model-provider key outside the sandbox; the agent sees a placeholder.
  • The agent never receives your repository token. The worker pushes after the agent exits.
  • Instructions found in repositories, documents and tool output are treated as data. What an agent may do comes from its tool policy, not from anything it reads.

Status: The default runner isolates accidents, not hostile code, and is intended for repositories you trust. A hardened container runner (read-only filesystem, no capabilities, unprivileged user) has been validated on one local Docker daemon, but not with bridge networking, an egress allowlist or a real model run.

The tool gateway

Agents reach external integrations only through a gateway.

  • Each run has its own gateway token.
  • Every call is checked: the agent, its grant for that tool, the tool's approval, the integration's status and project restrictions.
  • Tools discovered from an integration are unapproved by default. If a tool's definition changes after approval, it must be approved again.
  • Integration endpoints are checked against server-side request forgery: private and internal addresses are refused, and redirects are not followed.
  • Calls are capped at 200 per run and every decision is recorded.
  • A tool call with side effects is recorded before it is sent. If its outcome is unknown it is never replayed automatically; it blocks merging until an admin reconciles it.

Tools marked as requiring approval are currently denied. Per-call human approval is planned.

Approvals and the merge gate

  • An independent reviewer runs on a fresh clone with read-only tools.
  • Human approval is always required; the setting is locked. Auto-merge is locked off.
  • Reviews, approvals and CI evidence are bound to a commit. New commits invalidate them.
  • The merge is pinned to the approved commit and passes 11 checks. See GitHub integration.
  • Before a push, the change is scanned for known secret values and well-known key patterns. A hit blocks the commit and the push.

GitHub access

  • Tokens are created per use, scoped to one repository and the narrowest permission set for the job: read-only for reviews, write for implementation, merge-scoped for merging. They are never stored.
  • Claiming an installation requires proof that you control the GitHub account.
  • Webhooks are signature-verified, size-capped and protected against replay.

Known limitations and residual risks

  • Shell-enabled agents. An agent allowed to use the shell can read whatever its sandbox user can read and can reach the network. Enable shell only where needed.
  • No egress allowlist. Network access from the sandbox is not restricted yet.
  • Prompt injection. Agents read repository content and tool output, which can contain misleading instructions. The defence is structural: tool policy, gateway grants, the secret scan, independent review and a human approval before merge.
  • Secret detection is pattern-based. A secret of an unknown shape that PWR never saw can pass the scan and the redactor. The changed-files archive of a run is not scrubbed; it is restricted to developers and above.
  • Worker trust boundary. During a run the worker holds a write token for your repository in memory.
  • Reviewer independence. By default the reviewer shares the implementer's model family and credential.
  • Installation ownership is checked at claim time only.
  • At-least-once execution. After a worker crash a run restarts from scratch, and the first attempt's usage is still recorded.
  • Sign-in rate limiting is per API process.
  • Cost figures are estimates from reported usage, not reconciled with provider invoices.

What PWR does not claim

No SOC 2, ISO 27001 or similar certification. No uptime commitment is published. SSO is not implemented. If you need details for a security review, contact us.