Security

Reporting a vulnerability

If you discover a security vulnerability in 143, please report it responsibly. Do not open a public GitHub issue for security vulnerabilities.

Preferred method: Use GitHub's private security advisory reporting on the repository's Security tab.

Alternative: Email security@assembled.com, and review the repository's SECURITY.md.

Supported versions

We currently support the hosted service at 143.dev and the latest code on the repository's default branch. Because the open-source project moves quickly and does not currently publish long-term support branches, older forks or unpatched deployments may not receive coordinated fixes.

Safe harbor and testing rules

We support good-faith security research that avoids privacy violations, service disruption, destructive testing, social engineering, spam, and persistence in other users' data. Stop testing and contact us immediately if you access non-public data.

What to include

• Description of the vulnerability and its potential impact
• Steps to reproduce or a proof of concept
• Affected versions or components
• Any suggested fixes, if you have them

Response timeline

• Acknowledgment: within 14 calendar days
• Triage and severity assessment: within 30 calendar days
• Investigation complete: within 60 calendar days
• Remediation target: we aim to remediate confirmed issues according to severity, with coordinated disclosure timing based on exploitability and user impact

These targets are best-effort goals. We will keep you informed throughout the process. If you have not heard from us within the acknowledgment window, please follow up. See the repository's SECURITY.md for full details including severity tiers.

Security design

143 is designed with security in mind:

• Sandboxed execution - coding agents run in isolated containers, separate from the host system
• Minimal permissions - integrations request only the scopes necessary to function
• Hosted-service transport security - production traffic to 143.dev is intended to use TLS; self-hosted operators are responsible for their own deployment configuration
• Credential handling - credentials are stored with platform protections, and some credentials may be injected into sandboxes when needed to run a configured agent or integration workflow
• Sensitive state treatment - workspace snapshots and agent state are treated as sensitive because they may contain customer content and temporary credentials
• Open source - the entire codebase is public and auditable under the MIT License

Scope

This page covers the 143 open-source project and the hosted service at 143.dev. Vulnerabilities in third-party dependencies should also be reported to the relevant maintainers, but we still want to know about them so we can patch or upgrade our usage promptly.

Recognition and rewards

We appreciate the work of security researchers. With your permission, we are happy to credit you in the security advisory and release notes when a fix is available. We do not currently operate a formal bug bounty program, but we may offer recognition or rewards at our discretion for reports of significant vulnerabilities.

Contact

For security questions that are not vulnerability reports, reach us at security@assembled.com.