Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.neo.projectdiscovery.io/llms.txt

Use this file to discover all available pages before exploring further.

How Neo handles secrets across the model and execution boundary Security testing almost always requires credentials. API keys to authenticate against a target, tokens for internal services, passwords for staging environments, cloud provider credentials for infrastructure assessments. Neo handles these through an encrypted secrets system that lets the agent use your credentials during testing without ever exposing the actual values in its output, conversation history, logs, or the UI. Secrets are stored using AES-256-GCM encryption in the database. When you provide a credential, it is encrypted at rest and only decrypted at the moment a tool needs it during execution. The decrypted value lives in memory for the duration of the tool call and is never persisted in plaintext anywhere. SSH connections follow the same principle: saved SSH passwords or private keys are encrypted at rest and only used when Neo tests or connects to the configured host. The core of how this works is the reference pattern. When the agent needs to use a credential, it writes a reference like {{$API_KEY}} or {{$DB_PASSWORD}} in its tool calls rather than the actual value. At execution time, the tool resolves the reference to the real credential, performs the action, and returns the result using the original reference in the output. The model never sees, generates, or handles the plaintext secret. If the agent runs a curl command with {{$AUTH_TOKEN}} in a header, the sandbox receives the real token but the conversation shows only the reference. This resolution happens across all the tools where credentials are needed. Sandbox commands receive your secrets as environment variables, so any script or tool the agent runs can access them through standard environment variable patterns. The curl tool resolves secret references in headers, request bodies, and cookies. Browser tools resolve them in URLs, form inputs, and JavaScript execution, so the agent can log into authenticated applications without the password appearing in the conversation. Codemaps resolve git tokens for indexing private repositories. You add secrets through the credential vault in the Neo interface. Secrets are created in batch (up to 50 at once), with automatic duplicate detection. If a name like GITHUB_TOKEN already exists, the system auto-renames the new one to GITHUB_TOKEN_2. Secret names follow uppercase snake case convention (e.g., API_KEY, DB_PASSWORD, STAGING_TOKEN). If you provide a name in a different format, the system sanitizes it automatically. Secrets have a sticky behavior across conversations. When you select secrets for a task, those selections persist on the thread so subsequent messages in the same conversation continue to have access. Within a project, secret selections aggregate across all threads, so new conversations in the same project automatically inherit the credentials used in prior sessions. This means you do not need to re-select your secrets every time you start a new task against the same target. You can also mark secrets as default-available, which means they are automatically injected into every task without needing to be explicitly selected. This is useful for credentials you always need, like a personal GitHub token or a cloud provider key. For security isolation, some secrets are tool-scoped. Credentials like HackerOne API keys are only accessible to the specific tool that needs them and are filtered out of the sandbox environment variables. For HackerOne, add H1_API_IDENTIFIER and H1_API_TOKEN as described in the HackerOne integration guide. This prevents them from being exposed through general-purpose commands, even though the agent has root access to the sandbox. Secrets integrate directly with scheduling. When you create a scheduled task, it inherits the secrets from the session where it was set up. This means recurring security scans against authenticated targets run unattended without any manual credential handling. The secrets are resolved fresh at each execution, so if you rotate a credential, the next scheduled run picks up the new value automatically. The practical result is that you can hand Neo a target that requires authentication and the agent handles the full workflow securely. It logs in, navigates authenticated surfaces, tests protected endpoints, and reports findings, all while the actual credentials remain encrypted and invisible throughout the entire process.