@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

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

@@ -1,28 +1,29 @@
-# Official Sources
+# Official sources
 
-Use when grounding AWS WAF Cost Optimization 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 Cost Optimization 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/cost-optimization-pillar/welcome.html
-- https://docs.aws.amazon.com/wellarchitected/latest/framework/a-cost-optimization.html
+- https://docs.aws.amazon.com/wellarchitected/latest/framework/cost-optimization.html
+- https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_cloud_financial_management.html
+- https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_manage_demand_resources.html
 
-## Cost management tooling
-
-- https://docs.aws.amazon.com/cost-management/latest/userguide/what-is-costmanagement.html
-- https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html
-- https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html
-
-## Commitment discounts
+## Grounding rule
 
-- https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html
-- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.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.
 
-## Rightsizing
+## Current MCP/documentation refresh (2026-06-02)
 
-- https://docs.aws.amazon.com/compute-optimizer/latest/ug/what-is-aws-compute-optimizer.html
-- https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API_GetRightsizingRecommendation.html
+Service facts from official docs:
+- The Well-Architected Cost Optimization Pillar focuses on avoiding unnecessary cost while meeting business outcomes.
+- Cost optimization review areas include cloud financial management, expenditure awareness, cost-effective resources, demand/resource management, and continuous optimization.
 
-## 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`.
+- Cost-review evidence still requires workload, billing, tagging, utilization, and commitment data from the user's account; Well-Architected API availability alone does not prove review status.
 
-Official documentation explains service behavior and pricing models — not the user's current account spend or commitment portfolio. Always use Cost Explorer data or user-provided evidence for spend claims.
+Review implications:
+- Require spend owner, cost allocation/tags, unit economics, utilization, rightsizing, commitment coverage, idle resources, and risk of reliability/security regression before recommending savings.
+- Do not treat Well-Architected answers or tool access as proof that cost risks are remediated.

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

@@ -0,0 +1,59 @@
+# Well-Architected Cost Optimization Review Guide
+
+Use this reference for AWS Well-Architected Framework Cost Optimization Pillar reviews. In this repository, `aws-waf-cost-optimization-review` means Well-Architected Framework review, not AWS Web Application Firewall configuration.
+
+## What people get wrong
+
+The lazy story is:
+
+> Cost optimization means find idle resources and buy commitments.
+
+Wrong. Good cost review preserves business outcomes. Savings that degrade reliability, security, observability, or delivery speed are not automatically good recommendations.
+
+Common bad assumptions:
+
+- Current month spend alone proves waste.
+- Low utilization means safe rightsizing.
+- Reserved Instances or Savings Plans are safe if the discount is large.
+- Untagged resources are minor accounting issues.
+- Spot is always a cost win.
+- Deleting logs, backups, or redundancy is acceptable savings.
+
+## Cost-specific failure modes
+
+- No owner, cost allocation tags, unit-cost metric, or budget accountability.
+- Recommendations ignore seasonality, migration, incident recovery, test load, or business growth.
+- Commitment purchase locks in wrong family/Region/account or hides architecture change plans.
+- Rightsizing ignores burst, memory, I/O, latency, failover, or compliance requirements.
+- Observability, backup, security, or resilience costs are cut without risk acceptance.
+- Savings estimate uses list pricing or aggregates without amortized/unblended context.
+
+## Minimum safe workflow
+
+1. Confirm workload, payer/member account scope, monthly spend, business owner, unit economics, and cost target.
+2. Break down cost by service, account, Region, usage type, operation, tag, and resource where supported.
+3. Evaluate governance: tagging, budgets, anomaly detection, chargeback/showback, and owner accountability.
+4. Separate quick wins from structural optimization, commitment strategy, and risky workload changes.
+5. Estimate savings with assumptions, confidence, operational risk, and pillar tradeoffs.
+6. Require owner approval before deletion, downscaling, commitment purchase, retention reduction, or architecture change.
+7. Track recommendations as experiments with rollback criteria and post-change cost validation.
+
+## Verification targets
+
+- Cost Explorer/Billing data grouped by service, account, Region, usage type, operation, tag, and resource where available
+- budget, anomaly detection, cost category, and tag coverage evidence
+- utilization metrics, performance headroom, workload seasonality, and business-critical periods
+- Savings Plans/RI coverage, utilization, expiration, and purchase constraints
+- idle/underused resources with owner and purpose confirmation
+- reliability/security/observability impact for any proposed savings action
+
+## When to push back
+
+Push back if the user asks to:
+
+- recommend commitments without usage stability and roadmap evidence
+- delete backups/logs/redundancy for savings without risk acceptance
+- rights-size production from average utilization only
+- blame teams from untagged or payer-level aggregates
+- ignore security or reliability tradeoffs
+- confuse this Well-Architected Framework review with AWS Web Application Firewall cost tuning

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

@@ -4,8 +4,8 @@ description: "Review AWS workload reliability posture against the Well-Architect
 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: resilience
 ---
 
@@ -36,3 +36,4 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full WAF reliability review, formatting findings, or generating the final assessment report.
 - [Safety checklist](references/safety-checklist.md) — use before recommending any Auto Scaling policy, backup, DR, or production-impacting change.
 - [Official sources](references/official-sources.md) — use when grounding AWS service reliability behavior or citing WAF documentation.
+- [Well-Architected Reliability Review Guide](references/well-architected-reliability-review.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.

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

@@ -15,11 +15,13 @@
   "source_type": "original",
   "official_docs": [
     "https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html",
-    "https://aws.amazon.com/architecture/well-architected/"
+    "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"
   ],
   "security_notes": "Read-only advisory. Do not modify Auto Scaling policies, backup schedules, or DR configurations without explicit approval.",
-  "last_verified": "2026-05-09",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-waf-reliability-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.4"
 }

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."