Brewed In The Cloud logo Brewed In The Cloud

Brewed AI Strategy Journal

Strategic cloud insights for technology leaders and architects

Clear positions, real trade-offs, and practical next actions.

AI Agent Governance Is a Platform Architecture Decision

AI Agent Governance Is a Platform Architecture Decision

2026-09-02 • Chris Hailes

AI Agent Governance Is a Platform Architecture Decision

Assumption to Challenge

Many leadership teams assume agent governance can be completed with policy, training, and a security review before launch. That model works only while an agent recommends. Once it can choose tools, use delegated access, and change a business process, governance must shape the execution path itself.

A policy can state that high-impact actions need approval. It cannot prove that every workflow stopped at the right boundary. That is the gap leaders need to close.

Why It Breaks Now

Agentic workflows combine decisions that enterprises previously governed in separate systems: identity, data access, tool use, approval, logging, and incident response. Microsoft now places agent governance across the organizational lifecycle and applies Zero Trust principles to AI agents. OWASP identifies excessive functionality, permissions, and autonomy as a distinct risk. NIST's AI Risk Management Framework treats governance, measurement, and risk management as connected, continuing functions.

The signal is not that organizations need another AI committee. It is that policy intent must survive contact with runtime behaviour.

Strategic Reframe

Thesis: agent governance becomes operational only when autonomy, approval, identity, evidence, and shutdown boundaries are encoded as a shared platform architecture contract.

That contract should answer five questions for every production agent: Who owns its outcome? Which identity and tools can it use? Which actions can proceed autonomously? Where must a human approve? What evidence and stop authority exist when behaviour departs from intent?

These are operating-model decisions because they allocate authority and accountability. They are architecture decisions because the platform must enforce them consistently.

Decision Choices and Trade-offs

Leaders have two viable paths.

Local governance lets each product team define controls around its own agent. It preserves experimentation speed and domain flexibility. It also creates different approval semantics, audit records, and escalation paths for workflows that may touch the same customer or system.

A platform governance contract defines reusable autonomy tiers, identity patterns, approval gates, evidence requirements, and shutdown controls. Domain owners still decide what their workflow needs, but they choose from enforceable patterns. The cost is up-front platform work and fewer local exceptions. The return is comparable evidence and bounded authority across the portfolio.

The tension is not central control versus innovation. It is local speed versus enterprise confidence that the same decision means the same thing at runtime.

Recommended Stance and First Executive Move

Adopt one platform governance contract, then make the domain owner accountable for selecting and defending the autonomy tier. Platform and security teams own the control primitives; business owners retain responsibility for the outcome. Neither side can outsource its decision.

This week, choose one production candidate and require a one-page agent authority record: accountable owner, agent identity, allowed tools, approval points, required audit evidence, and who can stop it. Then test whether the platform can enforce every field. Any field that relies only on team convention is a control gap to fund before scale.

Brewed Insight

If a governance decision cannot change an agent's runtime path, it is guidance, not control.

Sources

  1. Microsoft Learn, "Govern and secure AI agents across the organization": https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization
  2. Microsoft Learn, "Least privilege for AI agents with Microsoft Entra Agent ID": https://learn.microsoft.com/en-us/security/zero-trust/sfi/least-privilege-for-ai-agents
  3. Microsoft Security Blog, "Advance Zero Trust for AI: New tools and guidance to secure AI agents and DevSecOps": https://www.microsoft.com/en-us/security/blog/2026/08/04/advance-zero-trust-for-ai-new-tools-and-guidance-to-secure-ai-agents-and-devsecops/
  4. OWASP GenAI Security Project, "LLM06:2025 Excessive Agency": https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
  5. NIST, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)": https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf