@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/aws/aws-waf-reliability-review/references/official-sources.md

@@ -1,28 +1,29 @@
-# Official Sources
+# Official sources
 
-Use when grounding AWS WAF Reliability Pillar behavior or citing documentation.
+Use this reference only when you need source grounding for AWS service behavior or the detailed source list.
 
-## AWS WAF Reliability Pillar
+## AWS documentation
 
+Use these as starting points, not as proof of the user's live AWS state:
 - https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html
-- https://docs.aws.amazon.com/wellarchitected/latest/framework/a-reliability.html
+- https://docs.aws.amazon.com/wellarchitected/latest/framework/reliability.html
+- https://docs.aws.amazon.com/wellarchitected/2023-10-03/framework/rel_planning_for_recovery_disaster_recovery.html
+- https://docs.aws.amazon.com/resilience-hub/latest/userguide/resilience-checks.html
 
-## Compute and scaling
-
-- https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html
-- https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html
-
-## Database HA
+## Grounding rule
 
-- https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html
-- https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html
+Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.
 
-## Chaos and testing
+## Current MCP/documentation refresh (2026-06-02)
 
-- https://docs.aws.amazon.com/fis/latest/userguide/what-is.html
-- https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_chaos_eng.html
+Service facts from official docs:
+- The Well-Architected Reliability Pillar focuses on designing, delivering, and maintaining workloads that perform their intended functions correctly and consistently.
+- Reliability guidance includes foundations, workload architecture, change management, failure management, and DR strategies to meet recovery objectives.
 
-## Grounding rule
+Sampled live evidence:
+- Read-only API availability sampling reported `WellArchitected+GetWorkload` as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Read-only product availability sampling also reported AWS Resilience Hub as `isAvailableIn` in those regions, but that does not prove a workload has an assessed or passing resilience policy.
 
-Official documentation explains service behavior — not the user's current account state. Prefer live AWS MCP evidence or sanitized user-provided evidence for current-state claims.
+Review implications:
+- Require workload dependency map, quotas, autoscaling, health checks, change safety, backup/restore, failover tests, RTO/RPO, and operational runbooks.
+- Do not infer resilience from architecture diagrams or API availability without exercised failure and recovery evidence.

package/skills/aws/aws-waf-reliability-review/references/well-architected-reliability-review.md

@@ -0,0 +1,59 @@
+# Well-Architected Reliability Review Guide
+
+Use this reference for AWS Well-Architected Framework Reliability Pillar reviews. In this repository, `aws-waf-reliability-review` means Well-Architected Framework review, not AWS Web Application Firewall configuration.
+
+## What people get wrong
+
+The lazy story is:
+
+> Multi-AZ plus backups equals reliable.
+
+Wrong. Reliability is measured against explicit objectives and exercised recovery. Architecture diagrams, service defaults, and unused backups do not prove resilience.
+
+Common bad assumptions:
+
+- Multi-AZ deployment proves failure isolation.
+- Auto Scaling means capacity headroom exists.
+- Backups prove restore capability.
+- DR plan proves RTO/RPO compliance.
+- Queue/DLQ presence proves downstream recovery.
+- Well-Architected questionnaire answers equal implementation evidence.
+
+## Reliability-specific failure modes
+
+- No explicit SLO, RTO, RPO, dependency tier, or error budget.
+- Single points of failure hidden in DNS, KMS, NAT, VPC endpoints, IAM roles, data stores, or third-party dependencies.
+- Quotas, throttling, and retry storms are not modeled.
+- Change safety lacks canaries, rollback alarms, deployment circuit breakers, or game-day evidence.
+- Backup retention exists but restore order, permissions, and application consistency are untested.
+- Regional failover path conflicts with data replication lag, identity, DNS TTL, or runbook ownership.
+
+## Minimum safe workflow
+
+1. Confirm workload scope, business criticality, SLO, RTO, RPO, peak load, and dependency map.
+2. Classify failure domains: Availability Zone, Region, account, service dependency, data plane, control plane, and human/operator path.
+3. Review workload architecture, quotas, health checks, scaling, backpressure, retries, queues, and stateful components.
+4. Inspect change-management controls: staged rollout, rollback, alarms, deployment history, and incident correlation.
+5. Verify backup/restore and DR test evidence against RTO/RPO, not just configuration.
+6. Produce findings with severity, evidence level, risk, recommended validation, and owner.
+7. Do not mark reliability ready without exercised failure/recovery evidence.
+
+## Verification targets
+
+- SLO/RTO/RPO and customer-impact definitions
+- dependency map for compute, network, identity, data, DNS, KMS, queues, and third parties
+- quotas, scaling policies, circuit breakers, alarms, synthetic checks, and runbook links
+- backup policy, restore test record, replication lag, and data-consistency notes
+- deployment strategy, rollback alarms, canary/blue-green config, and recent change failure history
+- Resilience Hub assessment, Well-Architected workload answers, incident/postmortem evidence where available
+
+## When to push back
+
+Push back if the user asks to:
+
+- call the workload reliable without SLO/RTO/RPO
+- accept untested backups or DR as evidence
+- ignore quota/throttling risk because current traffic is low
+- treat multi-AZ as equivalent to multi-Region DR
+- recommend availability changes without owner and rollback path
+- confuse this Well-Architected Framework review with AWS Web Application Firewall tuning

package/skills/aws/aws-waf-security-review/SKILL.md

@@ -4,8 +4,8 @@ description: "Review AWS workloads against the Well-Architected Framework Securi
 allowed-tools: Read Grep Glob
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-09"
+  version: "0.1.4"
+  updated: "2026-06-02"
   category: security
 ---
 
@@ -36,3 +36,4 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full WAF security review, formatting findings, or generating the final assessment report.
 - [Safety checklist](references/safety-checklist.md) — use before recommending any IAM, network, KMS, or production-impacting change.
 - [Official sources](references/official-sources.md) — use when grounding AWS service security behavior or citing WAF documentation.
+- [Well-Architected Security Review Guide](references/well-architected-security-review.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.

package/skills/aws/aws-waf-security-review/metadata.json

@@ -15,11 +15,13 @@
   "source_type": "original",
   "official_docs": [
     "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html",
-    "https://aws.amazon.com/security/security-resources/"
+    "https://docs.aws.amazon.com/wellarchitected/latest/framework/security.html",
+    "https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html",
+    "https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub-v2.html"
   ],
   "security_notes": "Read-only advisory. Do not modify IAM policies, SCPs, GuardDuty configurations, or KMS keys without explicit approval. Work from AWS Config exports, Security Hub findings, or sanitized descriptions.",
-  "last_verified": "2026-05-09",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-waf-security-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.4"
 }

package/skills/aws/aws-waf-security-review/references/official-sources.md

@@ -1,30 +1,29 @@
-# Official Sources
+# Official sources
 
-Use when grounding AWS WAF Security Pillar behavior or citing documentation.
+Use this reference only when you need source grounding for AWS service behavior or the detailed source list.
 
-## AWS WAF Security Pillar
+## AWS documentation
 
+Use these as starting points, not as proof of the user's live AWS state:
 - https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html
-- https://docs.aws.amazon.com/wellarchitected/latest/framework/a-security.html
-
-## Identity and access
-
+- https://docs.aws.amazon.com/wellarchitected/latest/framework/security.html
 - https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
-- https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
-- https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html
+- https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub-v2.html
 
-## Detective controls
+## Grounding rule
 
-- https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html
-- https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html
-- https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html
+Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.
 
-## Data protection
+## Current MCP/documentation refresh (2026-06-02)
 
-- https://docs.aws.amazon.com/kms/latest/developerguide/overview.html
-- https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html
-- https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html
+Service facts from official docs:
+- The Well-Architected Security Pillar focuses on protecting data, systems, and assets while delivering business value through risk assessments and mitigation strategies.
+- Security review domains include identity and access management, detective controls, infrastructure protection, data protection, and incident response.
 
-## Grounding rule
+Sampled live evidence:
+- Read-only API availability sampling reported `WellArchitected+GetWorkload` as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Read-only product/API sampling also reported Security Hub and `SecurityHub+GetFindings` available in the sampled regions, but that does not prove detector coverage or finding remediation.
 
-Official documentation explains service behavior — not the user's current account state. Prefer live AWS MCP evidence or sanitized user-provided evidence for current-state claims.
+Review implications:
+- Require IAM evidence, logging/detection coverage, network and workload protection, encryption/data-boundary controls, vulnerability posture, incident-response readiness, and exception tracking.
+- Do not claim Well-Architected security readiness from questionnaire answers without live/repo evidence.

package/skills/aws/aws-waf-security-review/references/well-architected-security-review.md

@@ -0,0 +1,59 @@
+# Well-Architected Security Review Guide
+
+Use this reference for AWS Well-Architected Framework Security Pillar reviews. In this repository, `aws-waf-security-review` means Well-Architected Framework review, not AWS Web Application Firewall configuration.
+
+## What people get wrong
+
+The lazy story is:
+
+> Security review is checking IAM, encryption, and public access.
+
+Wrong. Security posture is an end-to-end control system: identity, detection, infrastructure protection, data protection, vulnerability management, and incident response must all have evidence.
+
+Common bad assumptions:
+
+- No Security Hub finding means secure.
+- Encryption enabled means data protection is complete.
+- IAM managed policies are least privilege.
+- CloudTrail exists, so detective controls are covered.
+- Network private means workload secure.
+- Incident response is ready because a runbook exists.
+
+## Security-specific failure modes
+
+- Multi-account boundaries, SCPs, permission boundaries, and break-glass controls are undefined.
+- Static credentials, long-lived access keys, or broad cross-account trust remain active.
+- Logging/detection coverage is incomplete across accounts, Regions, services, or data planes.
+- KMS key policies, bucket policies, secrets, and data residency controls are unreviewed.
+- Public exposure hides behind CDN/API/LB layers or misconfigured security groups.
+- Findings have no owner, SLA, exception record, or verification after remediation.
+
+## Minimum safe workflow
+
+1. Confirm workload scope, accounts, Regions, data classification, regulatory context, and threat model.
+2. Review identity first: human access, workload roles, federation, privilege boundaries, and break-glass.
+3. Check detective controls: CloudTrail, Config, GuardDuty, Security Hub, IAM Access Analyzer, log retention, and alert routing.
+4. Review infrastructure and data protection: network exposure, KMS, secrets, storage policies, backups, and vulnerability posture.
+5. Check incident readiness: runbooks, contacts, containment paths, forensics logging, and game-day evidence.
+6. Prioritize findings by exploitability, blast radius, business impact, and remediation safety.
+7. Keep recommendations non-mutating unless a separate guarded operator workflow is invoked.
+
+## Verification targets
+
+- Organization/account structure, SCPs, permission boundaries, identity center/federation, MFA, and break-glass controls
+- IAM policies, trust policies, access analyzer findings, unused access, and credential age
+- CloudTrail, Config, GuardDuty, Security Hub, VPC Flow Logs, log destinations, retention, and alert paths
+- public exposure evidence across ALB/API Gateway/CloudFront/S3/security groups/routes
+- KMS key policies, secret rotation, S3/data-store encryption, backups, and data classification
+- incident response runbooks, contacts, tabletop/game-day evidence, and exception register
+
+## When to push back
+
+Push back if the user asks to:
+
+- claim security readiness from questionnaire answers alone
+- ignore unsupported accounts, Regions, or log gaps
+- widen IAM or network access as a shortcut
+- hide critical findings behind generic “best practice” language
+- treat encryption as proof of authorization or data minimization
+- confuse this Well-Architected Framework review with AWS Web Application Firewall rules

package/skills/azure/azure-ai-foundry-ops-governor/SKILL.md

@@ -4,8 +4,8 @@ description: Use this skill for Microsoft Foundry and Azure AI Foundry operation
 allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
-  version: 0.1.0
-  updated: "2026-05-05"
+  version: 0.1.3
+  updated: "2026-06-05"
   category: ai
 ---
 
@@ -16,7 +16,7 @@ metadata:
 Act as a ruthless Azure AI Foundry operations governor. Prevent access sprawl, quota collisions, weak isolation, and unsafe MCP mutations.
 
 Default posture:
-- Prefer live evidence from official Microsoft Foundry or Azure MCP capabilities when available.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP, and use sampled read-only Azure evidence only when the active client exposes it.
 - Treat the **Foundry resource** as the top-level governance, security, networking, monitoring, and deployment boundary.
 - Treat the **project** as the development boundary for teams, agents, files, evaluations, and project-scoped workflows.
 - Do not assume every API or feature works at project scope. Verify whether the workload requires parent resource scope.
@@ -35,7 +35,7 @@ Use this skill when the user asks to:
 
 ## Lean operating rules
 
-- Prefer live Azure or Microsoft evidence first when the active client exposes it; otherwise fall back to official documentation and sanitized user evidence.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP, then sampled read-only Azure evidence when the active client exposes it, then sanitized user evidence.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, broad scope, destructive changes, and hand-wavy production claims.
 - Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
@@ -44,7 +44,9 @@ Use this skill when the user asks to:
 
 Load these only when needed:
 
-- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing live Azure evidence, confirming Microsoft MCP capability, or switching to documentation mode.
+- [Operations guide](references/foundry-ops-governance.md) — use for service-specific pitfalls, design rules, verification targets, and pushback criteria.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only Azure evidence, or sanitized user evidence.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, and credential boundaries.
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks, or formatting the final answer.
 - [Official sources](references/official-sources.md) — use when you need the detailed Microsoft documentation list or source notes.
 

package/skills/azure/azure-ai-foundry-ops-governor/metadata.json

@@ -23,11 +23,14 @@
     "https://learn.microsoft.com/en-us/azure/foundry/how-to/quota",
     "https://learn.microsoft.com/en-us/azure/foundry/foundry-models/quotas-limits",
     "https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/monitor-models",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/"
+    "https://learn.microsoft.com/azure/foundry/mcp/security-best-practices",
+    "https://learn.microsoft.com/security/benchmark/azure/baselines/azure-ai-foundry-security-baseline",
+    "https://learn.microsoft.com/en-us/azure/security/fundamentals/ai-security-best-practices",
+    "https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai/platform/networking"
   ],
-  "security_notes": "Keep Foundry resource governance separate from project developer isolation, prefer Entra ID over key-based auth, verify quota and diagnostics before rollout, and treat MCP mutations as higher risk than read-only discovery, especially because hosted Foundry MCP security guidance documents preview and public-endpoint limitations.",
-  "last_verified": "2026-04-27",
+  "security_notes": "Keep Foundry resource governance separate from project developer isolation, prefer Entra ID over key-based auth, verify quota and diagnostics before rollout, and treat tool-backed mutations as higher risk than read-only discovery, especially because hosted Foundry MCP capability security guidance documents preview and public-endpoint limitations.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-ai-foundry-ops-governor",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.3"
 }

package/skills/azure/azure-ai-foundry-ops-governor/references/foundry-ops-governance.md

@@ -0,0 +1,62 @@
+# 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.

package/skills/azure/azure-ai-foundry-ops-governor/references/mcp-and-evidence.md

@@ -1,34 +1,27 @@
-# MCP and Evidence Path
+# MCP and evidence path for Microsoft Foundry operations governance
 
-## Official Azure / Foundry MCP Linkage
+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.
 
-Use only official Microsoft MCP surfaces documented for this role.
+## Evidence ladder
 
-Preferred order:
-1. **Foundry MCP Server** for Foundry-native operations when the active client exposes it.
-2. **Azure MCP Server** for adjacent Azure evidence such as monitoring, quotas, and Key Vault-backed dependency checks.
-3. **Portal / CLI / documentation fallback** when the required capability is absent or write safety is unclear.
+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** invent MCP namespaces or assume a namespace exists because it would be convenient.
-- Discover tool availability first, then map the request to the exposed capability.
-- Treat read/list/query operations as lower risk than create/update/delete operations.
-- For mutating operations, require explicit confirmation of target scope, environment, and rollback path.
-- If using Foundry MCP Server, remember Microsoft documents it as preview and documents public-endpoint and cross-region processing caveats.
+## Rules
 
-## Platform-Agnostic Execution
+- 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.
 
-This skill must work in MCP-only, portal-guided, CLI-guided, macOS, Linux, and Windows environments.
+## Final-answer evidence language
 
-When examples are needed:
-- use neutral placeholders like `<subscription>`, `<resource-group>`, `<foundry-resource>`, and `<project>`,
-- avoid shell-specific assumptions until the platform is known,
-- prefer evidence collection and decision framing over long command dumps.
+Use phrases like:
 
-## Documentation Fallback When Live Data Is Unavailable
-
-If live access is missing, denied, incomplete, or unsafe:
-- ground recommendations in official Microsoft Learn documentation only,
-- label conclusions as `live evidence`, `documentation-based`, `sanitized user evidence`, or `inference`,
-- do not present documentation as proof of the user's current state,
-- ask for sanitized scope details only when needed: subscription layout, resource count, project count, regions, environment split, or redacted screenshots.
+- "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."

package/skills/azure/azure-ai-foundry-ops-governor/references/official-sources.md

@@ -1,25 +1,29 @@
-# Official Sources
+# Official sources for Azure AI Foundry Ops Governor
 
-## References
+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.
 
-Load only what is needed:
-- Microsoft Foundry architecture
-- Microsoft Foundry rollout planning
-- Foundry RBAC guidance
-- Foundry MCP security best practices
-- Foundry network isolation guidance
-- Foundry quota and monitoring guidance
-- Azure MCP Server tools inventory
+## Primary Microsoft Learn sources
 
-## Official 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. |
 
-- Microsoft Foundry architecture: https://learn.microsoft.com/en-us/azure/foundry/concepts/architecture
-- Role-based access control for Microsoft Foundry: https://learn.microsoft.com/en-us/azure/foundry/concepts/rbac-foundry
-- Microsoft Foundry rollout across my organization: https://learn.microsoft.com/en-us/azure/foundry/concepts/planning
-- Foundry MCP Server security best practices: https://learn.microsoft.com/en-us/azure/foundry/mcp/security-best-practices?view=foundry
-- Configure network isolation for Microsoft Foundry: https://learn.microsoft.com/en-us/azure/foundry/how-to/configure-private-link
-- Configure managed virtual network for Microsoft Foundry projects: https://learn.microsoft.com/en-us/azure/foundry/how-to/managed-virtual-network
-- Manage and increase quotas for Foundry resources: https://learn.microsoft.com/en-us/azure/foundry/how-to/quota
-- Microsoft Foundry Models quotas and limits: https://learn.microsoft.com/en-us/azure/foundry/foundry-models/quotas-limits
-- Monitor model deployments in Microsoft Foundry Models: https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/monitor-models
-- Azure MCP Server tools inventory: https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/
+## 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.

package/skills/azure/azure-ai-foundry-ops-governor/references/safety-checklist.md

@@ -0,0 +1,37 @@
+# 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.