Skip to main content
SAP Pentest Playbook
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  2. /
  3. SAP Business Technology Platform
  4. /
  5. Known Attack Vectors
  6. /
  7. SAP AI Core / Generative AI Hub
Edit page

SAP AI Core / Generative AI Hub

Description

SAP AI Core runs customer-supplied workloads (Argo/Kubeflow pipelines) and binds them to a customer-registered object store (S3/GCS/Azure Blob). It concentrates two things a tester cares about: arbitrary-code execution capability (who can create executions/deployments) and standing credentials (service keys, object-store secrets, any hyperscaler keys placed in a workload’s own config). Generative AI Hub sits on the same AI Core substrate.

Risk

A weakness in who can create, read, or trigger AI Core objects turns into code execution inside the tenant’s AI runtime, or credential access one layer down into the customer’s hyperscaler account. Because the service is newer, it is frequently deployed with default-broad role assignments and unrotated secrets.

Options

  • Execution and standing credentials (not secret read-back): AI Core binds workloads to a customer-registered object store whose credentials are supplied as an object store secret created via the AI API (POST .../v2/admin/objectStoreSecrets). These are write-only - the read/list endpoints return metadata only (name, type, bucket, endpoint, region, path prefix); the secret’s data field is never returned, so a service key does not read the stored hyperscaler keys back in cleartext. Secrets are scoped per resource group (AI-Resource-Group header; default if unspecified). The realistic tests are therefore:
    • (a) who can create AI Core executions/deployments - tight role-collection scoping on the aicore service is what gates arbitrary-code capability;
    • (b) whether long-lived hyperscaler credentials were placed in a workflow’s own environment/config - a standing set of cloud-account keys, one layer below BTP;
    • (c) grep CI/notebooks/repos for a leaked AI Core service-key clientsecret.

Mitigation

  • Tightly scope the role collections that can create executions/deployments on the aicore service.
  • Never place long-lived hyperscaler credentials in a workflow’s own environment; scope object-store IAM to a dedicated least-privilege prefix.
  • Rotate service keys; scan repos/CI for leaked clientsecret values.

Detection and Monitoring

  • Audit-log the creation of AI Core executions/deployments and service keys.
  • Alert on unusual outbound egress from workloads where a BYO/Kyma-style runtime exposes it.
  • Subject to the BTP Audit Log’s coverage limits - see BTP Audit Blind Spots.

References