For Azure DevOps
When AI agents write code faster than a team can review it, review has to scale with them. Polier is meant to turn that into reviewed pull requests – in an instance of your own, in Germany.
Sign-up not open yet
#4799 Reject expired session tokens
Acceptance criteria
✓ expired token → 401 · ✓ test covers expiry · ✓ no API change
tag: polierBoardsclaimed
1. src/Auth/SessionService.cs · guard expiry
2. tests/Auth/SessionServiceTests.cs · add case
3. docs/auth.md · note
auth change → waiting for /approve
worktree agent/4799-session-ttl
$ egress
blocked by default
@ -42,2 +42,3 @ public Session? Create(Token token)− return Issue(token.UserId);+ if (token.ExpiresAt <= clock.UtcNow) return null;+ return Issue(token.UserId);
$ dotnet test
Passed SessionServiceTests.ExpiredTokenIsRejected
Passed SessionServiceTests.ValidTokenIssuesSession
214 passed · 0 failed · exit 0
reviewer-agent non-blocking
Reject expired tokens before issuing a session.
@ -42,2 +42,3 @ public Session? Create(Token token)− return Issue(token.UserId);+ if (token.ExpiresAt <= clock.UtcNow) return null;+ return Issue(token.UserId);
Draft PR !812 → main
Build · 214 tests passed
reviewer-agent · required ✓
Branch policy · 1 human approval
Polier is being built to turn work items in Azure Boards into tested, reviewed pull requests in Azure Repos. Intended: you sign up yourself, and an instance of its own is created automatically for your company in our Azure in Germany. Models and tokens are included in the subscription, and your own branch policies apply.
In development, not available yet
0merge and deploy rights for agent identities (by design)
3 · 2 · 2rounds before a person takes over: tests, review, pipeline (defaults)
Intended: an instance of its own per customer in our Azure in Germany · Azure DevOps Services. "In development" means: the code exists and is tested against test doubles, but not yet against a real Azure DevOps organization.
An agent should never merge by itself.
An agent needs access to code and work items. For Azure DevOps teams with strict requirements the conversation can end there: at the security department, at data protection or at the works council.
An agent works with code copies and transcripts. That means contract review and the question of where the data lives and who shares the environment with it. Our answer is meant to be simple: an instance of its own per customer, in Germany.
As of 24 October 2026 Microsoft's AI services for Azure DevOps, such as Copilot code review, were only available for Azure DevOps Services. Polier does not support Azure DevOps Server yet; it is planned.
An agent that pushes and merges on its own is hard to justify. You need hard limits, not just good prompts.
Every step leaves traces in Azure DevOps. The agent itself never merges; you decide where a person decides.
In development: this is how Polier is being built. As of 01/11/2026: none of it runs for a customer.
Describe a project in your own words, as text or by voice (the console's dictation uses your browser's speech recognition). The planner asks at most one round of questions and turns it into epics, features and work items with a done criterion, dependencies, order, size and risk class; you approve the plan as a whole. For a bug or a single task, tag a work item in Azure Boards with "polier" instead. A task only starts for people who have write access to the target repository and are enabled for the project.
Polier reads the code and writes a plan as a comment on the work item. For risky changes – for example infrastructure, pipelines, authentication or agent rule files – Polier waits for a "/approve" from a person configured for it. From risk tier 2 on, that cannot be the person who requested the task; the approval only counts for exactly this plan.
A coding agent works in its own Git worktree, in one sandbox per task. Network traffic is blocked except for the path to the model proxy. The sandbox is the boundary, not the tool list. In our own operation that is a Linux sandbox (bubblewrap); for customers, Azure Container Apps Sandboxes per task are planned. Until they exist an instance runs no customer code.
Build and tests run before every push. The exit code counts, not the agent's own assessment. Red results go back to the agent, three times at most.
A separate reviewer (its own, read-only session) checks the diff and sets the status "polier/review" on the pull request. As a required status in your branch policies, Azure DevOps resets it on new changes. The status can block a merge, never approve one on its own.
The dispatcher opens a draft PR on an agent/* branch, linked to the work item. Exactly the state the reviewer checked is pushed. Your pipelines and branch policies decide. By default a person merges; further automation (auto-merge, staging, production) is meant to be configurable per repository and environment – that is planned and not built yet.
After fixed round limits Polier hands over to a person with a summary instead of trying forever.
As of 01/11/2026: the flow is built and tested against test doubles. A real run against Azure DevOps and a real model has not happened yet; that is why there are no figures here.
Context
Before every plan the planner reads the repository and the board, not just the diff – and only what you let it read.
In development: this is how Polier is being built. As of 01/11/2026: none of it runs for a customer.
Rule files such as AGENTS.md and the README from the protected state of your target branch – merged by people, never from the agent branch – enter the task as marked, untrusted input.
Title, description, acceptance criteria and up to 50 latest comments, read fresh over REST. The hook payload alone does not count as evidence.
Open work items with the tag "polier", so a new plan does not plan twice what is already on the board.
Your text, your answers to the questions and, if you want, a product plan file. After every merged pull request the plan can be re-assessed.
Planned: foreign text – work item text, PR comments, rule files from customer repositories – passes through Azure AI Content Safety (Prompt Shields) first.
What runs have shown, Polier proposes as a draft pull request against your repository's rule file, with evidence, written by fixed code. A person reviews and merges; it does not learn on its own without review.
Instance
Planned: at sign-up an instance just for you is created automatically, with no person in between. Your code then runs at ours, so we are a data processor. No instance runs today.
In development: this is how Polier is being built. As of 01/11/2026: none of it runs for a customer.
Illustration with sample data, not the result of a real run.
Its own database, storage, Key Vault, Service Bus and Container Apps environment, in the Azure region Germany West Central.
A Microsoft work account, your company, an instance address: that is all it is meant to take. The instance is created automatically, with a trial and a small AI quota.
A guided page in the instance: a Microsoft Entra admin consents once, an Azure DevOps Project Collection Administrator signs in once, everything else is automatic. Service principals, no personal access tokens. Azure DevOps Services only for now.
All customers run on our models from Azure. Tokens are included as a quota per package, and you can raise it. Nobody brings a key or a model.
Your code runs only in a sandbox per task (Azure Container Apps Sandboxes, planned), never on a development server. As long as that sandbox does not exist, an instance runs no customer code.
Branch policies, pipelines and approvals stay those of Azure DevOps. Polier gets no rights to bypass them.
Guardrails
What an agent must not do is prevented by rights, policies and network – not by a sentence in a prompt.
In development: this is how Polier is being built. As of 01/11/2026: none of it runs for a customer.
Illustration with sample data, not the result of a real run.
Agent identities get no write access to your main branches and no "Bypass policies"; the action rules also refuse pushes and merges from inside a run. By default a person merges. More automation can be set later per repository (planned).
The agent process holds no credentials: the dispatcher pushes from a fresh clone outside the sandbox (only the reviewed state, only to agent/*), the preparation step fetches packages before the start, and a proxy outside the sandbox sets the Authorization header for model calls.
Reading and local changes run automatically. Network, spending, deleting and production need approval, as do writes to protected paths such as pipelines, infra/ and agent rule files. Files in the repository can only tighten the rules.
Notices at 50, 75 and 90 percent. At 100 percent nothing new starts; open tasks are parked and continue later. You set the limits.
A switch stops the dispatcher: running sessions are interrupted, no new tasks are accepted until a person resumes. The switch is built; it is triggered in the console or through a pause endpoint, for example by a cost alert in Azure. The command from a phone follows.
Every stop of the guardrails and every approval is recorded in an append-only trail. Planned: one immutable audit record per run in your instance's storage (trigger, identities, model and data path, tests, review, approvals, cost), transcripts kept apart and deleted after a period. The storage's immutability is not set up yet.
More than pull requests
Reviewer, watchdog and night shift are built and tested against test doubles – not yet against real alerts, a real model and a real organization. As of 01/11/2026.
Illustration with sample data, not the result of a real run.
A required status instead of mere comments, an answer to follow-up questions ("@polier" in the pull request) and review with read rights only. Part of every run today; planned as a separate, easy entry point for your team's own pull requests.
An Azure Monitor alert or a red run on a main line starts an investigator with read-only rights. You get a diagnosis on your phone; a fix is only made when an authorised person clicks "Builder should fix".
Routines run at night by playbooks that you define – all are off at first – within a night budget: for example package updates as ordinary tasks with review and pull request. At 7:00 (Berlin time) a report is ready, built from the books without a model call.
Azure DevOps Server is planned, not before 2027; for now we only support Azure DevOps Services.
For works council and data protection, a product principle of Polier: no productivity metrics for individuals, no rankings, no sentiment analysis.
Polier is in development and not in use anywhere yet. We want to use it in our own products first and publish dated figures with method here: agent PRs, the share merged without a manual code change, and the cost per task – plus an uncut video of a run, including a failed one.
No published figures yet. As of: 01/11/2026
No customers yet, so no logos. A logo appears here only when a customer allows it. More on the method
No. Polier is meant to take clearly described tasks and deliver pull requests. Approving the plan, the review decision and the merge stay with your team.
All customers run on our models from Azure: models that Azure sells itself (Azure OpenAI and other vendors' models hosted by Azure). Which one becomes the default is being measured and not decided. Tokens are included in the subscription as a quota per package, and you can raise it. Nobody brings a key or a model. Only in the Enterprise package can access of your own be unlocked later, for a higher platform fee; that is not built.
Planned: you sign up with your Microsoft work account, name your company and an instance address, and the instance is created automatically. Then a page in the instance guides you through connecting Azure DevOps: a Microsoft Entra admin consents once, a Project Collection Administrator signs in once, everything else is automatic. You need no personal access tokens for it.
No. Polier works with Azure Boards, Azure Repos and Azure Pipelines.
After fixed limits – by default three test rounds, two review rounds, two pipeline rounds – Polier hands over to a person with a summary. On a rate limit or a reached budget the task is parked and continues later at the same place.
Not for Polier itself: the instance runs in our Azure, and it does not matter how you otherwise buy Azure. You need an Azure DevOps organization connected to Microsoft Entra ID. Each agent identity takes a Basic access level there; the first five Basic seats are free per Microsoft, above that Microsoft bills you directly.
There is no price list yet. The pricing page shows provisional amounts per package. Tokens are included as a quota; its size is still open.
No. Polier is in development, so far only tested against test doubles and not deployed anywhere. That is why there are no customer logos or figures here.
Intended is an instance of its own for you in the Azure region Germany West Central, with its own database and storage. Model calls run on Azure, and the exact region per model comes with the catalog. The data stays with Microsoft; the model vendors do not see it. Because your code runs at ours, we are a data processor; you conclude the agreement for that at sign-up.