Azure DevOps is a high-impact surface for agents because it can change code, pipelines, and release settings in ways that ship to production. If you let an agent operate on prompt-only instructions, a single prompt injection or mis-scoped token can turn “help me triage” into “change a pipeline to exfiltrate secrets.”
Claw EA runs OpenClaw as the baseline agent runtime and adds a permissioned execution layer: every Azure DevOps write or admin action must be authorized by policy-as-code using a WPC, carried by a CST, and auditable with gateway receipts and a proof bundle.
Step-by-step runbook
Azure DevOps is connectable via official API with enterprise buildout controls. Do not treat it as a “tool the model can call freely.” Treat it as a controlled capability with explicit scopes, approvals, and a bounded blast radius.
-
Define the minimum Azure DevOps duties for the agent, split into read-only and write paths. Start with “read work items and pull requests” and postpone “edit pipelines” until you have approval gates.
-
Provision identity in Microsoft Entra ID for the integration (service principal or delegated flow), and restrict sign-in using Conditional Access where your org policy supports it. Use PIM for any role elevation that a human operator may need during setup or incident response.
-
Build an Azure DevOps access model using Azure DevOps security groups, permissions inheritance, and access levels. Ensure the identity can only see the specific organization and project(s) the agent is supposed to touch.
-
Write a WPC that enumerates allowed Azure DevOps operations, projects, and repositories, and that requires explicit approval for write and admin actions. Pin the policy hash where you need stable behavior across runs.
-
Issue a CST from clawscope for the job, with scope hash and optional policy hash pinning to the WPC. Bind the CST to the job to reduce replay, so a token from one run is not accepted for a different run.
-
Run the agent in OpenClaw with sandboxing and tool policy enabled, and route model traffic through clawproxy. Collect gateway receipts and emit a proof bundle for the run, then store or attach it to your internal ticketing or audit workflow.
Threat model
Azure DevOps failures are rarely “the agent made a bad summary.” The meaningful failures are permission mistakes, tool misuse, and changes that silently widen access or change what gets deployed.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection turns triage into a destructive change | The agent edits pipeline YAML, service connections, or branch policies after reading untrusted text from a work item, PR description, or log. | WPC denies write/admin calls by default; write paths require WPC approval gates and a separate CST scope. Keep OpenClaw tool policy tight so the agent cannot add new tools to “work around” the denial. |
| Overbroad OAuth scopes or project-wide permissions | The integration identity can read or modify unrelated projects, repos, or release pipelines, increasing blast radius for any mistake. | Least-privilege Azure DevOps permissions and access levels, combined with WPC constraints that whitelist org, project, and repo identifiers. In Claw EA, only issue CSTs whose scope hash corresponds to that WPC. |
| Malicious or misconfigured plugin/skill | A tool implementation makes extra calls not described in prompts, or a skill encourages unsafe “temporary” elevation like granting admin to unblock a job. | Permissioned execution over prompt-only: the WPC is enforced regardless of what the model requests. Use OpenClaw sandboxing and tool allow/deny so the runtime cannot execute arbitrary host actions if a plugin is compromised. |
| Token replay across runs | A captured token is reused later to perform the same Azure DevOps operation outside the intended change window. | Marketplace anti-replay binding using job-scoped CST binding. Require short TTL and rotate credentials using your Entra ID and Azure DevOps practices. |
| Unverifiable model behavior during an incident | You cannot prove which model calls and tool decisions led to a pipeline change, so you cannot scope impact quickly. | Route model calls through clawproxy to emit gateway receipts, and package them into a proof bundle. Use the bundle to reconstruct what the agent was asked and what it did, without relying on ad hoc logs. |
Policy-as-code example
The goal is to make “what the agent is allowed to do” machine-checkable, stable, and reviewable. A prompt can be negotiated; a WPC is an enforceable contract served by clawcontrols and referenced by hash.
{
"wpc_version": "v1",
"tool": "azure_devops",
"connection": { "mode": "official_api", "auth": "oauth" },
"allow": {
"orgs": ["contoso"],
"projects": ["PaymentsPlatform"],
"repos": ["payments-api", "payments-infra"],
"operations": [
"work_items.read",
"pull_requests.read",
"pipelines.read",
"repos.read"
]
},
"deny": {
"operations": [
"pipelines.write",
"service_connections.write",
"permissions.admin",
"branch_policies.write"
]
},
"approval_gates": [
{
"when_operation_in": ["pipelines.write", "permissions.admin"],
"require": ["human_approval", "change_ticket_id"]
}
],
"token_requirements": {
"cst": { "scope_hash_required": true, "policy_hash_pinning": "optional" }
},
"logging": { "receipt_required": true, "proof_bundle_required": true }
}
This pattern keeps “read for triage” always-on while forcing “write to production path” through explicit review. In an enterprise buildout, you map the allowed operations to Azure DevOps REST API calls and the minimum OAuth permissions your security team approves.
What proof do you get?
For model calls routed through clawproxy, you get gateway receipts that can be checked later to confirm what was called and under which constraints. Those receipts are not a screenshot of Azure DevOps, but they are a verifiable record of the model call path used by the run.
Claw EA packages receipts plus related metadata into a proof bundle. If you publish it for audit viewing, you can store it as a Trust Pulse artifact so reviewers can fetch the same run evidence without asking the operator for local files.
When you combine the WPC hash, CST scope hash, and the proof bundle, you can answer operational questions quickly: which policy was in force, whether the token was job-bound, and which model calls were made during the run.
Rollback posture
For Azure DevOps, rollback needs to be planned before you grant write access. The safest posture is to require pull-request based changes for anything that affects builds and releases, so a revert is a normal Git operation.
| Action | Safe rollback | Evidence |
|---|---|---|
| Agent edited pipeline YAML in a repo | Revert the commit, then rerun the last known-good pipeline. Prefer branch protections so the agent cannot push directly to main. | Repo commit history plus the proof bundle showing the model call sequence and the WPC that allowed the edit. |
| Agent changed pipeline variables or library values | Restore from a recorded baseline or redeploy configuration from code. If values include secrets, rotate secrets immediately and invalidate the integration credentials. | Azure DevOps audit trail where available, plus CST issuance/revocation records and the run’s proof bundle. |
| Agent modified permissions or added a broad group | Remove the permission grant, review group membership, and require PIM for any future elevation. Re-run access reviews for the affected project. | WPC deny or approval records (if a gate was bypassed, that is the incident), and receipts indicating what the agent attempted. |
| Agent triggered an unintended deployment | Stop the release, roll forward with a corrective release, or roll back using your environment’s standard procedure. Treat this as a release management incident, not an “agent glitch.” | Release logs and pipeline run IDs correlated to the agent job metadata and proof bundle timestamp window. |
FAQ
Is Azure DevOps support a native Claw EA connector today?
No. Azure DevOps can be connected via official API with enterprise buildout controls, and you should expect a scoped, reviewed integration rather than a one-click connector.
Why is policy-as-code required instead of just careful prompting?
Prompts do not constrain execution; they only influence behavior. A WPC is enforced even when the model is coerced, confused, or reading untrusted content from a work item or pull request.
What Azure DevOps permissions should an agent start with?
Start with read-only access to a single project and a small set of repos. Add write permissions only after you have WPC approval gates and a rollback plan that your release owner accepts.
How do CSTs relate to Entra ID tokens?
Entra ID handles authentication to Microsoft services; a CST is used to authenticate and scope the agent job within Claw Bureau services. You use the CST scope hash and optional policy hash pinning to bind the run to the approved WPC.
What do gateway receipts prove in practice?
They prove which model calls were made through clawproxy and provide signed evidence for later verification. They do not replace Azure DevOps audit logs, but they close a common gap when agent behavior is otherwise only “logged” in text.