Keeping your code and development workflow secure is important to us. Amp is built by Sourcegraph with the security of our enterprise customers in mind.

Frontier coding agents such as Amp are more powerful than the previous generation of AI coding tools. This document explains the security characteristics of Amp and helps enterprises make an educated risk assessment.

For any security-related questions or reports of potential vulnerabilities, email security@sourcegraph.com.

Certifications & Third-Party Assessments

Amp is SOC 2 Type II certified.

In addition, Sourcegraph is ISO 27001 certified, and has maintained GDPR and CCPA compliance for several years. Amp will be included in all upcoming reports and external penetration tests.

Visit security.sourcegraph.com to request a copy of our reports.

Infrastructure & Service Providers

Amp uses the following infrastructure and service providers:

“Partial code data” means snippets of or entire code files that are selected as context for the LLM requests, but not the entire codebase.

All of these providers except WorkOS and Stripe are also used by Sourcegraph Cloud.

We have no infrastructure or service providers based in China.

Data Security & Retention

Data such as threads, user information and telemetry on Amp Server is stored in a multi-tenant Google Cloud Platform project, where all service accounts are exclusive to this project.

The Amp Client and Amp Server do not see, store, clone, or index the entire codebase.

The Amp Enterprise plan (paid or trial) provides zero data retention for text inputs on all LLM providers, which means that any text (including code) sent to LLMs will not retain any input or output beyond the time it takes to generate an output. Images are subject to extremely limited retention periods by LLM providers to ensure compliance with law and the provider’s acceptable usage policy (AUP).

Thread Data

Thread data includes user messages, LLM responses, snippets of or entire code files used as context for the LLM requests, tool call results, and attachments. When a thread is explicitly deleted, all data for that thread is removed within 30 days of thread deletion.

When a user is deleted, thread data corresponding to that user is handled as follows:

• Threads in Enterprise workspaces: Threads created within an Enterprise workspace are owned by the enterprise who owns the workspace, not the individual user who created the thread. If a user leaves that workspace or deletes their account, their threads (and thread author attribution data, including user names and emails) remain in the workspace. We only delete workspace threads and associated user data when the enterprise’s contract with us ends.
• Threads in non-Enterprise workspaces: If the user is in a non-Enterprise workspace and deletes their account, the user’s threads will be deleted along with the user’s account information, pursuant to our Privacy Policy.
• Threads created outside any workspace: Threads created outside of a workspace are deleted when the user deletes their account along with their account information, pursuant to our Privacy Policy. Note that when joining a workspace with the same account as an individual user has used to create personal threads, the user understands and acknowledges that existing personal threads will be visible in the workspace to all workspace members unless: (a) the user makes those threads “private”, or (b) the user signs up to the workspace with a separate account under a separate email.

Encryption Standards

Amp uses industry-standard encryption practices to protect data:

• In Transit: All traffic in transit is encrypted using TLS 1.2+.
• At Rest: All data stored by Amp Server is encrypted at the volume level using AES-256. Backups are similarly encrypted.

Models in Use

See the Models page for a list of which LLMs are currently used by Amp. All model inference is performed on the infrastructure & service providers documented above.

Enterprise workspaces can disable the free mode to prevent the use of those free-mode models by all members of their workspace.

User Authentication

Amp Enterprise supports Single Sign-On (SSO) and Directory Sync through various identity providers, including Okta, for user authentication. We use WorkOS to provide this capability and the SSO configuration and management dashboard for Workspace Admins.

SSO can be configured to be the exclusive authentication method for your workspace, preventing the use of password-based authentication.

Directory Sync (e.g. SCIM) can be used for automatic provisioning and de-provisioning of user accounts and groups. This allows organizations to automatically manage user access based on their identity provider’s user directory, ensuring that access is granted or revoked when users join or leave the organization.

To set up SSO and Directory Sync, go to your Workspace Settings page.

Audit Logging

Audit logs for user authentication-related events are available to Workspace Admins in Enterprise workspaces.

Amp maintains comprehensive application audit logs for security and monitoring purposes. Logs are structured and include key fields such as timestamps, actor IDs, request details, and event information. These logs are collected internally and monitored by the Amp security team, but are not currently exposed to Workspace Admins.

Application audit logs log can be provided for Enterprise workspaces upon request, for example during customer audits or incidents.

Retention: Audit logs are retained for 30 days minimum.

Model Training

Amp does not train models on your data, unless you have explicitly opted into training.

If you’re on an Amp workspace, turning training on requires the approval of the Workspace Admin.

On an Amp Enterprise workspace plan (paid or trial) training can never be turned on and is always off.

To enable or disable training, go to User Settings.

(Amp’s free mode no longer requires opting into training.)

System Components

Amp consists of two components:

1. Amp Client: The end-user application that is used as a VS Code extension (in VS Code or a compatible fork) or a CLI program. The client provides the user interface, local code and context management, local settings, and local thread history. It communicates with and executes tools as requested by Amp Server (ampcode.com).
2. Amp Server: A multi-tenant cloud service at ampcode.com, hosted on Google Cloud Platform. It handles authentication, user accounts, workspaces, thread syncing and storage, and usage tracking. It also acts as a proxy for LLM inference between the Amp Client and the LLM providers listed above.

Amp doesn’t support Bring Your Own Key or self-hosted deployments.

User Interaction Example

When users use Amp, they create and send messages in threads to the agent. A thread is a single conversation between the user and the agent, with any number of back-and-forths among the user, tools, and LLM.

When a developer starts a new thread in an Amp Client, the client collects local contextual information such as code snippets, metadata about open files, and relevant editor state. For additional context, the agent may use built-in tools such as Bash or MCP servers (Model Context Protocol) to provide additional information. The collected context, along with the user’s prompt and conversation history, if applicable, is sent to the Amp Server and then to the LLM inference provider.

After processing, the LLM’s response is returned through the Amp Server back to the Amp Client. The Amp Client displays the response and takes additional actions based on the response, such as reading files requested by the LLM and sending them back to the Amp Server for the next step in the agentic loop.

The Amp Server stores these conversations in its PostgreSQL database in Google Cloud Platform, which enables team collaboration features such as thread sharing and auditing. Users can mark a thread as private to prevent it from being shared with other workspace members.

Client Security

• The VS Code extension stores credentials using VS Code’s built-in SecretStorage API, which uses the system’s native credential store (Keychain on macOS, Credential Manager on Windows, libsecret on Linux).
  • Thread history is cached locally by the extension and stored in the extension’s VS Code globalStorage directory.
• The Amp Client makes HTTP requests to the following domains. If you’re behind a corporate proxy, please allowlist these domains to ensure that Amp works correctly.
  • ampcode.com: For the Amp Server service.
  • auth.ampcode.com and authapi.ampcode.com: For authentication to ampcode.com.
• The Amp CLI stores credentials in ~/.local/share/amp/secrets.json on Linux and macOS, and %APPDATA%\amp\secrets.json on Windows.
• The Amp Client makes a best effort to avoid reading .env files and other credentials files.

Secret Redaction

Amp automatically detects and redacts secrets before they can enter threads or be transmitted to any external service. This protection operates at the lowest level of the system to ensure that detected secrets are never visible to the LLM, stored in local cache, transmitted to LLM providers, or saved on ampcode.com.

When a secret is detected, it is replaced with a redaction marker like [REDACTED:sourcegraph-amp] that indicates the type of secret found without exposing the actual value.

Supported Secret Types: Amp detects many common secrets including:

• Cloud Providers: AWS, Google Cloud, and Azure credentials.
• Development Platforms: GitHub, GitLab, Sourcegraph, and Amp access tokens.
• LLM Providers: OpenAI, Anthropic, and HuggingFace API keys.
• Common Services: Stripe, Slack, and npm tokens.
• Generic Patterns: API keys, webhook secrets, and password fields.

Limitations: Secret redaction is best-effort and may not catch all possible secret formats, especially:

• Secrets in non-standard formats or custom internal systems.
• Secrets that don’t follow recognizable patterns.
• Encoded or obfuscated secrets.

If a secret is not automatically redacted:

• Edit the message that precedes the secret being read and resend it, which will overwrite the thread contents on ampcode.com.
• Mark the thread as private (this prevents workspace sharing but does not remove the secret from ampcode.com).
• Consider rotating the exposed secret as a security precaution.

The secret detection patterns are regularly updated to cover new services and formats. Contact Support if you would like a secret redaction pattern to be added.

Vulnerability Disclosure Policy

Sourcegraph welcomes feedback from security researchers and the general public to help improve our security. If you believe you have discovered a vulnerability, privacy issue, exposed data, or other security issues we want to hear from you.

This policy outlines steps for reporting vulnerabilities to us, what we expect, what you can expect from us.

Systems in Scope

This policy applies to Amp (ampcode.com) and related digital assets owned, operated, or maintained by Sourcegraph.

Out of Scope

• We’re interested in prompt injection and LLM security research—please report findings to us. However, due to LLMs’ inherent nature and Amp’s code execution capabilities, these vulnerabilities aren’t typically eligible for bug bounty rewards.
• Assets not related to Amp, or not owned by Sourcegraph, are out of scope.

Vulnerabilities discovered or suspected in out-of-scope systems should be reported to the appropriate vendor or authority.

Our Commitments

When working with us, according to this policy, you can expect us to:

• Respond to your report promptly, and work with you to understand and validate your report;
• Strive to keep you informed about the progress of a vulnerability as it is processed;
• Work to remediate discovered vulnerabilities in a timely manner, within our operational constraints; and
• Extend Safe Harbor for your vulnerability research that is related to this policy.

Our Expectations

In participating in our vulnerability disclosure program in good faith, we ask that you:

• Play by the rules, including following this policy and any other relevant agreements. If there is any inconsistency between this policy and any other applicable terms, the terms of this policy will prevail;
• Report any vulnerability you’ve discovered promptly;
• Avoid violating the privacy of others, disrupting our systems, destroying data, and/or harming user experience;
• Use only the Official Channels to discuss vulnerability information with us;
• Provide us a reasonable amount of time (at least 30 days from the initial report) to resolve the issue before you disclose it publicly;
• Perform testing only on in-scope systems, and respect systems and activities which are out-of-scope;
• If a vulnerability provides unintended access to data: Limit the amount of data you access to the minimum required for effectively demonstrating a Proof of Concept; and cease testing and submit a report immediately if you encounter any user data during testing, such as Personally Identifiable Information (PII) or proprietary information;
• You should only interact with test accounts you own or with explicit permission from the account holder; and
• Do not engage in extortion.

Official Channels

Please report security issues via security@sourcegraph.com, providing all relevant information. The more details you provide, the easier it will be for us to triage and fix the issue.

Safe Harbor

When conducting vulnerability research, according to this policy, we consider this research conducted under this policy to be:

• Authorized concerning any applicable anti-hacking laws, and we will not initiate or support legal action against you for accidental, good-faith violations of this policy;
• Authorized concerning any relevant anti-circumvention laws, and we will not bring a claim against you for circumvention of technology controls;
• Exempt from restrictions in our Terms of Service (TOS) and/or Acceptable Usage Policy (AUP) that would interfere with conducting security research, and we waive those restrictions on a limited basis; and
• Lawful, helpful to the overall security of the Internet, and conducted in good faith.

You are expected, as always, to comply with all applicable laws. If legal action is initiated by a third party against you and you have complied with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through one of our Official Channels before going any further.

Note that the Safe Harbor applies only to legal claims under the control of the organization participating in this policy, and that the policy does not bind independent third parties.

Whitehat Hall of Fame

We’re grateful to the security researchers who help keep Amp secure. We thank the following security researchers for their responsible disclosure of vulnerabilities:

2025

• Zachary Sims on behalf of Canva.
• Gerred Dillon