Security & data
What Polier is meant to do, what exists in the code today and what does not. We only write down what we can stand behind, and we date it.
As of 01/11/2026. None of this is in use at a customer.
What applies today – and what does not
- Polier is in development and deployed nowhere. There has been no real run against Azure DevOps and a real model yet.
- The building blocks are built and tested against test doubles. Whether they hold under real conditions only the first runs will show.
- We hold no certification (such as ISO 27001 or SOC 2) and have no external penetration test.
- The threat model and the red-team cases are planned but not published yet.
- The data protection and contract documents for customers, including the data processing agreement, are drafts and have not been reviewed by a lawyer yet.
- Sign-up, automatic instances and the sandboxes per task are not in operation yet. As long as the sandbox is not built, an instance runs no customer code.
Where Polier is meant to run
Intended is an instance of its own per customer in our Azure, in Germany (Azure region Germany West Central): its own database, storage, Key Vault, Service Bus and Container Apps environment. There is no shared database for all customers. The instance is created automatically at sign-up.
Your code therefore runs at ours, not at yours. It runs only in a sandbox per task (Azure Container Apps Sandboxes, planned) and never on our development server. Until that route is built, an instance runs no customer code. Our own operation runs separately from it.
What is meant to leave your instance
- Model calls to the models from Azure (data path below) and, planned, Prompt Shields checks to Azure AI Content Safety.
- Package restores only in the preparation step, before the agent starts, and only reading from allowed feeds.
- Reads and writes to your Azure DevOps organization: work items, repositories and pull requests, with the agents' service principals.
- Container images come from our registry, signed and pinned by digest (planned).
Model access and data path
As of 01/11/2026, per Microsoft's documentation; please check the details yourself before deciding.
| Route | Data path | Billing |
|---|---|---|
| Models that Azure sells itself (Azure OpenAI and other vendors' models hosted by Azure), for all customers | The data stays with Microsoft: Microsoft runs the models in Azure, and the model vendors do not see prompts and responses. Your instance's stored data is meant to stay in Germany; model calls run on Azure, and the exact region per model comes with the catalog. | Included in the subscription, as a quota per package; you can raise it. |
| Access of your own in the Enterprise package (planned, not built yet) | Will be settled when this route is built. | A higher platform fee; Enterprise package only. |
- We do not promise that model calls are processed in Germany or the EU: depending on the deployment type, Azure can process prompts and responses outside a geography as well.
- Which model becomes the default is not decided. We measure the models with the same cases and set it afterwards.
- Microsoft monitors the services for abuse: samples of prompts and responses can be reviewed automatically and, where necessary, by authorised Microsoft employees. Models in preview can follow different rules.
Source: Microsoft's page "Data, privacy, and security for Models sold by Azure", read on 1 November 2026: learn.microsoft.com
Identities and rights
Every role has an identity of its own: service principals in your organization, no personal access tokens. There is no identity with deploy rights. Each identity takes a Basic access level in Azure DevOps; the first five Basic seats are free per Microsoft, above that Microsoft bills you directly.
| Identity | May | May not |
|---|---|---|
| Intake | Read and write work items, comment, hold leases. | Write code. |
| Build | Push to "agent/*" and create pull requests – only through the dispatcher. | Write to main lines, bypass policies, complete pull requests. |
| Review | Read code, "Contribute to pull requests", set the required status. | Approve a merge on its own. |
| Investigation (in development) | Read in approved projects and resource groups. | Write. |
| Deploy | No agent identity. Deploys stay in your pipelines with your environment approvals. | – |
Guardrails
"Built" means: code and tests are on our main line, tested against test doubles, but not yet in a real run. "Planned" means: not built.
- built
Rights of the agent identities
No merge, no deploy, no pushes outside "agent/*". You set the branch rights in Azure DevOps; the action rules additionally refuse pushes and merges from inside a run.
- built
Action classes
Read, local write, network, spend, delete, production. Only reading and local changes run automatically; network, spend, delete and production need approval. Repository files can only tighten.
- built
Sandbox
Every process in a worktree runs in a sandbox with a writable worktree, a read-only clone and package cache, an empty home and network only to the model proxy. Build and tests run arbitrary code; that is why the sandbox is the boundary, not the tool list. Today that is the Linux sandbox of our own operation; for customers, Azure Container Apps Sandboxes are planned.
- built
No credentials in the agent
A token proxy outside the sandbox sets the Authorization header for model calls; a token broker hands Azure DevOps tokens only to the Linux user that owns the role.
- built
Push gate
Only the state the reviewer checked (tree hash) is pushed, after a green build and green tests, to an agent branch, without protected paths and without tier-2 changes the plan did not approve.
- built
Budget and kill switch
Limits per run, night and month with notices at 50, 75 and 90 percent and a hard stop. A switch stops the dispatcher; it is triggered in the console or through a pause endpoint. The command from a phone follows.
- planned
Prompt Shields
Foreign text (work item text, PR comments, rule files from customer repositories) is meant to pass through Azure AI Content Safety before it reaches the model.
- planned
Immutable audit, signed images
One immutable audit record per run in your instance's storage, signed container images with pinned digests, an SBOM. Today there is an append-only trail for stops and approvals; the storage's immutability is not set up yet.
AI labelling
Every comment from Polier carries the line "Polier (AI agent), on behalf of <requester>". Commits carry the trailer "Agent: Polier" and pull requests the label "ai-generated". Polier does not measure the productivity of individuals and creates no rankings.
Data protection: we are a data processor
Your code is meant to run at ours. So for the content of your instance we are a data processor, and you are the controller. You conclude the data processing agreement at sign-up. Microsoft is intended as a sub-processor. The legal texts are drafts and have not been reviewed by a lawyer yet. For contact details from emails to us we are the controller; see the privacy notice.
Security reports
If you notice something, please write to us. There is no dedicated security address yet: info@ballmüllersolutions.de