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.

Agentic coding tools 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

Sourcegraph is ISO 27001 certified, holds a SOC 2 Type II attestation, and has maintained GDPR and CCPA compliance for several years. This year, we’ll also include Amp in every upcoming report and external penetration test. See reports at security.sourcegraph.com.

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. Data at rest on Amp Server is encrypted using AES-256, and traffic in transit is encrypted using TLS 1.2+.

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

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. For all users and teams, all thread data is removed within 30 days of thread or user deletion.

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).

User Authentication

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

Audit logs for user authentication-related events are available to Team Admins in Amp Enterprise. Comprehensive audit logs are collected internally by Sourcegraph for security and monitoring purposes but are not yet exposed to Team Admins.

Model Training

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

Training Mode is off by default and requires explicit opt-in by the user (and Team Admin if the user is on a team).

Training Mode is always off for users on an Amp Enterprise team (paid or trial).

To enable or disable Training Mode, go to User Settings > Advanced Settings.

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, teams, 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 team 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: 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 team 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.

Bill of Materials

Amp provides a Software Bill of Materials (SBOM) in CycloneDX format at /bom.json which catalogs all open source dependencies used in Amp. It is automatically generated during the build process and updated with each release.

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