# Microsoft Foundry operations governance

## What people get wrong

- They treat a Foundry project as the whole security boundary. It is only a development boundary; connected services still need their own RBAC, networking, logging, and lifecycle controls.
- They assign broad Azure roles because Foundry-specific roles feel new. That expands blast radius across model deployment, project management, and access assignment.
- They discuss model rollout without proving regional feature support, deployment type, and quota. Documentation is not capacity evidence.
- They enable tool or agent workflows before deciding which identity is allowed to read, write, delete, or assign access.
- They design private access to Foundry but forget Storage, Key Vault, AI Search, registry, logging sinks, and outbound dependencies.

## Officially grounded service shape

Microsoft Learn describes a layered Foundry model: a top-level Foundry resource for governance, networking, security, monitoring, and deployments; projects for team development isolation; and connected Azure resources such as Storage, Key Vault, and AI Search under separate governance boundaries. RBAC is scope-sensitive and uses Foundry-specific built-in roles. Some role names were renamed, so automation should prefer stable role definition IDs where possible.

## Non-negotiable design rules

1. Identify whether each operation is resource-scoped, project-scoped, or connected-resource-scoped.
2. Use least-privilege Foundry roles first; justify any Owner, Contributor, or custom role action.
3. Prefer Microsoft Entra ID and managed identity. Treat keys as full-access secrets unless proven otherwise.
4. Verify regional availability and quota for the exact deployment type before approving rollout.
5. Verify network isolation for Foundry and every connected dependency.
6. Require diagnostic settings or equivalent monitoring for operations, model usage, errors, and access changes.
7. Put mutation approval behind blast-radius, rollback, and evidence review.

## Minimal safe implementation flow

1. Inventory intended teams, projects, model deployments, agent/tool usage, and connected resources.
2. Map every persona and managed identity to the smallest Foundry and connected-resource scope.
3. Validate target regions, features, deployment types, and quotas against Microsoft Learn and sampled configured-environment evidence if available.
4. Validate private access and outbound paths for Foundry plus Storage, Key Vault, AI Search, registry, and monitoring sinks.
5. Confirm diagnostics, retention, alerting, and access-review ownership.
6. Run a preproduction rollout with the same role, network, and quota shape as production.
7. Approve production only with a rollback plan for access, networking, deployments, and tool registration changes.

## High-risk assumptions to kill

- A project boundary is not enough for production isolation unless connected resources, model deployments, networking, diagnostics, and RBAC are separately verified.
- A documented Foundry capability is not proof that the target region, deployment type, quota, or project scope can support the workload.
- Managed identity only reduces key exposure if each identity has narrowly scoped permissions on Foundry and every connected resource.
- Private access to the Foundry resource does not automatically make Storage, Key Vault, AI Search, registry, monitoring, or agent outbound paths private.
- Content safety or guardrail configuration is not production readiness unless intervention points, model deployment scope, logging, and operational ownership are defined.

## Safe command/code verification targets

- Inspect infrastructure definitions for `Microsoft.CognitiveServices/accounts`, `Microsoft.CognitiveServices/accounts/projects`, deployments, private endpoint, diagnostic setting, and role-assignment resources.
- Verify automation distinguishes resource-scope and project-scope operations before creating deployments, projects, agents, evaluations, or connections.
- Check policy-as-code or templates for private DNS, Key Vault, Storage, AI Search, and log destination wiring rather than only the Foundry resource.
- Review scripts for secret material, key-based auth, broad `Owner` or `Contributor` grants, and unguarded delete/update actions.
- Confirm generated evidence labels separate Microsoft Learn documentation from sampled configured-environment evidence.

## Safe verification targets

- Role assignments at Foundry resource and project scopes.
- Managed identity assignments on project and connected resources.
- Model deployment type, region, capacity, and quota.
- Public network access, private endpoint, DNS, and outbound dependency paths.
- Diagnostic settings and log destinations.
- Guardrail and tool-registration configuration where applicable.

## When to push back

Push back on production approval from diagrams only, broad role grants, project-only isolation claims, region-agnostic quota claims, key-based automation, or tool operations without an approval and rollback boundary.

# MCP and evidence path for Microsoft Foundry operations governance

Use Microsoft Learn documentation through the user's configured documentation MCP as the first grounding path for Azure service behavior. This file defines evidence boundaries; it must not imply that documentation proves the user's tenant, subscription, RBAC, quotas, deployed resources, or production readiness.

## Evidence ladder

1. `docs_only`: Microsoft Learn documentation and official architecture guidance. Use for documented behavior, caveats, and safe review criteria.
2. `sampled_read_only`: configured-environment evidence from read-only tools, if available and explicitly scoped. Use only for the sampled resource/time window.
3. `user_supplied`: sanitized outputs, IaC, diagrams, or metrics provided by the user. Treat as unverified unless independently checked.
4. `mutation_ready`: documentation plus current-state evidence plus explicit approval, blast-radius statement, and rollback path.

## Rules

- Do not expose environment-specific implementation details in committed docs or user-facing guidance.
- Do not ask for credentials, tokens, tenant identifiers, subscription identifiers, connection strings, private keys, customer data, or raw secrets.
- If current-state evidence was not sampled, say `not sampled`; do not imply it.
- If evidence is representative or partial, say so. A sample does not prove broad regional availability or production readiness.
- Prefer read-only evidence before mutation planning. Stop for approval before write operations.

## Final-answer evidence language

Use phrases like:

- "Based on Microsoft Learn documentation..."
- "Configured-environment evidence was not sampled in this review."
- "The following is an inference from the provided configuration, not proven live state."
- "This recommendation is mutation-ready only after explicit approval and rollback review."

# Official sources for Azure AI Foundry Ops Governor

Use this file to ground reviews in Microsoft Learn documentation through the user's configured documentation MCP. Documentation evidence proves Microsoft-published behavior; it does not prove the user's tenant, RBAC, quotas, network routes, deployed resources, or production readiness.

## Primary Microsoft Learn sources

| Source | Review implication |
| --- | --- |
| [Microsoft Foundry architecture](https://learn.microsoft.com/en-us/azure/foundry/concepts/architecture) | Treat the Foundry resource as the governance/security/network/deployment boundary and projects as team development boundaries. Verify connected resources separately. |
| [Role-based access control for Microsoft Foundry](https://learn.microsoft.com/en-us/azure/foundry/concepts/rbac-foundry) | Validate scope and role fit. Do not recommend broad Owner/Contributor when Foundry-specific roles or split data/control-plane roles are enough. |
| [Azure AI security best practices](https://learn.microsoft.com/en-us/azure/security/fundamentals/ai-security-best-practices) | Ground network isolation, least privilege, model governance, secure compute, and monitoring recommendations. |
| [Configure secure networking for Azure AI platform services](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai/platform/networking) | Use for private endpoint and supporting-service network-boundary checks. |
| [Foundry Model Context Protocol security best practices](https://learn.microsoft.com/en-us/azure/foundry/mcp/security-best-practices) | Use only for Foundry product MCP behavior, identity, RBAC categories, and Conditional Access review. Do not confuse product documentation with evidence about this user's runtime. |
| [Feature availability across cloud regions](https://learn.microsoft.com/en-us/azure/foundry/reference/region-support) | Confirm model, agent, evaluation, and feature regional support before endorsing a rollout. |
| [Azure OpenAI quotas and limits](https://learn.microsoft.com/en-us/azure/foundry/openai/quotas-limits) | Treat quota as regional and deployment-dependent; require configured-environment evidence before claiming capacity. |
| [Agent Service limits, quotas, and regions](https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/limits-quotas-regions) | Use for agent-specific limit checks; do not extrapolate from model quota alone. |

## Source-grounding rules

- Documentation claim: cite the relevant Microsoft Learn source and state it as documented behavior.
- Current environment claim: require sampled read-only Azure evidence or user-provided sanitized output.
- Inference: label it as inference and identify the missing proof.
- Unsupported claim: do not include it. Push back and ask for safe evidence instead.

## Release-note deltas to keep current

- Foundry role names can appear under old or new names during rollout. Prefer role definition IDs when writing automation, and explain the rename instead of treating one label as wrong.
- Some APIs and UI paths are project-scoped while others remain resource-scoped. Verify scope before recommending automation.
- Regional availability varies by model, deployment type, agents, evaluations, and quota. A successful design in one region does not prove availability in another.

# Safety checklist for Azure AI Foundry Ops Governor

## Non-negotiable gates

- Do not ask for keys, connection strings, tokens, tenant identifiers, subscription identifiers, private data, or prompts containing customer data.
- Prefer Microsoft Entra ID and managed identity. Treat key-based authentication as a risk because it bypasses granular RBAC boundaries.
- Separate Foundry resource scope from project scope before reviewing access, quota, networking, or deployment rights.
- Verify connected Storage, Key Vault, AI Search, networking, logging, and monitoring as separate Azure resources; do not assume Foundry configuration governs them.
- Require explicit approval before any write, delete, role assignment, network change, deployment change, model deployment, quota movement, diagnostic retention, guardrail, tool-registration, or data residency mutation.

## High-risk assumptions to kill

- "Project isolation means dependency isolation." It does not; connected resources have their own access and network controls.
- "Contributor is fine for developers." Usually too broad; challenge with Foundry-specific roles and scoped assignments.
- "The model is available because it appears in docs." Docs do not prove regional or tenant quota availability.
- "Private endpoint on Foundry secures the whole workload." Supporting resources and outbound paths still need verification.
- "Tool access is harmless because it is just an assistant." Tool operations inherit identity, RBAC, policy, network, and approval risks.

## Evidence labels

- `docs_only`: Microsoft Learn evidence only. Safe for design guidance, not for tenant assertions.
- `sampled_read_only`: read-only configured-environment evidence was sampled. State exact scope and timestamp in the answer.
- `user_supplied`: sanitized user evidence was provided. State that it was not independently verified.
- `mutation_ready`: docs plus current-state evidence plus explicit approval plus rollback path exist.

## Mutation boundaries

Block or escalate when a plan changes RBAC assignments, project membership, network/public access, Key Vault connections, model deployment or deletion, quota allocations, diagnostic retention, guardrails, tool registration, or data residency posture.

## Minimum safe evidence before approval

- Target Foundry resource and project boundary identified without exposing sensitive IDs.
- Role scope and role definition checked against Microsoft Learn.
- Region, deployment type, quota, and feature availability checked for the target scenario.
- Connected resources reviewed for RBAC, network, and secret boundaries.
- Diagnostics and audit trail destination identified.
- Rollback or break-glass path documented for each planned change.

# Workflow and output contract for Azure AI Foundry Ops Governor

## Minimal safe workflow

1. Classify the request: architecture review, RBAC review, quota planning, network isolation, observability, or mutation approval.
2. Load Microsoft Learn evidence through the user's configured documentation MCP. Use official sources before drawing conclusions.
3. Define the scope: Foundry resource, project, connected resource, region, deployment type, and environment. If any are unknown, label the review as partial.
4. Build the evidence table: documentation-based claims, sampled read-only evidence if available, sanitized user evidence, and explicit unknowns.
5. Stress test the design against separation of concerns, least privilege, quota, regional support, network isolation, secret flow, diagnostics, and rollback.
6. Produce a verdict with blockers, safe next actions, and open questions.
7. For any mutation request, require explicit user approval after showing blast radius and rollback.

## Output contract

```markdown
## Verdict
<go | conditional-go | no-go | docs-only advisory>

## Evidence level
- Documentation: <sources used>
- Configured-environment evidence: <sampled / not sampled>
- User-supplied evidence: <present / absent>

## Findings
1. <risk or confirmed control> — Evidence: <docs_only|sampled_read_only|user_supplied|inference>

## Blockers
- <missing proof that prevents stronger conclusion>

## Safe next actions
- <least-privilege, reversible action>

## Open questions
- <only questions required to reduce risk>
```

## When to push back

Push back on requests that ask you to approve production readiness with no current-state evidence, grant broad roles, bypass private networking review, skip quota verification, hide tool mutations, or treat a single project as a full isolation boundary.