@raishin/vanguard-frontier-agentic 3.0.0-alpha.7 → 3.0.1

package/skills/sap/sap-abap-cloud-rap-review/references/official-sources.md

@@ -0,0 +1,95 @@
+# Official sources — SAP ABAP Cloud RAP Review
+
+Use this reference when grounding RAP behavior definition design, CDS view modeling, authorization control, draft handling, ABAP unit testing, and released API compliance.
+
+**Evidence level**: documentation-based (SAP Help Portal — help.sap.com/docs/abap-cloud, SAP API Business Hub). No live-system evidence is collected by this skill.
+
+## RAP core documentation
+
+- ABAP RESTful Application Programming Model (RAP) — overview
+  https://help.sap.com/docs/abap-cloud/abap-rap/abap-restful-application-programming-model
+  source_owner: SAP SE
+  topic_supported: RAP programming model overview, business object layers, OData service generation, RAP on S/4HANA and BTP ABAP Environment
+  why_needed: Primary taxonomy for RAP artifact classification and component role assignment
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- What is ABAP Cloud
+  https://help.sap.com/docs/abap-cloud/abap-cloud/what-is-abap-cloud
+  source_owner: SAP SE
+  topic_supported: ABAP Cloud programming model tiers, tier-2 compliance rules, forbidden language constructs, object release status
+  why_needed: Defines the ABAP Cloud tier compliance rules that govern what is and is not permitted in clean-core RAP objects
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Behavior Definition (BDEF)
+
+- RAP Behavior Definition
+  https://help.sap.com/docs/abap-cloud/abap-rap/behavior-definition
+  source_owner: SAP SE
+  topic_supported: BDEF syntax, managed vs. unmanaged implementation type, draft enablement (with draft), authorization master/dependent, alias, feature control, action and function declarations, association exposure
+  why_needed: Authoritative reference for BDEF correctness review; defines required keywords and their semantics
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## CDS data model
+
+- RAP CDS Data Model
+  https://help.sap.com/docs/abap-cloud/abap-rap/cds-data-model
+  source_owner: SAP SE
+  topic_supported: Interface CDS views (data definitions), projection CDS views, consumption views, CDS metadata extensions, access control (DCL), draft table configuration, UUID key design
+  why_needed: Defines the three-layer CDS view hierarchy (interface / projection / consumption) and access control (DCL) patterns; used to classify view type misuse and annotation gaps
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Authorization control
+
+- RAP Authorization Control
+  https://help.sap.com/docs/abap-cloud/abap-rap/authorization-control
+  source_owner: SAP SE
+  topic_supported: Authorization master and dependent assignment in BDEF, CHECK_AUTHORIZATION method implementation, AUTHORITY-CHECK for RAP operations, instance-based authorization
+  why_needed: Defines the RAP authorization model; used to classify missing or pass-through authorization checks
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Draft handling
+
+- RAP Draft Handling
+  https://help.sap.com/docs/abap-cloud/abap-rap/draft-handling
+  source_owner: SAP SE
+  topic_supported: Draft-enabled entities, draft table configuration, draftActivate action, BeforeSave validation, lock expiry, draft discard, ETag handling
+  why_needed: Defines RAP draft implementation requirements; used to identify incomplete draft configuration and missing validation handlers
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## ABAP unit testing for RAP
+
+- ABAP Unit Tests for RAP Business Objects
+  https://help.sap.com/docs/abap-cloud/abap-rap/abap-unit-tests-for-rap-business-objects
+  source_owner: SAP SE
+  topic_supported: if_abap_behv_test_environment, if_cds_test_environment, test class structure, MODIFY ENTITIES test calls, ROLLBACK ENTITIES teardown, test double creation
+  why_needed: Defines correct RAP unit test patterns; used to classify missing test doubles and absent teardown methods
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Released API compliance
+
+- Released ABAP Object Types
+  https://help.sap.com/docs/abap-cloud/abap-cloud/released-abap-object-types
+  source_owner: SAP SE
+  topic_supported: C1/C2 release contract definitions, object release status (RELEASED, NOT_RELEASED, DEPRECATED), what is permitted in ABAP Cloud tier-1 and tier-2
+  why_needed: Defines the release contract taxonomy used for classifying NOT_RELEASED API consumption findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP API Business Hub — SAP S/4HANA Cloud product overview and released APIs
+  https://api.sap.com/products/SAPS4HANACloud/overview
+  source_owner: SAP SE
+  topic_supported: C1/C2 released API catalog for S/4HANA and BTP ABAP Environment; used to verify replacement candidates for NOT_RELEASED objects
+  why_needed: Authoritative source for confirming which ABAP objects carry a release contract; must be used to validate any proposed replacement API
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Help Portal documentation describes design intent, required patterns, and release contracts. It does not prove which objects exist in the user's ABAP system, what their release status is in a specific system version, or whether SAP notes have been applied. Users must supply ABAP source code, CDS DDL definitions, BDEF source, or written descriptions of their RAP object model for concrete assessment.

package/skills/sap/sap-abap-cloud-rap-review/references/safety-checklist.md

@@ -0,0 +1,37 @@
+# Safety checklist — SAP ABAP Cloud RAP Review
+
+Use before making any finding or remediation recommendation, especially for authorization and released API compliance findings.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live ABAP system, SAP S/4HANA tenant, or BTP ABAP Environment. This skill reviews artifacts only.
+- Do not accept or request system credentials, RFC connection parameters, logon data, BTP service keys, or client secrets.
+- Do not classify `update_granted = abap_true` (simulated full access) as acceptable in production-bound code. This pattern is explicitly documented as a development-only simulation that must be removed before production deployment.
+- Do not validate release contract status from memory alone. Direct the user to verify proposed C1/C2 alternatives on SAP API Business Hub (api.sap.com) for the specific S/4HANA or BTP ABAP Environment version in scope.
+- Do not recommend consuming NOT_RELEASED SAP internal objects as a remediation step, even if they are technically functional. Only C1/C2 released objects are clean-core compliant in ABAP Cloud.
+- Do not classify a RAP business object's authorization coverage as complete without reviewing the `CHECK_AUTHORIZATION` method implementation. A BDEF with `authorization master ( global )` is meaningless if the method contains pass-through logic.
+- Do not confuse RAP managed and unmanaged implementation types. Managed RAP uses the RAP framework for persistence; unmanaged RAP delegates to custom code. The wrong selection affects OData behavior, draft support, and lock handling.
+
+## What people get wrong
+
+- **Leaving AUTHORITY-CHECK simulation in production**: The `update_granted = abap_true` simulation pattern is a documented development shortcut from openSAP exercises. Any behavior implementation containing this in a production-bound branch is a critical security finding.
+- **Treating `authorization master ( global )` as sufficient**: Declaring `authorization master ( global )` in the BDEF is a structural declaration, not an authorization guarantee. The `CHECK_AUTHORIZATION` method must implement actual `AUTHORITY-CHECK` statements for it to be meaningful.
+- **Assuming draft works without draft table**: `with draft;` in the BDEF requires a matching `draft table` definition in the CDS interface view. Missing the CDS-side draft table causes a runtime error on activation.
+- **Using interface views directly in service bindings**: Interface views should not appear directly in service bindings. The correct pattern is: interface view → projection view → service definition → service binding.
+- **Confusing ROLLBACK WORK and ROLLBACK ENTITIES**: In RAP unit tests, `ROLLBACK ENTITIES` is the correct teardown mechanism, not `ROLLBACK WORK`. Using `ROLLBACK WORK` does not clean up the RAP buffer.
+- **Asserting only initial result in unit tests**: A test that only asserts `assert_initial( failed-travel )` without asserting expected field values provides weak coverage — the test passes even if the result is empty.
+
+## When to push back
+
+- Push back when the user asks for an authorization compliance ruling without providing the behavior implementation class source code for `CHECK_AUTHORIZATION`.
+- Push back when the user proposes to keep a `update_granted = abap_true` simulation in code that will go to production.
+- Push back when released API compliance is in scope but no ABAP source code or object list is provided for review.
+- Push back when the request involves live ABAP system access, ATC execution, or object navigation — redirect to SAP ABAP Test Cockpit or `sap-clean-core-debt-review` for live object enumeration first.
+- Push back when the user proposes consuming a NOT_RELEASED SAP object as a workaround and presents performance or convenience as justification.
+
+## Evidence labels
+
+- `documentation-based` — grounded in official SAP ABAP Cloud docs (help.sap.com/docs/abap-cloud) or SAP Help Portal RAP documentation
+- `user-provided evidence` — ABAP source code, CDS DDL, BDEF source, metadata extensions, or written descriptions provided by the user
+- `context7-supplementary` — RAP authorization and unit test patterns from Context7 openSAP sample repository (supplementary to official SAP docs)
+- `inference` — derived reasoning not directly confirmed; must always be labeled as such

package/skills/sap/sap-abap-cloud-rap-review/references/workflow-and-output.md

@@ -0,0 +1,76 @@
+# Workflow and output contract — SAP ABAP Cloud RAP Review
+
+Use this reference for all classification, severity assignment, and output formatting.
+
+## Review domain taxonomy
+
+| Domain | Scope |
+|--------|-------|
+| `CDS Views` | View type selection (interface/projection/consumption), annotation completeness, metadata extensions, access control (DCL), UUID key design, draft table configuration |
+| `BDEF` | Implementation type (managed/unmanaged), draft enablement, authorization master/dependent, alias, feature control, action/function declarations, association exposure |
+| `Behavior Implementation` | AUTHORITY-CHECK coverage, action method completeness, validation message patterns, determination logic, forbidden language constructs |
+| `Released API Compliance` | C1/C2 contract verification, NOT_RELEASED consumption, DEPRECATED object usage, tier-2 compliance |
+| `ABAP Unit Tests` | Test double usage (if_abap_behv_test_environment / if_cds_test_environment), test class structure, ROLLBACK ENTITIES teardown, CREATE ENTITIES test correctness |
+| `Object Composition` | Root vs. child entity hierarchy, composition relationship completeness, ETag strategy, UUID vs. semantic key trade-offs |
+
+## Severity classification
+
+| Severity | Meaning | Examples |
+|----------|---------|---------|
+| `critical` | Security breach or data integrity loss risk | AUTHORITY-CHECK simulation left active in production-bound code; authorization master method returning allowed without any check |
+| `high` | Functional, correctness, or upgrade-blocking risk | NOT_RELEASED API consumption; missing `with draft;` on a BO requiring Fiori draft editing; missing draftActivate method; unmanaged RAP with no justification |
+| `medium` | Governance, maintainability, or test isolation gap | ROLLBACK ENTITIES missing in test teardown; CDS metadata extension annotations on wrong view layer; unmanaged implementation where managed would suffice |
+| `low` | Best practice deviation or code quality concern | Inconsistent CDS naming conventions; missing alias in BDEF; action not declared as static where appropriate |
+
+## Common finding patterns
+
+### BDEF
+- `with draft;` absent on a root entity that requires Fiori Elements draft editing (high)
+- `authorization master ( global )` declared but CHECK_AUTHORIZATION never implemented in the behavior implementation class (critical)
+- `authorization dependent by _ParentAssociation` incorrectly used on the root entity (high — only valid for child entities)
+- Unmanaged BDEF without documented justification on a greenfield BO (medium)
+
+### Behavior Implementation
+- `update_granted = abap_true` or `delete_granted = abap_true` hard-coded without actual `AUTHORITY-CHECK` — simulation left from development (critical)
+- `AUTHORITY-CHECK OBJECT` used for update but not for delete (high — asymmetric authorization check)
+- Missing `APPEND VALUE #(...) TO reported-travel` for unauthorized operations — authorization failure not surfaced to the caller (high)
+- Validation method that returns without any `APPEND TO failed` or `APPEND TO reported` (high — silent failure)
+
+### CDS Views
+- Interface view directly used in service binding instead of projection view (medium — bypass of projection separation)
+- Access control (DCL) missing on interface view (high for sensitive entities)
+- Draft table not defined on the root CDS interface view while `with draft;` is in the BDEF (high — runtime error)
+- Metadata extension annotations placed on interface view instead of projection view (medium)
+
+### Released API Compliance
+- Direct SELECT from SAP standard database table without C1 released CDS view equivalent (high)
+- Consumption of a function module or BAPI with no C1/C2 release contract in ABAP Cloud context (high)
+- Use of DEPRECATED released objects without noting migration path (medium)
+
+### ABAP Unit Tests
+- Test class uses `MODIFY ENTITIES` against live data without `cl_cds_test_environment` or `cl_abap_behv_test_environment` double (high)
+- `ROLLBACK ENTITIES` absent in `teardown` method (medium)
+- `cds_test_environment->destroy()` absent in `class_teardown` (medium)
+- Test method asserts only initial result without asserting expected field values (low)
+
+## Workflow
+
+1. **Receive artifacts** — ABAP source code, CDS DDL files, BDEF source, metadata extensions, access control definitions, or user descriptions.
+2. **Classify each finding** by review domain above.
+3. **Assign severity** (critical / high / medium / low).
+4. **Identify evidence level** (documentation-based / user-provided evidence / context7-supplementary / inference).
+5. **Recommend specific remediation** — ABAP code pattern to apply, BDEF keyword to add, DCL source to create, API Business Hub check to perform.
+6. **Prioritize** — critical and high severity first; released API compliance and authorization before structural findings; test isolation before style.
+7. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. Artifacts reviewed and domains in scope
+2. Finding(s) per domain with severity and evidence label
+3. Specific remediation recommendation per finding (with code-level detail from user-provided evidence where available)
+4. Released API compliance summary — list any NOT_RELEASED or DEPRECATED objects with recommended C1/C2 alternatives (to be verified on API Business Hub)
+5. Authorization coverage summary — AUTHORITY-CHECK status for each operation (create/update/delete) per reviewed behavior implementation
+6. Prioritized remediation sequence (critical → high → medium → low)
+7. Escalation trigger if live ABAP system access or ATC execution is required before proceeding

package/skills/sap/sap-ai-core-generative-ai-hub-governance/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: sap-ai-core-generative-ai-hub-governance
+description: Governance review for SAP AI Core, AI Launchpad, and Generative AI Hub deployments. Assesses model access control, data privacy for RAG pipelines and embeddings, prompt-injection risk in orchestration configurations, grounding data classification, prompt-log handling, and auditability of AI outputs. Does not run models or access production AI deployments.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: ai
+  lifecycle: experimental
+---
+
+# SAP AI Core Generative AI Hub Governance
+
+## Purpose
+
+Assess the governance posture of SAP AI Core, AI Launchpad, and Generative AI Hub deployments. Review model access control: resource group isolation, role assignments in AI Launchpad, and AI API service key scope. Review data privacy for RAG pipelines: classification of grounding data sources, embedding storage location, data residency of vector stores, and personal data exposure in retrieval results. Assess prompt-injection risk in orchestration configurations: unguarded template variables, absent input/output content safety filters, and missing grounding data sanitization. Review prompt-log handling and retention: whether prompts containing personal or confidential data are logged, where logs are stored, and whether log access is role-restricted. Assess auditability of AI outputs: traceability of model responses to grounding sources, audit trail completeness, and model version pinning. Does not invoke models, connect to live AI Core deployments, or process production data.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review AI Core resource group structure and role assignment for model access isolation,
+- assess AI Launchpad user role configuration: `aicore_admin`, `aicore_viewer`, `genai_manager`, `genai_viewer` role assignments and separation of duties,
+- evaluate Generative AI Hub orchestration configuration for prompt-injection risk: input/output content safety filter coverage, unguarded template variable injection points, and system-prompt integrity,
+- audit grounding data classification: whether documents in the Document Grounding Service or vector store are classified by data sensitivity before ingestion, whether personal data or confidential business data is ingested into shared vector stores,
+- review prompt-log handling: whether prompt logging is enabled, log retention period, log access controls, and compliance with data residency requirements for logged prompts containing personal data,
+- assess embedding and vector store data privacy: which data is vectorized, where embeddings are stored, cross-tenant vector store isolation, and right-to-erasure implications for embedded personal data,
+- evaluate auditability of Generative AI Hub outputs: model version pinning, grounding source attribution in responses, audit log completeness for AI-assisted decisions, and explainability requirements.
+
+## When not to use
+
+- When the request requires connecting to a live AI Core deployment, running model inference, or accessing production prompt logs — this skill reviews configuration artifacts and governance descriptions only.
+- When the request is about BTP account-level governance (entitlements, subaccounts, role collections) unrelated to AI services — use `sap-btp-governance-review`.
+- When the request is about integration wiring between AI Core and other SAP services via Integration Suite — use `sap-integration-suite-review`.
+- When the request is about training custom ML models on BTP AI Core (pipeline configuration, Docker images, custom training workflows) rather than Generative AI Hub governance.
+
+## Does not touch live systems
+
+This skill operates on user-provided orchestration configuration files, role assignment descriptions, resource group layouts, grounding pipeline configuration, data classification documentation, or written descriptions of the AI governance posture. It does not invoke any Generative AI Hub model, access AI Core deployment APIs, read prompt logs, query vector stores, or connect to AI Launchpad. All live inspection is out of scope.
+
+## Lean operating rules
+
+- Classify governance findings before recommending. Every finding must be assigned to a governance domain (Model Access / Data Privacy / Prompt Injection Risk / Grounding Data / Prompt Logging / Auditability) before remediation is proposed.
+- Content safety filters are required on both input and output for customer-facing orchestration pipelines. An orchestration configuration without `filtering_module_config` on both the input and output path is a `high` finding for prompt injection and harmful output risk.
+- Grounding data classification must precede ingestion. Ingesting unclassified documents into a vector store shared across resource groups or tenants is a `high` finding for data privacy. Personal data in grounding documents must be identified before vectorization.
+- Prompt logging of personal data requires legal basis and residency compliance. If prompts submitted by end users may contain personal data (names, IDs, health data, financial data), prompt logging must be evaluated against the applicable data protection regulation (GDPR, local law). Unreviewed prompt logging with no retention limit is a `medium` finding.
+- Embedding personal data creates right-to-erasure obligations. Personal data vectorized into embeddings cannot be trivially erased. Any grounding pipeline ingesting personal data must have a documented erasure procedure or must exclude personal data from vectorization.
+- Model version must be pinned for AI-assisted decisions. An orchestration configuration using `latest` or a floating model version alias for any workflow that produces auditable business outputs is a `medium` finding for reproducibility.
+- Resource group isolation is the primary access control boundary. All model deployments, vector stores, and grounding pipelines must be assigned to the appropriate resource group. Cross-resource-group access without documented justification is a `high` finding.
+- Evidence from official SAP AI Core, AI Launchpad, and Generative AI Hub documentation takes precedence over inference.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in official SAP AI Core, AI Launchpad, or Generative AI Hub documentation (help.sap.com)
+- `user-provided evidence` — orchestration configuration files, role assignment descriptions, grounding pipeline design, data classification documentation, or written descriptions provided by the user
+- `context7-supplementary` — grounded in SAP Generative AI Hub orchestration configuration patterns from Context7 (supplementary; applies for content safety filter configuration and grounding module structure)
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence
+
+## Live-environment rules and data privacy rules
+
+**This skill does not touch live systems.** There is no AI Core API call, Generative AI Hub model invocation, vector store query, prompt log access, or AI Launchpad session in this skill's execution path.
+
+**Data privacy rules for this review skill:**
+
+- Do not request, accept, or process actual prompt logs, user message history, or inference outputs from production deployments.
+- Do not request actual grounding documents, embeddings, or vector store contents. Accept only descriptions of data classification and pipeline configuration.
+- Do not request AI Core service keys, OAuth tokens, or resource group credentials.
+- When the user describes a grounding pipeline that handles personal data, advise on governance controls without requesting the underlying data.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — governance domain taxonomy, severity classification, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, common AI governance mistakes, when to push back.
+- [Official sources](references/official-sources.md) — SAP AI Core, AI Launchpad, Generative AI Hub, and Document Grounding Service documentation.
+- [Context7 framework docs](references/context7-framework-docs.md) — SAP Generative AI Hub orchestration configuration patterns (supplementary; applies for content safety filter and grounding module configuration).
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: governance domain(s) in scope and specific finding(s) per domain.
+- **Evidence used**: documentation-based / user-provided evidence / context7-supplementary / inference.
+- **Risk level**: critical (regulatory breach, data exfiltration, or security bypass risk) / high (governance control gap with material privacy or security impact) / medium (audit or compliance gap) / low (best practice deviation).
+- **Recommended action**: specific governance control per finding (add content safety filter, classify grounding data before ingestion, restrict prompt log access, pin model version, define erasure procedure for embedded personal data, etc.).
+- **Refusal / escalation triggers**: if live AI Core access, prompt log inspection, or vector store content review is required to complete the governance assessment, state that clearly and do not proceed. If the configuration may contain personal data, do not accept it directly — request a redacted or anonymized description instead.
+- **Business impact**: regulatory exposure (GDPR, local data protection law), AI output reliability risk, audit trail gap, or reputational risk from harmful model output.
+- **Next verification step**: validate recommended governance controls against current SAP AI Core configuration documentation and applicable data protection regulation before deploying changes.

package/skills/sap/sap-ai-core-generative-ai-hub-governance/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "SAP AI Core Generative AI Hub Governance"
+  short_description: "Governance review for SAP AI Core, AI Launchpad, and Generative AI Hub: model access control, data privacy, prompt-injection risk, grounding data classification, prompt-log handling, and AI output auditability"
+  default_prompt: "Use $sap-ai-core-generative-ai-hub-governance to assess the provided SAP Generative AI Hub governance artifacts. Classify findings by domain (Model Access / Data Privacy / Prompt Injection Risk / Grounding Data / Prompt Logging / Auditability), assign severity (critical / high / medium / low), state evidence level (documentation-based / user-provided evidence / context7-supplementary / inference), and recommend specific governance controls per finding. Do not request actual prompt logs, grounding data contents, embeddings, or AI Core service credentials."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/sap-ai-core/sap-ai-core-service-guide/security-and-data-protection"
+      description: "SAP AI Core security and data protection guide — verify data residency, privacy controls, and access governance requirements for the target AI Core service plan"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-ai-core-generative-ai-hub-governance/metadata.json

@@ -0,0 +1,34 @@
+{
+  "id": "sap-ai-core-generative-ai-hub-governance",
+  "name": "SAP AI Core Generative AI Hub Governance",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Governance review for SAP AI Core, AI Launchpad, and Generative AI Hub: model access control, data privacy for RAG/embeddings, prompt-injection risk in orchestration configurations, grounding data classification, prompt-log handling, and auditability of AI outputs. Does not run models or access production AI deployments.",
+  "source_type": "original",
+  "category": "ai",
+  "official_docs": [
+    "https://help.sap.com/docs/sap-ai-core/sap-ai-core-service-guide/what-is-sap-ai-core",
+    "https://help.sap.com/docs/sap-ai-core/sap-ai-core-service-guide/resource-groups",
+    "https://help.sap.com/docs/ai-launchpad/sap-ai-launchpad/what-is-sap-ai-launchpad",
+    "https://help.sap.com/docs/sap-ai-core/generative-ai/generative-ai-hub-in-sap-ai-core",
+    "https://help.sap.com/docs/sap-ai-core/generative-ai/orchestration",
+    "https://help.sap.com/docs/sap-ai-core/generative-ai/document-grounding",
+    "https://help.sap.com/docs/sap-ai-core/sap-ai-core-service-guide/security-and-data-protection",
+    "https://help.sap.com/docs/sap-ai-core/generative-ai/data-protection-and-privacy",
+    "https://help.sap.com/docs/ai-launchpad/sap-ai-launchpad/roles-and-authorizations"
+  ],
+  "security_notes": "Does not access live AI Core deployments, invoke Generative AI Hub models, read prompt logs, query vector stores, or connect to AI Launchpad. Accepts only orchestration configuration files, role assignment descriptions, grounding pipeline design, data classification documentation, or written descriptions. Never request or accept AI Core service keys, OAuth tokens, resource group credentials, actual prompt logs, grounding document contents, or embeddings. If user-provided configuration may contain personal data, request a redacted version.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-ai-core-generative-ai-hub-governance",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-ai-core-generative-ai-hub-governance/references/context7-framework-docs.md

@@ -0,0 +1,107 @@
+# Context7 framework docs — SAP AI Core Generative AI Hub Governance
+
+**Role**: supplementary. Official SAP AI Core and Generative AI Hub documentation (help.sap.com) is the primary source for all governance guidance. Context7-sourced Generative AI Hub documentation supplements with concrete orchestration configuration structure for content safety filtering and grounding module setup — both directly relevant to prompt-injection risk and grounding data governance.
+
+**Library used**: SAP AI Core Generative AI Hub
+Context7 library ID: `/websites/help_sap_sap-ai-core_generative-ai`
+Lookup target: orchestration configuration, content safety filtering (filtering_module_config), grounding module (grounding_module_config), prompt template variables, metadata exposure in retrieval
+Skill: `sap-ai-core-generative-ai-hub-governance`
+Classification: supplementary — applies for prompt-injection risk and grounding data governance domains
+
+---
+
+## Orchestration — content safety filter configuration (supplementary)
+
+Source: help.sap.com SAP AI Core Generative AI Hub (Context7 `/websites/help_sap_sap-ai-core_generative-ai`)
+Reference: https://help.sap.com/docs/sap-ai-core/generative-ai/contextualized-retrieval-using-metadata-and-vector-search
+
+Content safety filtering is configured via `filtering_module_config` in the orchestration request body. Both input and output paths must be configured independently:
+
+```json
+"filtering_module_config": {
+    "input": {
+        "filters": [
+            {
+                "type": "azure_content_safety",
+                "config": {
+                    "Hate": 2,
+                    "SelfHarm": 2,
+                    "Sexual": 2,
+                    "Violence": 2
+                }
+            }
+        ]
+    },
+    "output": {
+        "filters": [
+            {
+                "type": "azure_content_safety",
+                "config": {
+                    "Hate": 2,
+                    "SelfHarm": 2,
+                    "Sexual": 2,
+                    "Violence": 2
+                }
+            }
+        ]
+    }
+}
+```
+
+**Governance relevance:**
+- `filtering_module_config` must appear in every orchestration configuration that accepts user input or returns output to end users. Its absence is a `high` finding.
+- The `input` filter screens prompts before they reach the model — primary defense against harmful input and some prompt injection patterns.
+- The `output` filter screens model responses before they reach the caller — defense against harmful model output.
+- Threshold values (0–6): lower values = more permissive (more content passes); higher values = more restrictive. Setting thresholds to 0 effectively disables filtering for that category — a `high` finding for customer-facing pipelines.
+- `azure_content_safety` is the filter type available in the standard Generative AI Hub orchestration service. Governance reviews must confirm the filter type matches what the target deployment supports.
+
+---
+
+## Orchestration — grounding module and metadata exposure (supplementary)
+
+Source: help.sap.com SAP AI Core Generative AI Hub (Context7 `/websites/help_sap_sap-ai-core_generative-ai`)
+Reference: https://help.sap.com/docs/sap-ai-core/generative-ai/contextualized-retrieval-using-metadata-and-vector-search
+
+The grounding module (`grounding_module_config`) retrieves documents from a vector store and injects them into the prompt via a named output parameter:
+
+```json
+"grounding_module_config": {
+    "type": "document_grounding_service",
+    "config": {
+        "filters": [
+            {
+                "id": "filter1",
+                "data_repositories": ["*"],
+                "search_config": {},
+                "data_repository_type": "vector"
+            }
+        ],
+        "input_params": ["groundingRequest"],
+        "output_param": "groundingOutput",
+        "metadata_params": ["source", "webUrl"]
+    }
+}
+```
+
+**Governance relevance:**
+- `data_repositories: ["*"]` queries all vector stores accessible in the resource group. Governance review should confirm this is intentional — if only specific repositories should be queried, explicit repository IDs should be listed.
+- `metadata_params: ["source", "webUrl"]` exposes document source metadata in the orchestration response. Internal URLs, access-controlled document paths, or identifiers that reveal internal system topology may constitute an information disclosure finding if returned to end users without review.
+- `output_param: "groundingOutput"` injects retrieved document content into the prompt template via `{{ ?groundingOutput }}`. If grounding documents can contain untrusted or externally sourced content, this injection point is a vector for indirect prompt injection. Review whether `{{ ?groundingOutput }}` appears in the system message (high risk) or user message (medium risk).
+- `input_params: ["groundingRequest"]` takes the grounding query from a prompt template variable. Review whether this variable is user-controlled (`{{ ?userInput }}`) — if so, users can influence which documents are retrieved, potentially extracting information from the vector store beyond their intended scope.
+
+---
+
+## Scope boundaries for Context7 usage
+
+Context7 SAP Generative AI Hub documentation applies to:
+
+- **Prompt Injection Risk**: `filtering_module_config` structure, content safety threshold semantics, grounding output injection patterns
+- **Grounding Data**: `grounding_module_config` structure, `data_repositories` scope, `metadata_params` exposure
+
+It does not replace official SAP documentation for:
+- AI Core resource group isolation and access control (use help.sap.com/docs/sap-ai-core/sap-ai-core-service-guide/resource-groups)
+- AI Launchpad role definitions and separation of duties (use help.sap.com/docs/ai-launchpad/sap-ai-launchpad/roles-and-authorizations)
+- Data residency and data protection requirements (use help.sap.com/docs/sap-ai-core/generative-ai/data-protection-and-privacy)
+- Prompt logging behavior and retention (use help.sap.com/docs/sap-ai-core/generative-ai/data-protection-and-privacy)
+
+Always label Context7-sourced guidance as `context7-supplementary` in responses.

package/skills/sap/sap-ai-core-generative-ai-hub-governance/references/official-sources.md

@@ -0,0 +1,91 @@
+# Official sources — SAP AI Core Generative AI Hub Governance
+
+Use this reference when grounding AI Core model access, AI Launchpad role governance, Generative AI Hub orchestration, grounding data classification, data privacy, and audit requirements.
+
+**Evidence level**: documentation-based (SAP Help Portal — help.sap.com). No live-system evidence is collected by this skill.
+
+## SAP AI Core — service overview and access control
+
+- What is SAP AI Core
+  https://help.sap.com/docs/sap-ai-core/sap-ai-core-service-guide/what-is-sap-ai-core
+  source_owner: SAP SE
+  topic_supported: AI Core service overview, supported use cases, service plan tiers (standard, extended), BTP subaccount integration
+  why_needed: Establishes which AI Core service plan features are available; service plan determines available governance controls
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP AI Core Resource Groups
+  https://help.sap.com/docs/sap-ai-core/sap-ai-core-service-guide/resource-groups
+  source_owner: SAP SE
+  topic_supported: Resource group creation, isolation scope, assignment of model deployments, vector stores, and grounding pipelines to resource groups; cross-resource-group access controls
+  why_needed: Resource group is the primary access control and isolation boundary for AI Core workloads; used to classify cross-resource-group access findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP AI Core Security and Data Protection
+  https://help.sap.com/docs/sap-ai-core/sap-ai-core-service-guide/security-and-data-protection
+  source_owner: SAP SE
+  topic_supported: Data residency, encryption at rest and in transit, tenant isolation, AI Core security posture, responsible AI use policy
+  why_needed: Authoritative source for data residency requirements and security baseline; used to classify data protection gaps
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## AI Launchpad — roles and authorizations
+
+- What is SAP AI Launchpad
+  https://help.sap.com/docs/ai-launchpad/sap-ai-launchpad/what-is-sap-ai-launchpad
+  source_owner: SAP SE
+  topic_supported: AI Launchpad overview, supported AI Core connection types, user interface for managing AI workloads
+  why_needed: Establishes AI Launchpad scope and integration with AI Core; context for role-based access review
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP AI Launchpad Roles and Authorizations
+  https://help.sap.com/docs/ai-launchpad/sap-ai-launchpad/roles-and-authorizations
+  source_owner: SAP SE
+  topic_supported: aicore_admin, aicore_viewer, genai_manager, genai_viewer role definitions; separation of duties; role collection assignment in BTP
+  why_needed: Defines the role taxonomy for AI Launchpad access governance; used to classify overprivileged role assignments and missing separation of duties
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Generative AI Hub — orchestration and governance
+
+- Generative AI Hub in SAP AI Core
+  https://help.sap.com/docs/sap-ai-core/generative-ai/generative-ai-hub-in-sap-ai-core
+  source_owner: SAP SE
+  topic_supported: Generative AI Hub capabilities, supported models, model access via orchestration service, enterprise governance runtime
+  why_needed: Primary overview for Generative AI Hub scope; confirms enterprise governance is the intended operating posture
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Generative AI Hub Orchestration
+  https://help.sap.com/docs/sap-ai-core/generative-ai/orchestration
+  source_owner: SAP SE
+  topic_supported: Orchestration service configuration, llm_module_config, templating_module_config, filtering_module_config (content safety), grounding_module_config, prompt template variables, model version selection
+  why_needed: Authoritative source for orchestration configuration structure; used to classify missing content safety filters and unguarded template variables
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Generative AI Hub — document grounding
+
+- SAP Generative AI Hub Document Grounding
+  https://help.sap.com/docs/sap-ai-core/generative-ai/document-grounding
+  source_owner: SAP SE
+  topic_supported: Document Grounding Service configuration, vector store creation and scope, data repository types (vector, SharePoint), grounding pipeline ingestion, metadata handling, retrieval configuration
+  why_needed: Defines grounding pipeline architecture; used to classify data classification gaps before ingestion and cross-tenant vector store isolation findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Generative AI Hub — data protection and privacy
+
+- SAP Generative AI Hub Data Protection and Privacy
+  https://help.sap.com/docs/sap-ai-core/generative-ai/data-protection-and-privacy
+  source_owner: SAP SE
+  topic_supported: Prompt data handling, data residency for AI-processed data, personal data in prompts and grounding documents, prompt logging behavior, data retention, right-to-erasure considerations for vectorized data
+  why_needed: Authoritative source for data privacy requirements for Generative AI Hub workloads; used to classify prompt logging and embedding privacy findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Help Portal documentation describes design intent, supported governance controls, and data protection posture for standard AI Core service plans. It does not prove which controls are active in a specific customer's AI Core instance, what data has been ingested into their vector stores, or how their orchestration pipelines are currently deployed. Users must supply orchestration configuration files, role assignment descriptions, grounding pipeline design, or written descriptions for concrete governance assessment.

package/skills/sap/sap-ai-core-generative-ai-hub-governance/references/safety-checklist.md

@@ -0,0 +1,39 @@
+# Safety checklist — SAP AI Core Generative AI Hub Governance
+
+Use before making any finding or recommendation, especially for data privacy and prompt-injection risk findings.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live AI Core deployment, Generative AI Hub orchestration endpoint, vector store, or AI Launchpad session.
+- Do not accept or request AI Core service keys, OAuth tokens, resource group credentials, or BTP service binding secrets.
+- Do not accept or request actual prompt logs, user message history, inference output from production deployments, or grounding document contents. Request only descriptions of data classification and pipeline configuration.
+- Do not accept vector store embeddings or raw grounding data. If the user attempts to share this, redirect them to provide a description of the data types and classification status instead.
+- Do not recommend disabling content safety filters (`filtering_module_config`) as a performance optimization. Missing input or output content safety filters is a high or critical finding.
+- Do not recommend storing prompt logs in a region different from where personal data was collected without advising the user to review applicable data transfer regulations (GDPR Chapter V, local laws).
+- Do not validate data residency compliance from memory alone. Direct the user to verify against the current SAP AI Core data residency documentation for their contracted region.
+- Do not conflate AI Core resource group isolation with BTP subaccount tenant isolation. Resource groups provide workload isolation within a subaccount; cross-tenant isolation requires subaccount-level separation.
+
+## What people get wrong
+
+- **Assuming content safety is on by default**: SAP Generative AI Hub orchestration does not enable content safety filters by default. `filtering_module_config` must be explicitly added to the orchestration configuration for both input and output paths.
+- **Treating grounding output as trusted**: Grounding documents retrieved from a vector store may contain injected content if the ingestion pipeline accepted untrusted external documents. Injected content in `{{ ?groundingOutput }}` can manipulate model behavior (indirect prompt injection). Grounding output is not automatically safe to inject into system messages.
+- **Overlooking right-to-erasure for embeddings**: Once personal data is vectorized and stored in a vector store, deleting the source document does not delete the embedding. A documented erasure procedure for the embedding itself is required to comply with right-to-erasure requests.
+- **Assuming resource group isolation = tenant isolation**: Multiple tenants sharing a single BTP subaccount with different resource groups are not fully isolated. Subaccount-level isolation is needed for full tenant separation of AI workloads.
+- **Ignoring metadata exposure**: When `metadata_params` is configured to return `source` and `webUrl` from grounding retrieval, this information is visible in the orchestration response. Internal URLs, document IDs, or access-controlled source identifiers exposed in responses may constitute an information disclosure finding.
+- **Floating model versions in auditable workflows**: Using `model_version: "latest"` in an orchestration configuration means model behavior can change without notice. For any workflow where AI outputs are used in auditable business decisions, the model version must be pinned and changes must go through a change management process.
+
+## When to push back
+
+- Push back when the user asks to review actual prompt logs or grounding document contents — request a description of the data types and classification status instead.
+- Push back when the user proposes to disable content safety filters to improve response latency on customer-facing pipelines.
+- Push back when the user proposes to use a single shared resource group for multiple application teams with different data access levels.
+- Push back when the user attempts to ingest personal data into a vector store without a documented erasure procedure.
+- Push back when the request requires live AI Core API access or production deployment inspection — this skill is advisory only.
+- Push back when the user proposes logging prompts containing personal data without a documented retention policy and legal basis.
+
+## Evidence labels
+
+- `documentation-based` — grounded in official SAP AI Core, AI Launchpad, or Generative AI Hub documentation (help.sap.com)
+- `user-provided evidence` — orchestration configuration files, role assignment descriptions, grounding pipeline design, data classification documentation, or written descriptions provided by the user
+- `context7-supplementary` — SAP Generative AI Hub orchestration configuration patterns (content safety filter structure, grounding module config) sourced from Context7 (supplementary to official SAP docs)
+- `inference` — derived reasoning not directly confirmed; must always be labeled as such