Agent governance · News & analysis
Give AI agents an identity you can review
Microsoft’s August Zero Trust update brings AI and DevSecOps into the same review. How to connect agent identity, code changes and deployment evidence.
Microsoft announced additions to its Zero Trust for AI guidance on August 4, including expanded assessment coverage and a DevSecOps pillar in its workshop. The update links AI adoption with the controls around software development, identity and operations.
These are Microsoft’s tools and guidance, not a new universal certification requirement. For teams deploying coding or operational agents, the announcement is a useful prompt to review how an agent’s identity connects to the changes it can make.
Follow one change from request to production
Our suggested exercise is to trace a single agent-assisted change. Start with the person who requested it, then identify the agent identity, the repository permissions, the review decision and the deployment identity. The chain should be understandable even if different tools handle each step.
A common design temptation is to give the agent the same broad access as an experienced engineer. That makes an early demonstration convenient, but it can make later attribution difficult. Prefer an identity with a defined purpose and permissions that match the workflow, then keep the human requester visible in the record.
Keep approval and execution distinct
An agent may be able to propose a patch and run tests without being allowed to approve its own change. Establish which operations need independent review and where that requirement is enforced. The enforcement should survive a different client or automation path reaching the same repository or deployment service.
Include the agent’s configuration in change review when it can affect the result. New tools, broader credentials and changed instruction sources can alter what the workflow is able to do without changing the application code it edits. Assign an owner for those changes just as you would for a deployment pipeline.
- Give each production agent a named owner and documented purpose.
- Record which identity proposes, approves and deploys a change.
- Test that protected operations cannot bypass their approval requirement.
- Review access when the agent gains tools or its task changes.
Make the record useful to the next engineer
At the end of the exercise, ask a colleague who did not supervise the run to explain what happened. They should be able to find the request, the proposed change, the review, the tests and the deployed result. If they need to reconstruct the story from a chat transcript, improve the links between those records.
The value of this work is operational. A clear identity and change history helps investigate an incident, revoke an integration and answer an audit question. It also lets the team delegate more confidently because the boundaries and the evidence remain visible as the workflow grows.
Put your security work in motion.
Book a meeting