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

# Environment Variables

> Configure credentials and endpoints so Neo can connect to your tools and services

Environment variables let Neo connect to virtually any tool in your stack via API. Configure credentials and endpoints once, and Neo can pull context from cloud providers, create tickets in your issue tracker, trigger CI/CD workflows, and take action across your entire security and development ecosystem.

In Neo, environment variables are stored and managed as [Secrets](/platform/settings/secrets). They don't have to be sensitive values: any configuration your agents need at runtime, whether a credential, a base URL, a project ID, or a feature flag, can be stored as a secret and made available as an environment variable inside the sandbox.

## How they are used during execution

Secrets must be explicitly specified when starting a task to be accessible. There are two ways to do this:

* **Select from the task bar**: Click **Secrets** before submitting your prompt and select the variables you want available for that run.
* **Reference by name in your prompt**: Mention the variable name directly in your task prompt and Neo will use it. For example: "Run the scan and authenticate using `BURP_API_KEY`."

When an agent calls a tool that needs credentials or config:

1. The agent resolves only the explicitly defined environment variables for the current run
2. The sandboxed tool receives only those specified values (e.g., API tokens, base URLs)
3. The tool fetches data or performs the requested action
4. Outputs and artifacts are captured to your stored files for reuse

Examples:

| Category | Example Variables |
| :- | :- |
| Cloud infrastructure | `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_REGION`, `GCP_PROJECT_ID`, `AZURE_SUBSCRIPTION_ID` |
| Version control | `GITHUB_TOKEN`, `GITLAB_TOKEN`, `BITBUCKET_APP_PASSWORD` |
| CI/CD pipelines | `JENKINS_URL`, `JENKINS_API_TOKEN`, `CIRCLECI_TOKEN`, `BUILDKITE_API_TOKEN` |
| Container registries | `DOCKER_REGISTRY_URL`, `DOCKER_USERNAME`, `DOCKER_PASSWORD`, `ECR_REGISTRY` |
| Ticketing and project management | `JIRA_BASE_URL`, `JIRA_API_TOKEN`, `LINEAR_API_KEY`, `ASANA_ACCESS_TOKEN` |
| Monitoring and observability | `DATADOG_API_KEY`, `NEW_RELIC_API_KEY`, `GRAFANA_URL`, `PROMETHEUS_ENDPOINT` |
| Communication | `SLACK_WEBHOOK_URL`, `SLACK_BOT_TOKEN`, `PAGERDUTY_API_KEY`, `DISCORD_WEBHOOK` |
| Security tools | `SNYK_TOKEN`, `SONARQUBE_URL`, `SONARQUBE_TOKEN`, `CHECKMARX_API_KEY`, `H1_API_IDENTIFIER`, `H1_API_TOKEN` |

## Security and access control

For security reasons, secrets are only accessible when explicitly defined in your prompt or agent configuration. Agents and sub-agents cannot list or enumerate all available environment variables in your account.

**You must be specific:** If you want an agent to use `JIRA_TOKEN` or `AWS_REGION`, define those exact variable names in your prompt or agent setup. This ensures:

* No accidental exposure of sensitive credentials
* Clear visibility into which secrets each agent can access
* Isolation between different agents and workflows
* Controlled access to only the environment variables needed for the task

This explicit definition requirement prevents agents from discovering and accessing credentials they shouldn't have, maintaining strict security boundaries across your operations.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.