Product capability statement · reviewed 25 August 2026
Security
OpenAgent routes source code and task instructions through autonomous workers. Trust starts with naming that boundary precisely: what the product enforces now, what you can change, and what it does not yet do.
This is a product capability statement, not a certification, penetration test, uptime report, or claim about a model provider’s controls. Provider data handling is described in the privacy policy.
Enforced by the product
Implemented
These controls are present in the application and execution path today.
- Workspace-scoped access
- Authenticated sessions and API keys resolve to one workspace. Database row-level policies and server-side workspace checks scope tenant records before they are returned or changed.
- One-way API key storage
- OpenAgent stores a SHA-256 digest, prefix, and last four characters. The plaintext key is shown once and cannot be recovered from the database.
- Short-lived repository execution
- Workers operated by OpenAgent clone repository work into an isolated Vercel Sandbox. GitHub tokens are minted for the run, scoped to the named repository, and revoked when it ends or expire within an hour.
- Guarded actions and a run record
- Destructive tool calls require a human decision. Routing, attempts, verification, cost, and task events remain attached to the task so the final result can be inspected.
Controlled by workspace owners
Configurable
These controls exist, but their values depend on the workspace or request.
- Write approvals
- Owners and admins can require human approval for every tool classified as write. Destructive tools remain approval-gated regardless of that setting.
- Spend boundaries
- A workspace monthly cap is configurable in Settings, and each task can carry its own
max_cost_usdceiling. Work is refused when the applicable boundary is met. - API key lifecycle
- Owners and admins can create separate labelled keys and revoke them immediately. The live and test labels organise keys; both run real work and use the same security and billing path.
- Provider data policy
- Owners and admins can require no provider training or provider zero data retention. OpenAgent filters catalogue eligibility, attaches the matching Gateway request control, and refuses direct or external paths it cannot enforce.
- Strict-policy worker exclusion
- External workers are excluded under a strict provider policy. Sandboxed coding CLIs require team-wide Gateway ZDR because they cannot attach per-request AI SDK controls.
Current product limits
Not available
Do not design a security or compliance requirement around these controls today.
- Self-service data lifecycle
- There is no workspace deletion or complete data-export control in the dashboard. An owner must contact support, and the request is verified before workspace records are removed.
- MFA and session controls
- OpenAgent does not currently provide workspace-enforced MFA, a session inventory, remote session revocation, login history, or step-up authentication for sensitive actions.
- Organization audit log
- Task timelines preserve execution evidence, but there is no complete organization-wide audit log or export for membership, settings, billing, key, and policy changes.
- Enterprise identity lifecycle
- SAML SSO, SCIM provisioning, domain claims, just-in-time provisioning, and enforced identity-provider login are not available today.
- Published assurance reports
- OpenAgent does not currently claim SOC 2 or ISO 27001 certification and does not publish a penetration-test or third-party audit report. This page should not be read as one.
- Published recovery evidence
- OpenAgent does not publish backup restore-drill results, disaster-recovery objectives, incident-response service levels, or third-party uptime history today.
Responsible disclosure
Found a vulnerability?
Email the people who operate the service with SECURITY in the subject. Do not open a public issue with exploit details.