Who should be accountable for access reviews on Azure AI Foundry agents?

Why This Matters for Security Teams

Accountability for Azure AI Foundry agent access reviews is not a naming exercise. The review owner must be the team that can answer three questions at audit time: why the agent exists, what it can reach, and whether that access still matches current use. That usually means shared ownership across the agent product team, the identity or platform team, and the Azure resource owner, with one named approver responsible for closure.

This matters because agent access is not static. Agents may call tools, chain prompts, reach into data stores, and inherit permissions through managed identities or service principals. If reviews are treated like ordinary user recertification, excess access tends to persist unnoticed. NHIMG has documented how AI-driven tooling and identity mistakes can cascade quickly, including in CoPhish OAuth Token Theft via Copilot Studio and the OWASP Agentic Applications Top 10. Current guidance suggests assigning review ownership to the people who can actually remove risk, not merely to the people who can click approve. In practice, many security teams discover stale agent access only after a tool chain has already been abused.

How It Works in Practice

The cleanest model is to fold Azure AI Foundry agents into the same identity governance workflow used for users, service principals, and managed identities, but with a different reviewer lens. The reviewer should validate whether the agent still has a legitimate business purpose, whether each role assignment is still needed, and whether any attached tools or data connections can be removed or narrowed. That aligns with the least-privilege intent of the NIST AI Risk Management Framework and the access governance principles behind OWASP Non-Human Identity Top 10.

Operationally, the accountable owner is often the application or product owner, while the technical evidence comes from the platform team. That split works best when the following are reviewed together:

• The agent’s managed identity or service principal and its role assignments
• Any Key Vault, storage, database, or API permissions the agent can reach
• Whether the agent is still in production, pilot, or retired status
• Whether the agent’s access should be time-bound, scoped, or replaced with JIT approval

For teams adopting stronger runtime controls, current best practice is evolving toward explicit workload identity, policy-as-code, and contextual access checks rather than broad standing access. That approach is consistent with CSA MAESTRO agentic AI threat modeling framework and the OWASP Agentic AI Top 10. These controls tend to break down when the agent spans multiple subscriptions and a single team cannot see the full set of downstream data and tool dependencies.

Common Variations and Edge Cases

Tighter review accountability often increases coordination overhead, requiring organisations to balance faster approvals against stronger evidence. That tradeoff becomes sharper when agents are embedded in shared platform services, operated by one team but consuming data from several business units, or copied across environments without clear ownership lineage.

There is no universal standard for this yet, but current guidance suggests the accountable reviewer should be the person or team that can revoke the access without depending on another group to interpret intent. In a central platform model, that may be a platform owner with delegated business approval. In a federated model, it may be the product owner plus the Azure subscription owner. The important point is that accountability must map to revocation authority, not just org chart proximity.

Edge cases also arise when agent access is mediated through automation. If an agent’s permissions are created and removed by pipeline code, then the review should include the pipeline owner and the policy guardrails that govern deployment. This is especially important when agents can be cloned or reconfigured quickly, because the review record can go stale faster than the identity itself. In those cases, pair human attestation with automated checks against current role assignments and resource links, using the MITRE ATLAS adversarial AI threat matrix for abuse-path thinking and NHIMG’s analysis of Ultimate Guide to NHIs — 2025 Outlook and Predictions for broader identity governance context.

Related resources from NHI Mgmt Group

• Who should be accountable for user access reviews in a regulated environment?
• Why do AI agents increase compliance and breach investigation risk when access is not fully tracked?
• Who is accountable when SSO access reviews and audit logs are not maintained?
• Who is accountable when an approved AI application keeps access after the original business need has changed?