Security & Data Handling
How Azent protects customer data and how information moves through the service.
Our security approach
Azent is built for teams that work in Azure DevOps and need clear control over source code, work items, pull requests, and related project information. We use scoped access, isolated agent runs, encrypted transport, and customer-controlled configuration to keep data handling limited to the work you ask Azent to perform.
This page summarizes our operating model in practical terms. It complements our Privacy Policy and Terms of Service.
Who owns and controls the data
- You remain the owner of your code and Azure DevOps content. Azent does not claim ownership over repositories, work items, pull requests, wiki pages, build logs, or comments processed during an agent run.
- Your workspace configuration controls what Azent can access. Access is determined by the Azure DevOps bot user, its project permissions, configured service hooks, and the AI provider settings selected for the workspace.
- You decide when work starts. Azent acts when an authorized user triggers it from Azure DevOps or the dashboard. It does not independently browse projects or run tasks without a request.
How data moves during an agent run
- An authorized user asks Azent to perform work, usually by mentioning the bot in Azure DevOps or using the dashboard.
- Azent reads the relevant context from Azure DevOps, such as the work item, pull request, comments, repository files, or build information needed for the task.
- The agent works in an isolated runtime for that request. It may read files, edit code, create a branch, open a pull request, reply to comments, or trigger validation based on the request.
- If the selected AI connection requires it, the prompt and relevant task context are sent to the configured AI provider so the agent can reason and generate changes.
- Results are written back to Azure DevOps as code changes, pull requests, comments, work item updates, wiki updates, or pipeline actions.
We keep the information sent to the agent focused on the task. Users should avoid asking Azent to process data that is not needed for the requested work.
AI provider options
Azent supports different AI connection models because teams have different data residency and governance needs.
- API connection: task context may be sent to the configured AI provider, such as OpenAI or Anthropic, under that provider's terms and data processing commitments.
- Azure AI Foundry connection: the AI workload runs through the Azure configuration selected for the workspace, which can help teams align processing with their Azure governance model.
- Self-hosted deployment: the customer operates the Azent infrastructure in their own Azure subscription and controls the connected AI provider credentials.
Access controls
- Dedicated bot identity: Azent acts through a bot user in Azure DevOps. Its permissions should be scoped to the projects and repositories where it is allowed to work.
- Authorized users only: workspace configuration can limit who is allowed to trigger agent runs.
- Least practical access: teams should grant the bot only the project, repository, build, work item, and wiki permissions needed for their workflows.
- Customer revocation: customers can disable project integration, remove bot permissions, rotate credentials, or uninstall the Azure DevOps extension.
Storage and retention
- Repository content: source code is processed for the active task and written back to Azure DevOps only when the requested work requires a change.
- Run records: Azent keeps run status and operational logs so users can see progress, troubleshoot failures, and audit what happened.
- Secrets and credentials: credentials are stored according to the selected deployment and secret provider model. They are not shown in the product UI after entry.
- Billing and account data: subscription, account, and support records are retained as needed to provide the service and meet legal obligations.
Business parties involved
Depending on deployment and configuration, Azent may involve the following business parties:
| Party | Role | Data involved |
|---|---|---|
| Azent | Service operator | Workspace configuration, run metadata, support data, and task context needed to provide the service |
| Microsoft Azure and Azure DevOps | Hosting, identity, DevOps system, and optional AI platform | Application hosting data, Azure DevOps project data, and AI processing data when Azure AI Foundry is selected |
| OpenAI or Anthropic | AI processing provider, when selected | Prompts, relevant code snippets, work item content, pull request context, and generated responses for the requested task |
| Polar.sh | Payments and subscriptions | Billing and subscription data |
| PostHog | Product analytics, when enabled | Website and product usage events |
Customer responsibilities
- Review which Azure DevOps projects and repositories the bot can access.
- Choose the AI connection model that matches your data residency, contractual, and compliance requirements.
- Avoid placing unnecessary secrets or regulated personal data in prompts, work item comments, pull request descriptions, or files sent for agent work.
- Review generated changes before merging, especially for security-sensitive code, infrastructure, permissions, and deployment configuration.
Security questions
For security, privacy, or data-processing questions, reach out via our contact form. We can provide additional detail for procurement, vendor review, or self-hosted deployment planning.