Agents4DevOps runs inside your Azure DevOps organization and acts only within the permissions, scope and approval policy your team configured. Automation never widens access. Side-effectful steps wait for a named approver, results are verified after the action, and every run leaves a record you can open and inspect.
Runs inside your Azure DevOps, with no separate portal and no new login. · Existing Azure DevOps permissions and project scope enforced on every run. · Your project data is not used to train models. · Every run recorded: trigger, inputs, actions, approvals, outputs, errors.
These are product behaviors, not policy statements. Each one shows up in configuration, at a checkpoint, or in the job log.
Agents operate against your projects, repositories, pipelines and test plans directly, on the same security and trust model as Copilot4DevOps. There is no external copy of your requirements to secure.
Agents act within the Azure DevOps permissions, product roles, project scope and tool permissions already in place. If someone cannot reach an item today, an agent does not change that.
Actions with defined side effects pause for the reviewer you named before they execute. A rejected draft writes nothing to the project.
Post-action checks confirm the expected state, link, result or rerun exists. A run is not reported as successful until the result is verified.
Each execution creates a job with timestamped logs of the trigger, context, actions, approvals, outputs and errors. The work item history notes when an AI agent made a change.
Every change to an agent definition is versioned from the first save, with a readable summary and one-click restore to a known-good version. Agent behavior sits under change control.
Choose the model per agent and see its credit rate at selection. Enterprise plans bring their own LLM and key, so you control the model, region and data path directly.
Every run starts from a trigger a person on your team set: a manual request, an Azure DevOps event, or a schedule. An agent cannot add its own triggers, and a disabled agent does not run.
Agents read and write your Azure DevOps project as the system of record. Work items, links and traceability are not exported to a separate database to be drafted against, so there is no sync job, no drift between tools, and no new system for your auditor to review. Each workflow retrieves only the context configured for it, scoped to an organization, project, team, repository, area path, iteration or work item type, and sends data only to the services required to complete that run. Processing location, model endpoint and retention depend on the deployment and model configuration you choose, and the exact path is documented for your review.
A misbehaving agent is limited to one run's worth of work. When a run reaches a guardrail it is stopped, and it cannot keep consuming steps or credits.
Each run has a ceiling on the orchestration steps it can take. An agent cannot loop indefinitely while it decides what to do next.
A failed step can be retried, but only up to a set limit. Repeated failure ends the run and lands in the job log with its reason.
A run may delegate to sub-agents for multi-agent work, within a cap on how many it can spawn. Each handoff is explicit and recorded.
Execution Agents run deterministic code within a maximum execution time. A rule that hangs is stopped rather than left running.
Execution Agents also have a ceiling on the Azure DevOps API calls a single run can make, so one rule cannot flood your organization.
When credits reach zero, agents pause and no new runs start. Nothing is billed beyond your plan unless you enable auto top-up, which has a monthly cap you set.
Each execution creates a job in the Job Explorer. Its logs are timestamped and describe each stage of the run in plain language, so a reviewer can see what happened, when, and why, and compare runs across agent versions and settings. The agent's response can be saved as PDF, Word or Markdown for a review file. We do not promise a verbatim internal chain of thought: what matters for trust is the auditable trail of access, action, approval and result.
Run record fields
Audit feed · illustrative
Evidence pack assembled for release 2.4
14:06:06 · Compliance Officer Agent
Release notes drafted, waiting on sign-off
14:05:19 · Product Owner Agent
Nightly branch-policy audit completed clean
14:04:32 · Compliance Officer Agent
Draft rejected · nothing written to the project
14:03:45 · Product Owner Agent
Pipeline fix proposed, awaiting approval
14:02:58 · DevOps Engineer Agent
Drafted acceptance criteria on STORY 4821
14:02:11 · Business Analyst Agent
Never trained on your data
Checkpoints are set by policy, per workflow. The product supports three modes of human-in-the-loop automation, so a low-risk rule and a release decision do not get the same treatment.
The agent analyzes and recommends, citing the evidence it used. A person reads the recommendation and decides what happens next. Nothing is written back by the agent. Use it for investigations, impact analysis and go/no-go summaries.
The agent prepares the change, then pauses. With Required Approval on, it creates an Open Task with what it needs, and waits. The approver answers, edits or rejects, can attach up to 10 supporting files of 20 MB each, and the run resumes only after Proceed. If an agent's instructions ask for confirmation and Required Approval is off, the agent cannot be saved.
For controls you can specify exactly, an Execution Agent applies a fixed, versioned rule your team wrote and can read, with no model call at run time. It runs on the events or schedule you set, stays inside its guardrails, and every run is still verified and recorded.
Agents4DevOps permissions follow Allow and Deny per team or security group, set at project level with organization inheritance. Separation of duties is enforced, not assumed.
| Permission | What it controls | How it is set |
|---|---|---|
| Manage Agents | Create, configure, enable and edit agents: instructions, scope, triggers, tools and approval settings. | Allow or Deny per team or security group, project level, inherited from the organization. |
| Delete Agents | Remove agent definitions from the project, kept separate from the right to edit them. | Allow or Deny per team or security group, project level, inherited from the organization. |
| Job Explorer | Open jobs and their run details: logs, agent responses, tasks and outcomes for every run. | Allow or Deny per team or security group, project level, inherited from the organization. |
| Manage Skills | Create and change the reusable skills that agents are composed from. | Allow or Deny per team or security group, project level, inherited from the organization. |
Every output from an Assisted Autonomous Agent is an AI draft that requires review. Agents prepare, check, trace and assemble review-ready artifacts. Safety, compliance, certification, architecture and go/no-go decisions stay with the qualified engineers who sign them. For regulated teams this is the posture auditors expect: the agent produces the draft and the traceability, and a named person makes and signs the determination.
[ Trusted by Microsoft and industry leaders ]
Agents run inside your Azure DevOps environment, on the same security and trust model as Copilot4DevOps, with no separate login and no export to a third-party system of record. A run sends context only to the services needed to complete it, such as the model endpoint you configured. The exact data flow for your deployment is in the security package.
No. Your project data is not used to train models. Enterprise plans can bring their own LLM and key for full control of the model, region and data path.
No. Agents act within the existing Azure DevOps permissions, product roles, project scope and tool permissions. Tool calls are enabled or disabled per agent, and automation never widens access.
Execution Agents apply a fixed rule your team wrote, with no model call at the moment of execution. Assisted Autonomous Agents draft or analyze, and with Required Approval on they pause and create an Open Task for a named person before continuing.
Run guardrails on every plan: a maximum number of steps, a maximum number of retries and a limit on sub-agents per run, plus execution-time and API-call limits for Execution Agents. A run that hits a guardrail is stopped, and agents pause when credits reach zero.
Certification, attestation and compliance specifics, including SOC 2 and ISO 27001 status, are confirmed by our security and legal teams on request. Ask for the security package and we will map your required controls to the actual architecture.
Encryption in transit and at rest, including protocols and key ownership, is documented in the security package and confirmed on request. NEEDS · security-team-approved encryption statement
Open the job in the Job Explorer. Run details show timestamped logs of the trigger, context, tool calls, approvals, outputs, errors and verification. The work item history also notes when an AI agent made a change.
Request the security package, or book a security review with your highest-risk workflow. We will walk your team through the data flow, identity model, permission boundary, approval controls, verification and retention for your deployment.
Business Analyst Agent
