@raishin/vanguard-frontier-agentic 2.10.0 → 2.13.0

package/skills/sap/sap-guarded-integration-flow-change/references/live-environment-access.md

@@ -0,0 +1,80 @@
+# Live environment access — SAP Guarded Integration Flow Change
+
+This reference defines credential setup, role requirements, command restrictions by step, and audit log format for guarded integration flow change sessions.
+
+## Credential requirements
+
+### SAP Cloud Integration OData API
+
+Required service key scopes for the executing service instance:
+- Step 8 (read-only): `MonitoringDataRead` and `WorkspacePackagesRead`
+- Step 9 (diff, read-only): `WorkspacePackagesRead`
+- Step 14 (deploy, mutating): `WorkspacePackagesConfigure` and `NodeManager.deployer`
+- Step 15 (verify, read-only): `MonitoringDataRead`
+
+Not permitted:
+- `AuthGroup.Administrator` or `AuthGroup.IntegrationDeveloper` with tenant-wide scope for step 14 — scope to the specific package or integration flow
+- Any scope that permits security material configuration (keystore, credential store) unless explicitly in scope and approved
+
+### Integration Suite User (Cockpit access)
+
+Required role collection for the deploying user:
+- **PI_Integration_Developer** for the specific Cloud Integration tenant
+- Not permitted: **PI_Administrator** (grants tenant-level configuration rights beyond deployment)
+- Not permitted: **Integration_Provisioner** (grants capability activation and subscription changes)
+
+### OAuth token handling
+
+- Obtain OAuth tokens via the service key `tokenurl` endpoint with client credentials grant
+- Tokens are short-lived; do not cache or reuse tokens across sessions
+- Never store client ID, client secret, or bearer token values in any output or log entry
+
+## Step-by-step access matrix
+
+| Step | Live system access | Access type | Credential scope |
+|------|--------------------|-------------|-----------------|
+| 1–7 | None | Advisory only | Not applicable |
+| 8 | Cloud Integration OData API | Read-only | MonitoringDataRead + WorkspacePackagesRead |
+| 9 | Cloud Integration Design API | Read-only (diff) | WorkspacePackagesRead |
+| 10–13 | None | Advisory only | Not applicable |
+| 14 | Cloud Integration OData API | Mutating — deploy only | WorkspacePackagesConfigure + NodeManager.deployer |
+| 15 | Cloud Integration OData API / Monitoring API | Read-only | MonitoringDataRead |
+| 16–17 | None | Reporting only | Not applicable |
+
+## Audit log format
+
+Every command executed (steps 8, 9, 14, 15) must be logged before execution:
+
+```
+[INTEGRATION_FLOW_AUDIT_LOG]
+Step: <step number and name>
+Timestamp (UTC): <ISO 8601>
+Tenant: <Cloud Integration tenant ID and sub-domain>
+Tool: <Cloud Integration OData API | Design API | Monitoring API>
+Command/API call: <exact API endpoint and method, credentials omitted>
+Artifact(s) in scope: <artifact IDs and version numbers>
+Output summary: <one-line summary>
+Errors/Warnings: <none | list>
+Redactions applied: <yes/no>
+Approval gate cleared: <yes (step 13 documented) | not yet reached>
+```
+
+## Pre-execution gate checklist (step 13 → step 14)
+
+Before executing any deployment command, all of the following must be true:
+
+- [ ] Step 1: Artifact type and change type classified
+- [ ] Step 2: Target tenant ID, tier, and sub-domain confirmed
+- [ ] Step 3: Criticality level assigned
+- [ ] Step 4: Requester name and role documented
+- [ ] Step 5: Integration owner name, role, and accountability scope documented (different from requester)
+- [ ] Step 6: Change management ticket number confirmed
+- [ ] Step 7: Artifact list with IDs, versions, and dependency map documented
+- [ ] Step 8: Deployed artifact status and message monitoring baseline obtained (live evidence on record)
+- [ ] Step 9: Diff of artifact changes produced and on record
+- [ ] Step 10: Blast radius document confirmed (downstream partners, throughput impact, in-flight message handling)
+- [ ] Step 11: Rollback procedure (specific previous version to redeploy) documented and confirmed feasible
+- [ ] Step 12: SoD confirmed — requester and integration owner / approver are different individuals
+- [ ] Step 13: Explicit written integration-owner approval on record, naming the specific artifact IDs and versions
+
+If any item is unchecked, refuse step 14 execution until it is resolved.

package/skills/sap/sap-guarded-integration-flow-change/references/official-sources.md

@@ -0,0 +1,73 @@
+# Official sources — SAP Guarded Integration Flow Change
+
+Use this reference when grounding SAP Cloud Integration deployment procedures, OData API usage, message monitoring operations, and artifact versioning.
+
+**Evidence level**: documentation-based (SAP Help Portal). Live evidence gathered during steps 8, 9, and 14 is labeled separately as `live evidence` per the audit format in `references/live-environment-access.md`.
+
+## SAP Cloud Integration — Deployment
+
+- SAP Cloud Integration — deploy integration artifacts
+  https://help.sap.com/docs/cloud-integration/sap-cloud-integration/deploy-integration-artifacts
+  source_owner: SAP SE
+  topic_supported: Deployment of iFlows, value mappings, script collections, and API providers to a Cloud Integration runtime; deployment status lifecycle; error states and recovery
+  why_needed: Authoritative source for the deployment procedures used in step 14 and the deployment status inspection used in step 15; defines allowed artifact types for step 1
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Cloud Integration — manage integration content
+  https://help.sap.com/docs/cloud-integration/sap-cloud-integration/manage-integration-content
+  source_owner: SAP SE
+  topic_supported: Integration package and artifact management in the design workspace; undeploy, activate, and deactivate operations; content transport between tenants
+  why_needed: Grounds step 7 (scope documentation) and step 11 (rollback plan) with the exact package management and previous-version redeploy procedures available in Cloud Integration
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Cloud Integration — versioning of artifacts
+  https://help.sap.com/docs/cloud-integration/sap-cloud-integration/versioning-of-artifacts
+  source_owner: SAP SE
+  topic_supported: Artifact versioning in the design workspace, draft vs. active versions, version history, restoring previous versions
+  why_needed: Authoritative source for step 9 (diff of artifact changes between design workspace version and deployed version) and step 11 (rollback via previous version redeploy); defines the versioning model used to produce the change diff
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Cloud Integration — OData API
+
+- SAP Cloud Integration OData API reference
+  https://help.sap.com/docs/cloud-integration/sap-cloud-integration/odata-api
+  source_owner: SAP SE
+  topic_supported: Cloud Integration OData API endpoints — GET IntegrationRuntimeArtifacts (read deployed status), POST deploy, GET MessageProcessingLogs; authentication and service key setup
+  why_needed: Defines the exact API calls permitted for read-only state inspection (step 8), artifact deployment (step 14), and post-deployment verification (step 15); grounds the command patterns in the workflow reference
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Cloud Integration — Message Monitoring
+
+- SAP Cloud Integration — message processing log
+  https://help.sap.com/docs/cloud-integration/sap-cloud-integration/message-processing-log
+  source_owner: SAP SE
+  topic_supported: Message processing log (MPL) structure, status values (Completed / Failed / Retry / Escalated), log levels, correlation IDs, attachment inspection
+  why_needed: Grounds step 15 (post-deployment verification via message monitoring); defines the status values and log structure used to confirm successful processing after deployment
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Cloud Integration — monitor message processing
+  https://help.sap.com/docs/cloud-integration/sap-cloud-integration/monitor-message-processing
+  source_owner: SAP SE
+  topic_supported: Message monitoring cockpit, monitoring tile navigation, filtering by integration flow and time range, throughput analysis
+  why_needed: Provides the monitoring procedures for step 8 (read-only current state — error rate baseline) and step 15 (post-deployment verification — throughput resume confirmation)
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Integration Suite — Capabilities and Roles
+
+- SAP Integration Suite — activating and managing capabilities
+  https://help.sap.com/docs/integration-suite/sap-integration-suite/activating-and-managing-capabilities
+  source_owner: SAP SE
+  topic_supported: Integration Suite capability activation, role collection assignments for Cloud Integration, API Management, and Event Mesh; least-privilege role guidance
+  why_needed: Grounds step 5 (integration owner identification) and the least-privilege credential rules in live-environment-access.md; defines the Integration Developer and Integration Suite roles required for deployment operations
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Help Portal documentation describes Cloud Integration deployment design intent, OData API specifications, and monitoring architecture. It does not prove which artifacts are currently deployed in the user's tenant, what the current message processing error rate is, or whether downstream partner systems are reachable from the target tenant. Users must supply live evidence from steps 8, 9, and 15 for concrete integration state assessment.

package/skills/sap/sap-guarded-integration-flow-change/references/safety-checklist.md

@@ -0,0 +1,56 @@
+# Safety checklist — SAP Guarded Integration Flow Change
+
+Use before every step and unconditionally before step 14 execution.
+
+## Non-negotiables
+
+- Do not reach step 14 (execute) without documented integration-owner approval on record in this session.
+- Do not allow self-approval. The requester (step 4) and the integration owner / approver (step 5) must be different individuals. If they are the same, refuse execution.
+- Do not deploy artifacts not on the approved list from step 7.
+- Do not deploy any artifact for which a diff (step 9) has not been produced and reviewed.
+- Do not skip or reorder steps. The sequence is mandatory.
+- Do not use Integration Suite tenant administrator credentials. Use an Integration Developer role scoped to the specific tenant.
+- Do not accept, log, echo, or include Cloud Integration service key credential values, OAuth client secrets, or process integration runtime user passwords in any output.
+- Do not attempt self-recovery deployments without initiating a new 17-step sequence.
+- Do not deploy to a production tenant without a documented rollback plan that identifies the specific previous version to redeploy (step 11).
+- Do not ignore ERROR or RETRY status messages in post-deployment monitoring (step 15). Assess every failure before closing the session.
+
+## What people get wrong
+
+- **Treating verbal integration-owner approval as sufficient**: Step 13 requires explicit written approval documented in the session. Verbal or assumed approval does not clear the gate.
+- **Skipping the diff because the change seems minor**: Step 9 is mandatory. Minor-looking changes (e.g., a single script step update) can affect routing behavior, adapter retry configuration, or security material references in ways that only a diff reveals.
+- **Assuming QA tenant deployments are low risk**: QA tenants often connect to external partner test systems with real data and SLAs. The full sequence applies.
+- **Batching multiple iFlow deployments without per-artifact diff**: Each iFlow must have its own diff documented in step 9. Batching without per-artifact review is forbidden.
+- **Using the wrong role for deployment**: The deploying user must have the Integration Developer role for the specific tenant. A tenant administrator role is over-privileged.
+- **Not accounting for message-in-flight impact during deployment**: Deploying an iFlow while messages are being processed can cause message loss or duplication. The blast radius assessment in step 10 must address in-flight message handling.
+- **Treating a WARNING in message monitoring as a pass**: WARNING or RETRY status in message processing logs can indicate transient failures that persist. Step 15 must assess every non-Completed status before the session is closed.
+- **Not identifying downstream partner impact**: The blast radius (step 10) must name every external partner system, API consumer, and dependent iFlow. An iFlow change that alters a message structure or endpoint URL is a breaking change for downstream partners.
+
+## When to push back
+
+- Push back when the user asks to "just deploy it" without completing prior steps.
+- Push back when the requester and integration owner are the same person.
+- Push back when no change management ticket number is provided.
+- Push back when a diff of artifact changes has not been produced.
+- Push back when the rollback plan is "we'll redeploy if something goes wrong" without naming the specific version to restore.
+- Push back when the target is a production tenant and no blast radius covering downstream partners has been documented.
+- Push back when step 15 message monitoring shows ERROR or RETRY status and the user wants to close the session without assessment.
+- Push back when the user provides a credential with tenant administrator scope instead of Integration Developer scope.
+
+## Evidence labels
+
+- `live evidence` — directly observed from a live Cloud Integration tenant; include API endpoint, response summary, timestamp, tenant ID
+- `documentation-based` — grounded in SAP official docs; no live access
+- `user-provided evidence` — stated, uploaded, or confirmed by the user in this session
+- `inference` — derived reasoning; must always be labeled as such
+
+## SoD verification matrix
+
+| Role | Can request? | Can approve? |
+|------|-------------|-------------|
+| Integration developer | Yes | No |
+| Functional consultant | Yes | No |
+| Integration owner (accountable for iFlow and downstream partners) | No | Yes |
+| Delivery lead / project manager | No | Yes (for non-production tenants; integration owner required for production) |
+| Requester and approver in same person | No — SoD violation | Refuse execution |
+| Automated CI/CD pipeline without human integration-owner approval | No | Refuse — human integration-owner approval required for production |

package/skills/sap/sap-guarded-integration-flow-change/references/workflow-and-output.md

@@ -0,0 +1,122 @@
+# Workflow and output contract — SAP Guarded Integration Flow Change
+
+Use this reference for all step-by-step execution, command patterns, and output formatting.
+
+## Step execution protocol
+
+For each of the 17 steps, the following must be true before advancing to the next:
+
+1. The step's required evidence is on record in this session.
+2. The user has confirmed the evidence is accurate.
+3. Any step-specific gate (e.g., integration-owner approval, SoD check) has been explicitly cleared.
+
+If any of these conditions is false, the session pauses at the current step until resolved.
+
+## Command patterns by step
+
+### Step 8 — Read-only current state
+
+#### Cloud Integration OData API (read — deployed artifact status)
+```
+GET https://{tenant}.it-cpi{N}.cfapps.{region}.hana.ondemand.com/api/v1/IntegrationRuntimeArtifacts
+  (returns all deployed iFlows with version and status)
+
+GET https://{tenant}.it-cpi{N}.cfapps.{region}.hana.ondemand.com/api/v1/IntegrationRuntimeArtifacts('{artifactId}')
+  (returns status: STARTED | ERROR | STOPPING for a specific artifact)
+```
+
+#### Cloud Integration Monitoring API (read — message processing)
+```
+GET https://{tenant}.it-cpi{N}.cfapps.{region}.hana.ondemand.com/api/v1/MessageProcessingLogs
+  ?$filter=IntegrationFlowName eq '{iFlowName}' and Status eq 'FAILED'
+  &$orderby=LogStart desc&$top=20
+  (returns recent error messages as baseline for step 15 comparison)
+```
+
+### Step 9 — Diff of artifact changes
+
+#### Cloud Integration Design API (read — retrieve current design workspace version)
+```
+GET https://{tenant}.it-cpi{N}.cfapps.{region}.hana.ondemand.com/api/v1/IntegrationDesigntimeArtifacts(Id='{artifactId}',Version='active')/$value
+  (download current active design workspace version for diff comparison)
+
+GET https://{tenant}.it-cpi{N}.cfapps.{region}.hana.ondemand.com/api/v1/IntegrationDesigntimeArtifacts(Id='{artifactId}',Version='active')
+  (returns artifact metadata including version, description, and last modified timestamp)
+```
+
+Document in the diff:
+- Changed iFlow steps (adapters, routing conditions, content modifier, script steps)
+- Changed adapter configurations (endpoint URLs, authentication methods, retry settings)
+- Changed value mappings or external parameters
+- Changed security material references
+- Version number delta: deployed version → proposed version
+
+### Step 14 — Execute approved deployment
+
+#### Cloud Integration OData API (mutating — step 14 only, after step 13 gate is cleared)
+```
+POST https://{tenant}.it-cpi{N}.cfapps.{region}.hana.ondemand.com/api/v1/DeployIntegrationDesigntimeArtifact
+  ?Id='{artifactId}'&Version='{version}'
+  Body: (empty for standard deploy; artifact must be in active workspace state)
+```
+
+#### Undeploy (only when change type from step 1 is undeploy and explicitly approved)
+```
+DELETE https://{tenant}.it-cpi{N}.cfapps.{region}.hana.ondemand.com/api/v1/IntegrationRuntimeArtifacts('{artifactId}')
+```
+
+**Never call POST deploy or DELETE undeploy before step 13 approval gate is documented.**
+
+### Step 11 — Rollback (previous version redeploy)
+
+#### Cloud Integration — restore previous version
+```
+1. Navigate to: Integration Suite → Cloud Integration → Design → locate package
+2. Select artifact → Version History → identify last known good version
+3. Activate previous version in design workspace
+4. Execute step 14 pattern (POST deploy) with the previous version ID
+
+OData API equivalent:
+PUT https://{tenant}.it-cpi{N}.cfapps.{region}.hana.ondemand.com/api/v1/IntegrationDesigntimeArtifacts(Id='{artifactId}',Version='{previousVersion}')
+  (restore previous version to active) — then POST deploy as per step 14
+```
+
+## Step completion checklist
+
+| Step | Evidence type | Completion marker |
+|------|--------------|------------------|
+| 1 | user-provided / documentation-based | Artifact type and change type confirmed |
+| 2 | user-provided evidence | Target tenant ID, tier, and sub-domain confirmed |
+| 3 | user-provided evidence | Criticality level assigned |
+| 4 | user-provided evidence | Requester name and role on record |
+| 5 | user-provided evidence | Integration owner name, role, and accountability scope on record |
+| 6 | user-provided evidence | Ticket number confirmed |
+| 7 | user-provided evidence | Artifact list with IDs, versions, and dependency map on record |
+| 8 | live evidence | Deployed artifact status and message monitoring baseline from target tenant |
+| 9 | live evidence | Diff of artifact changes documenting changed components |
+| 10 | user-provided / inference | Blast radius document confirmed (downstream partners, throughput impact) |
+| 11 | user-provided evidence | Rollback procedure (previous version redeploy) confirmed feasible |
+| 12 | user-provided evidence | SoD confirmed: requester ≠ integration owner / approver |
+| 13 | user-provided evidence | Explicit integration-owner approval statement on record |
+| 14 | live evidence | Deployment command log with timestamp |
+| 15 | live evidence | Message monitoring verification — no new errors; throughput confirmed |
+| 16 | all of the above | Audit record compiled |
+| 17 | user-provided evidence | Report delivered and acknowledged |
+
+## Output contract
+
+Return after each step:
+
+1. Step number and name
+2. Evidence gathered for this step (labeled by evidence type)
+3. Gate status: cleared / pending / blocked
+4. Next step and what is needed to advance
+5. Refusal marker if any gate condition is unmet (do not advance)
+
+Return after step 17:
+
+1. Complete audit record (all 17 steps with evidence and timestamps)
+2. Final deployment status (success / partial / failed)
+3. Post-deployment message monitoring result (error count, throughput status, partner acknowledgements)
+4. Rollback status (not needed / standing by / triggered)
+5. Report delivery confirmation

package/skills/sap/sap-guarded-role-assignment/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: sap-guarded-role-assignment
+description: Assign or revoke SAP role collections and authorizations using a mandatory 17-step guarded mutation sequence covering classification, target tenant/system confirmation, criticality, requester, approver, ticket, scope, read-only current state, SoD pre-check, diff of effective permissions, blast radius, rollback plan, approval gate, execute approved changes only, verify, audit, and report. Refuses if any step is missing, if an SoD conflict is detected, or if self-approval is attempted. Use when a confirmed and approved role assignment or revocation in a non-development SAP system must be executed under traceable controls.
+allowed-tools: Read Grep Glob WebSearch WebFetch Bash
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: security
+  lifecycle: experimental
+  execution_tier: mutating-runtime
+---
+
+# SAP Guarded Role Assignment
+
+## Purpose
+
+Assign or revoke SAP role collections and authorizations in non-development systems under a strict 17-step guarded mutation sequence. Every step must be completed, documented, and confirmed before the execution step is reached. If any step is absent, the assignment or revocation is refused until it is completed. This skill treats every role assignment or revocation in a quality, pre-production, or production SAP system as a risk-critical mutating operation requiring explicit approval, a mandatory SoD pre-check, and a documented rollback path.
+
+SoD violations are a hard stop: if the proposed assignment would create a Segregation of Duties conflict, the assignment is refused regardless of who approves it. No role is granted for convenience, expediency, or "temporary access" without completing the full sequence.
+
+## When to use
+
+Use this skill when:
+
+- a user, service account, or group must be granted or have revoked one or more SAP role collections, composite roles, or single authorization objects in a quality, pre-production, or production system,
+- a security owner or compliance officer has confirmed the change is approved and requires traceable execution,
+- post-change verification and audit evidence are required for compliance, audit, or access review purposes,
+- the user needs a structured, risk-controlled execution protocol for SAP BTP role collections, S/4HANA PFCG roles, or cloud-service authorization management.
+
+## When not to use
+
+- When the target is a development system (DEV) with no business data — development role assignments do not require this full sequence, though SoD checks remain good practice.
+- When the user wants to *review* or *audit* existing role assignments without making changes — advise on the sequence but do not reach the execution step.
+- When any of the 17 steps cannot be completed — refuse execution until all steps are resolved.
+- When no explicit approval from an authorized approver has been obtained — refuse execution.
+- When the proposed assignment would create an SoD conflict — refuse execution entirely; do not proceed even with approval.
+
+## Lean operating rules
+
+- 17 steps, no shortcuts. The sequence is mandatory and must be completed in order. Steps cannot be skipped or reordered.
+- Refuse before step 13. Never reach the execution step (step 14) without a documented approval from an authorized approver on record in this session.
+- SoD pre-check is mandatory. Step 9 (SoD pre-check / diff of effective permissions) must be completed before any assignment is proposed. An assignment that creates an SoD conflict is refused unconditionally — approval does not override an SoD violation.
+- Segregation of duties enforced. The person who requests the role change (step 4) must not be the same person who approves it (step 12). If SoD is violated, refuse execution.
+- Read current state before any change. Step 8 (read-only current state) must be completed before any assignment is proposed. Do not propose a change on undocumented current access state.
+- Diff effective permissions before live execution. Step 9 must include a diff of effective permissions the user will hold after the change. Undocumented net-new permissions are a refusal trigger.
+- Blast radius documented before execution. Step 10 must list all business processes, transactions, and data objects that will become accessible. Assignments with undocumented blast radius are refused.
+- One user/group change at a time. Do not batch-assign roles to multiple users in a single execution step unless each has completed its own full 17-step sequence.
+- Never hardcode credentials. All system access uses pre-configured service users, API service keys, or SSO tokens — never credentials in plain text.
+- Evidence labeling mandatory. Every step must produce labeled evidence before the next step proceeds.
+- Never grant broad admin for convenience. Never assign SAP_ALL, Administrator role collections, or unrestricted authorization profiles as a workaround for missing fine-grained roles.
+
+## The 17-step guarded mutation sequence
+
+| Step | Name | Description | Evidence required |
+|------|------|-------------|-------------------|
+| 1 | Classify | Classify the role change type (assign / revoke), role type (BTP role collection, PFCG composite role, single authorization object, cloud service entitlement), and scope (user, group, service account) | Role change type, role type, and scope documented |
+| 2 | Confirm target | Confirm the exact target system (BTP subaccount/tenant, S/4HANA SID + client, cloud service instance, environment tier: QA/PPD/PRD) | Target system, subaccount/client, and tier confirmed by user |
+| 3 | Criticality assessment | Assess business criticality of the roles being assigned or revoked (financial posting, payment execution, payroll, system administration, integration platform access, compliance-relevant data) | Criticality level: low/medium/high/critical |
+| 4 | Requester confirmation | Confirm the name, role, and authorization of the change requester | Requester name and role documented |
+| 5 | Approver identification | Identify the authorized approver (security owner or compliance officer — different person from requester — SoD requirement) | Approver name, role, and authorization level |
+| 6 | Ticket linkage | Link the role change to a change management or access request ticket (ITSM reference: ServiceNow, Remedy, SAP Cloud Identity Access Governance, GRC access request, etc.) | Ticket number confirmed |
+| 7 | Scope documentation | Document the complete list of roles, role collections, or authorization objects to be assigned or revoked, including the target user(s) or group(s) and the validity period | Role list with descriptions, target user/group, and validity period |
+| 8 | Read-only current state | Read the current role assignments for the target user(s) or group(s): current role collections, assigned PFCG roles, active authorization objects, last access review date | Live evidence from target system (read-only) |
+| 9 | SoD pre-check and diff | Run a Segregation of Duties pre-check against the proposed assignment; produce a diff of effective permissions the user will hold after the change; document any SoD conflicts found — refuse if any conflict exists | SoD pre-check result (pass/fail) and effective-permission diff |
+| 10 | Blast radius | Document all transactions, business objects, data sets, and business processes that will become accessible (for assignment) or inaccessible (for revocation) after the change | Blast radius document with affected access scope |
+| 11 | Rollback plan | Document the explicit rollback procedure: which roles to revoke or reassign, validity-period reversion, or restore-from-snapshot path | Rollback procedure documented and confirmed feasible |
+| 12 | SoD verification | Verify that requester (step 4) and approver (step 5) are different authorized individuals; confirm no self-approval; confirm SoD pre-check from step 9 returned no conflicts | SoD confirmed: requester ≠ approver; SoD pre-check passed |
+| 13 | Approval gate | Obtain explicit written approval from the authorized approver for this specific role assignment or revocation | Approval statement on record in this session |
+| 14 | Execute approved change | Execute the role assignment or revocation for approved roles only, for approved users or groups only, within the documented validity period | Execution log with timestamp |
+| 15 | Verify | Verify post-change state: confirm role assignments are active, run effective-permission check, confirm business process access matches expectations, confirm no unintended SoD conflicts introduced | Post-change log and verification results |
+| 16 | Audit | Produce complete audit record: all 17 steps, evidence, commands, timestamps, approvals, SoD pre-check result | Audit record |
+| 17 | Report | Deliver final report to requester, approver, security owner, and compliance team | Report delivered and acknowledged |
+
+## Evidence rules
+
+Label all data with one of:
+
+- `live evidence` — directly observed from a live SAP system in this session (include command, output summary, timestamp)
+- `documentation-based` — grounded in SAP official docs
+- `user-provided evidence` — stated or supplied by the user in this session
+- `inference` — derived reasoning not directly confirmed by live data or official docs; must always be labeled
+
+## Live-environment rules
+
+**Allowed** (step 8 only — read-only current state):
+- BTP cockpit or BTP APIs: GET role collection assignments for user or group (read-only)
+- S/4HANA PFCG display (transaction PFCG in display mode, SU01 display)
+- SAP Cloud Identity Services (IAS/IPS) GET user role assignments
+- SAP GRC / Cloud Identity Access Governance: GET current access assignments and SoD risk report
+
+**Allowed** (step 9 only — SoD pre-check and diff):
+- SAP GRC Access Control or Cloud Identity Access Governance: SoD risk simulation for proposed roles
+- BTP role collection effective-permission diff (read-only API calls)
+- PFCG authorization trace (read-only simulation mode)
+
+**Allowed** (step 14 only — after all prior steps confirmed):
+- BTP cockpit or BTP API: POST/PUT role collection assignment for approved users or groups
+- S/4HANA SU01 or PFCG: role assignment execution for approved users
+- SAP Cloud Identity Services: group or role assignment for approved service accounts
+
+**Forbidden** (all other contexts):
+- Any assignment or revocation command before step 13 approval gate is cleared
+- Any assignment of roles not on the approved list from step 7
+- Any assignment that produces an SoD conflict identified in step 9, regardless of approval
+- Any grant of SAP_ALL, Administrator role collections, or unrestricted authorization profiles
+- Any modification to role definitions or authorization object values (this skill covers assignment only, not role design)
+- Any self-approval (requester = approver)
+- Any system access with basis administrator or tenant administrator credentials not scoped to role assignment only
+
+**Least-privilege credential rules**:
+- BTP: use a user with User and Role Administrator role collection scoped to the specific subaccount only; not Global Account Administrator
+- S/4HANA: use a user with authorization for SU01 (user maintenance) and PFCG (role assignment) scoped to the target client only; not SAP_ALL or BASIS profile
+- SAP Cloud Identity Services (IAS/IPS): use a service account with User Administrator scope for the specific tenant; not Tenant Administrator with system configuration rights
+- SAP GRC / Cloud IAG: use a risk analyst or access request processor role scoped to the relevant business unit; not GRC system administrator
+
+**Approval gate (step 13)**:
+Before step 14 execution, confirm:
+1. All steps 1–12 are documented and evidence is on record.
+2. The approver from step 5 has provided explicit written approval in this session.
+3. The approver is a different person from the requester.
+4. The SoD pre-check from step 9 returned no conflicts.
+5. The approval explicitly names the roles and the target user(s) or group(s).
+
+**Rollback**:
+- The rollback plan from step 11 must be documented before step 14 begins.
+- If post-change verification (step 15) reveals unintended access or SoD conflicts, stop immediately and execute the rollback plan before escalating to the approver.
+- Do not attempt self-recovery without a new 17-step sequence.
+
+**Post-change (step 15)**:
+- Run an effective-permission check for the target user after the assignment.
+- Confirm the user can access only the intended transactions and business objects.
+- Run a second SoD check to confirm no conflicts were introduced.
+- Document the verification result as `live evidence`.
+
+**Audit (step 16)**:
+- Produce a complete record of all 17 steps, evidence gathered, commands executed, timestamps, SoD pre-check result, approval statement, and verification results.
+- Retain audit record for the session and deliver to the approver, security owner, and compliance team.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — 17-step execution details, command patterns, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, SoD rules, refusal triggers.
+- [Official sources](references/official-sources.md) — SAP BTP role collections, PFCG, IAS/IPS, GRC docs.
+- [Live environment access](references/live-environment-access.md) — credential setup, role requirements, audit log format.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: role change type (assign/revoke), role type, target system, and environment tier.
+- **Evidence used**: live evidence (with command log) / documentation-based / user-provided / inference.
+- **Risk level**: always risk-critical for non-development targets; critical for any financial, payroll, or system-administration role.
+- **Recommended action**: current step in the 17-step sequence and what is needed to advance.
+- **Refusal / escalation triggers**: refuse if approval gate not cleared; refuse if SoD violation detected (step 9 or step 12); refuse if self-approval attempted; refuse if any step is missing; refuse if rollback plan is absent; refuse if broad admin role requested.
+- **Business impact**: what access changes if the assignment succeeds; what business processes are affected if the revocation is unintended.
+- **Next verification step**: which step number is next and what evidence is required.

package/skills/sap/sap-guarded-role-assignment/agents/openai.yaml

@@ -0,0 +1,17 @@
+interface:
+  display_name: "SAP Guarded Role Assignment"
+  short_description: "Assign or revoke SAP role collections and authorizations under a mandatory 17-step guarded mutation sequence — refuses if any step is missing, SoD conflict detected, or approval gate not cleared"
+  default_prompt: "Use $sap-guarded-role-assignment to assign or revoke SAP role collections or authorizations. Begin at step 1 (classify) and advance through all 17 steps in order. Do not reach step 14 (execute) without a documented approval from an authorized approver who is different from the requester. Refuse if any step is skipped, if an SoD conflict is detected in step 9, if SoD is violated in step 12, or if a rollback plan is absent. Never grant broad admin roles for convenience."
+dependencies:
+  tools:
+    - type: "api"
+      value: "sap-btp-security-api"
+      description: "SAP BTP Security API — GET role collection assignments for read-only state (step 8), POST/PUT role collection assignment for approved users or groups (step 14) using User and Role Administrator scope only"
+    - type: "api"
+      value: "sap-cloud-identity-services"
+      description: "SAP Cloud Identity Services (IAS/IPS) API — GET user role assignments (step 8), POST group or role assignment for approved service accounts (step 14)"
+    - type: "cli"
+      value: "pfcg-su01"
+      description: "SAP PFCG and SU01 transactions — display mode for read-only current state (step 8), role assignment execution for approved users in S/4HANA (step 14) using scoped authorization only"
+policy:
+  allow_implicit_invocation: false

package/skills/sap/sap-guarded-role-assignment/metadata.json

@@ -0,0 +1,33 @@
+{
+  "id": "sap-guarded-role-assignment",
+  "name": "SAP Guarded Role Assignment",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Assign or revoke SAP role collections and authorizations in quality, pre-production, or production systems using a mandatory 17-step guarded mutation sequence: classify, confirm target, criticality, requester, approver, ticket, scope, read-only current state, SoD pre-check and diff of effective permissions, blast radius, rollback, SoD verification, approval gate, execute approved changes only, verify, audit, report. Refuses if any step is missing, if an SoD conflict is detected, or if self-approval is attempted.",
+  "source_type": "original",
+  "category": "security",
+  "official_docs": [
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/role-collections-and-roles-in-global-accounts-directories-and-subaccounts",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/assign-role-collections-to-users-or-user-groups",
+    "https://help.sap.com/docs/SAP_NETWEAVER_750/6dae0b55c6264f94b4e7e5f2e696d5d2/4a31e3fd18b44f7e9e3d2c16cdcd5e31.html",
+    "https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/manage-users",
+    "https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/manage-groups",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/security-in-the-cloud-foundry-environment",
+    "https://help.sap.com/docs/SAP_ACCESS_CONTROL/a44f200cb83c4f0fa06c50c73e67e7c8/e5c4e14d9f804a53a1baa2f8d4e12c87.html"
+  ],
+  "security_notes": "Mutating operations are gated behind the 17-step sequence. Never execute a role assignment or revocation before step 13 approval gate is cleared. Never accept self-approval (SoD: requester must differ from approver). Never assign roles that produce an SoD conflict identified in the step 9 pre-check — approval does not override an SoD violation. Never grant SAP_ALL, Administrator role collections, or unrestricted authorization profiles. Never use tenant administrator or global account administrator credentials — use the minimum scope required for user and role management in the specific target subaccount or system. Never hardcode or accept service keys, OAuth tokens, or ABAP logon passwords in plain text. Refuse any request to skip steps.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-guarded-role-assignment",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental",
+  "execution_tier": "mutating-runtime"
+}