Security overview

PWR runs AI agents against your code, so security matters more here than in most tools. This page describes the controls the platform implements today, then states plainly what is limited, what has not yet been verified against live services, and what we do not claim. PWR is pre-launch; this page will change as that work is completed.

How the platform is structured

PWR separates a control plane from an execution plane.

• The control plane (the dashboard and API) manages organizations, projects, tasks, credentials and approvals. It never executes customer code.
• The execution plane (workers) runs agents. Each run gets its own disposable workspace with a copy of the project source, its own home and temporary directories, and its own process group. Nothing is shared between runs, and the workspace is deleted when the run ends, including after failure or cancellation.

Tenant isolation and access control

• Every request to an organization's data checks that the caller is a member of that organization. Requests for another organization's resources are answered as "not found".
• Roles (owner, admin, developer, reviewer, viewer) are enforced by the API. Sensitive actions, such as granting ownership, changing billing, or setting the command that validates a project, are limited to higher roles. An organization cannot be left without an owner.
• Authentication tokens are verified against an explicit list of allowed signing algorithms, with issuer, audience and expiry checked.
• The development-only sign-in method is disabled in production. Supabase Auth is the planned production sign-in provider, and accounts must have a verified email address.

Credentials

• AI provider keys and integration credentials are encrypted at rest with AES-256-GCM, and each encrypted value is bound to its organization and record.
• Stored secrets are write-only: the API never returns them. Only a fingerprint is shown. Only the execution worker can decrypt a model provider key, and only to run a task.
• Model provider keys cannot be attached to outbound integrations, which prevents an administrator from redirecting a key to a server of their choosing.
• Known secret values, and common secret formats, are redacted from run events, logs, diffs and test output before they are stored.

GitHub access

PWR connects through a GitHub App. You choose which repositories it can reach.

• For each run, PWR requests a short-lived installation token limited to the single repository involved and to the narrowest permissions for the job. Reviews and checks use read-only tokens.
• The AI agent never receives the repository token. The worker pushes the task branch after the agent has finished.
• Tokens are held in memory only. They are not written to the database, repository configuration, logs or pull-request text.
• Connecting an installation requires proof through GitHub sign-in that you control the account: for an organization, you must be an active organization admin.
• If the App is uninstalled or suspended, or a repository is removed from it, runs and merges on the affected repositories are blocked.

Agent execution

• Agents run in a separate process with a minimal environment, operating-system resource limits, and a time limit. In production the agent process runs as a separate unprivileged user that cannot read the worker's own configuration or keys.
• File tools are confined to the run's workspace.
• What an agent is allowed to do is set by platform configuration, not by the prompt. Instructions found in repository files, documents or tool output are treated as data. Every tool decision is logged.
• Calls to external integrations go through a tool gateway that checks, on every call, that the agent has been granted that tool and that the tool has been approved. Tools are unapproved by default, and a tool whose definition changes must be approved again. Calls are capped per run and every decision is recorded.
• Outbound integration endpoints are validated to block requests to internal or private network addresses.
• Each agent can have a maximum cost, a maximum number of turns and a time limit per run. Organizations can set spending limits.
• Because an agent can modify its workspace, the worker neutralizes repository-level git hooks and configuration before running its own git commands, and fails the run if the repository metadata has been tampered with.

Review, approval and merge

• Before a task branch is pushed, the changes are scanned for known secret values and common secret formats. If one is found, nothing is committed or pushed.
• Each pull request gets an automated review that runs separately on a fresh copy of the code with read-only tools. A review that cannot be interpreted is treated as a failure, never as an approval.
• Merging requires a human approval. Reviews, CI results and approvals are bound to the exact commit they were made for. If the branch changes, earlier approvals stop counting and the task returns to review.
• A merge gate re-checks these conditions against the live state of the pull request immediately before merging, and the merge is pinned to the approved commit.
• Actions with external side effects, such as pushes, pull-request creation and merges, are recorded before they are attempted. If the outcome is uncertain, the action is not blindly repeated.

Webhooks, audit and abuse protection

• Incoming GitHub and Stripe webhooks are verified by signature. Duplicate and replayed deliveries are detected and ignored.
• Every change made through the API is written to an audit log with the actor and a request identifier.
• Credential endpoints are rate limited per IP address, and the number of live event streams per user is capped.
• Card payments are handled by Stripe. PWR does not store card numbers.

Current limitations and what is not yet verified

• Execution is currently scoped to trusted repositories. The default execution mode runs the agent as a restricted process on the worker host. That is not a security boundary against deliberately hostile code. Until container isolation is fully validated, PWR should only be used on repositories whose contents you trust.
• Container isolation is partly validated. A hardened container mode (non-root user, read-only filesystem, all capabilities dropped, memory and process limits) has been exercised on a live container runtime. It has not yet been validated with restricted outbound networking, a registry-built image, or a real model run.
• No outbound network restrictions for agents. An agent that is allowed to run shell commands can reach the internet, and is not confined to its workspace by the file-tool restriction.
• A shell-enabled agent can read its own model provider key. The key must be present in the agent's environment. Redaction removes it from stored output but cannot stop it being sent over the network. A credential broker to remove this exposure is planned.
• Secret detection is pattern-based. Secrets in a format the platform does not recognize, and has not seen, can pass through redaction and the pre-push scan.
• Prompt injection cannot be fully prevented. The safeguards are the limits on what an agent can do, the automated review and the human approval before merge — not an assumption that the model will ignore malicious instructions.
• The automated reviewer uses the same model and credential as the implementing agent by default. It is independent in context and tools, not in model, unless you configure a different reviewer.
• GitHub controls are verified against a test double, not yet against github.com. Live verification is pending.
• Billing flows are verified against a simulated Stripe, not yet against Stripe itself. Live verification is pending.
• Production sign-in through Supabase Auth has not yet been tested against a live project.
• Tenant isolation is enforced in the application layer. Database row-level security is not yet in place.
• The audit log is append-only by application policy, not yet enforced by database permissions.
• Rate limiting is per server process, and the dashboard does not yet set a Content Security Policy.
• The worker holds a repository write token in memory during a run, so the worker host is a trust boundary.
• Ownership of a GitHub installation is checked when it is connected, not continuously afterwards.

What we do not claim

• PWR holds no security or compliance certifications or attestations. We do not claim SOC 2, ISO 27001, HIPAA, PCI DSS or any similar status for PWR itself.
• PWR has not yet had an external security audit or penetration test by an independent firm.
• We offer no uptime guarantee or service level agreement.
• We make no commitment about the country or region where data is stored.
• We do not claim that PWR is safe to run against untrusted or hostile code.

Reporting a vulnerability

If you believe you have found a security issue in PWR, email SECURITY_EMAIL. Please include a description of the issue, the steps to reproduce it, and the impact you think it has. Please do not access other customers' data, disrupt the service, or disclose the issue publicly before we have had a chance to investigate. We will acknowledge your report and keep you informed of our progress.

For how we handle personal information, see the Privacy Policy. For other questions, use the contact page.