Skip to main content

Account & Setup

API Keys

API keys are credentials used to authenticate with Asymptote programmatically. They can be used to integrate Asymptote into CI pipelines and other automated workflows, and are stored as secrets in the systems that use them.

Repository

A repository is a connected GitHub repository that Asymptote monitors. Each repository has its own policy configuration and vulnerability history. You can connect additional repositories at any time from the Asymptote dashboard.

Security Policies

Policy

A policy is a single security rule that defines something Asymptote should detect or enforce. Policies are expressed in natural language (e.g. “no hardcoded secrets”) and Asymptote translates them into enforceable rules automatically. Each policy has an enforcement type and can be written from scratch or selected from Asymptote’s built-in library.

Policy Pack

A policy pack is a collection of related policies grouped around a specific risk category or compliance standard, like OWASP Top 10 or HIPAA. Policy packs can be enabled or disabled per repository. Asymptote ships with built-in packs covering common standards, and you can create custom ones tailored to your team.

Enforcement Type

An enforcement type defines how Asymptote responds when a policy is violated. Each policy is assigned one of three types: Block prevents the pull request from merging, Warn flags the issue without blocking, and Monitor silently logs the vulnerability for review.

Threat Modeling

Threat Model

A threat model is a structured security analysis of a system that identifies assets worth protecting, trust boundaries between components, the attack surface exposed to potential adversaries, and the ways those adversaries could exploit weaknesses. Asymptote generates threat models for your repositories by analyzing your codebase, architecture, and data flows. The resulting report documents potential attacker stories, ranked findings by criticality, and existing mitigations so your team has a clear picture of your security posture.

Attack Surface

The attack surface is the set of entry points in a system where an attacker could interact with or attempt to compromise it. This includes API endpoints, webhook handlers, authentication flows, file upload paths, and any other interface that accepts untrusted input. A larger attack surface means more opportunities for exploitation; reducing it is one of the most effective ways to lower overall risk.

Trust Boundary

A trust boundary is a point in a system where execution or data passes between components with different levels of trust, such as from a user-facing request to a database, or from an external service callback to an internal API. Each trust boundary requires explicit validation, authentication, or authorization. Failures at trust boundaries are among the most common sources of vulnerabilities.

Attacker Story

An attacker story is a narrative scenario in a threat model that describes how a specific threat actor could exploit weaknesses in a system to achieve a malicious goal. Each story traces the attack path from initial access through to impact, identifies what currently prevents success, and informs prioritization of security fixes.

Code Generation

Coding Sessions

Coding Sessions is the AI observability view in the Asymptote dashboard. It logs every interaction between your coding agent and Asymptote, including the code changes evaluated, policies checked, and any violations found. Use it to audit agent activity and review what guardrails fired during a session.

Coding Agent

A coding agent is an AI-powered tool that writes or modifies code on your behalf. Asymptote integrates with popular coding agents including Cursor, Claude Code, GitHub Copilot, and Factory to enforce security policies in real time as code is generated.

Guardrails

Guardrails are real-time security checks that run inside your coding agent as code is being written, before it reaches a pull request. They surface violations inline in the IDE and can re-prompt the agent to generate safer code automatically. Guardrails are configured through hooks set up via the Asymptote CLI.

Hooks

Hooks are integration points in your coding tools that trigger Asymptote analysis during code generation. When an agent produces code, the hook sends the diff to Asymptote for evaluation against your active policies and returns the result inline.

Pull Request Security

PR Reviews

PR Reviews are automated security scans triggered when a pull request is opened. Asymptote analyzes the full diff against your active policy packs, posts inline review comments with AI-generated fix suggestions, and creates a check run that can be required to pass before merging. PR reviews are powered by the Asymptote GitHub Action.

Checks

Checks are pass/fail status indicators posted on GitHub pull requests after a security scan completes. You can configure branch protection rules in GitHub to require Asymptote checks to pass before merging.

Vulnerabilities & Scans

Scan

A scan is an on-demand security analysis run against a repository. Each scan evaluates your code against your active policy packs and may surface zero or more vulnerabilities depending on what is found. Asymptote supports three scan types: Static Analysis, Penetration Test, and Software Composition Analysis.

Static Analysis

Static Analysis is Asymptote’s AI-native SAST scan. Unlike traditional static analysis tools that rely on pattern matching, Asymptote reasons about data flow, taint propagation, and full exploit paths across your codebase to surface issues that rule-based scanners miss. It also evaluates any custom OpenGrep rules you have enabled, combining deterministic rule matching with AI-powered reasoning in a single pass.

Penetration Test

Asymptote’s Penetration Test goes beyond automated scanning by deploying a swarm of AI agents that actively simulate attacks against your application. Rather than flagging theoretical weaknesses, the agents attempt to find and chain together exploitable vulnerabilities the way a human attacker would, surfacing issues that only become visible under adversarial conditions.

Software Composition Analysis

Software Composition Analysis (SCA) scans your dependencies for known vulnerabilities and license compliance issues. Asymptote correlates findings against your active policies so SCA results are triaged and prioritized alongside the rest of your vulnerability findings, rather than appearing in a separate tool.

Vulnerability

A vulnerability is a security issue in your code that could be exploited or cause harm. Each vulnerability includes the affected code location, severity, exploit path, and an AI-generated fix suggestion.

Severity

Severity indicates how critical a vulnerability is. It is used to prioritize which issues to address first and determines whether a pull request can be merged based on your enforcement type settings. By default, Asymptote blocks on Critical and High severity vulnerabilities. Asymptote uses five severity levels: Critical, High, Medium, Low, and Informational.

Critical

A Critical vulnerability represents an immediate risk of exploitation with significant impact. Critical findings should be resolved before merging and will block pull requests under the default enforcement type settings.

High

A High vulnerability is a serious issue that is likely exploitable and should be prioritized. High findings block pull requests by default alongside Critical.

Medium

A Medium vulnerability represents a moderate risk that warrants attention but does not block merging by default. Teams can configure enforcement type settings to block on Medium if their security posture requires it.

Low

A Low vulnerability is a minor issue with limited exploitability or impact. Low findings are surfaced for awareness but do not block merging by default.

Informational

An Informational finding carries no direct risk but is flagged for awareness or best practice guidance. Informational findings can be filtered out via severity thresholds if they add noise for your team.