Skip to content

Deterministic Compliance Middleware for SAP Cloud SDK (Optional Module) #215

Description

@Thilaknath

Describe the Problem

The SAP Cloud SDK for Python ships the building blocks for AI agents, agent_decorators, agentgateway, AI Core auth, OTLP telemetry, but lacks compliance gate. Every agent built on the SDK today reaches an LLM and calls tools with no deterministic control point between "model decided to act" and "action executes."

Concretely, an SDK-built agent today can:

  • Invoke a tool the deployer never intended to expose.
  • Ship to production with no per-decision audit record traceable to an operator-authored rule.
  • Ship with no technical documentation artifact that maps to EU AI Act Article 11 (Annex IV) obligations.

The above cited is a missing layer. Under the EU AI Act, any agent classified Annex III (essential services, employment, credit, law enforcement, education) is high-risk. High-risk
Systems need: Article 9 risk management, Article 10 data governance, Article 12 automatic logging of decisions, Article 14 human oversight,
Article 15 accuracy + robustness + cybersecurity, and Article 11 technical documentation before market entry.

The SDK has no primitive to help teams meet any of those obligations, so every agent development team have to re-implements the same middleware from scratch.

Regulators require the policy that gated a decision to be inspectable, versionable, and reproducible against the same input. Only rule-based, deterministic evaluation clears that bar.

Without this primitive in the SDK, every team building an agent on top faces a choice: ship ungated, or invent their own compliance stack.

Propose a Solution

Summary

Introduce a Compliance module in the SAP Cloud SDK, shipped as an optional extra so the base installation remains lightweight.

The module would provide a single, deterministic middleware for evaluating agent actions against deployer-defined compliance policies.

Proposed API

from sap_cloud_sdk.compliance import SAPComplianceMiddleware

middleware = SAPComplianceMiddleware.from_paths(
    agent_name="my-agent",
    policy_file="policies/my-agent.yaml",
    profile_file="policies/profile-my-agent.yaml",
    fail_closed=True,
)

decision = middleware.evaluate(
    prompt,
    action="tool:x",
    tool_args={...},
)

if not decision.allowed:
    raise PermissionError(decision.reason)

Key Capabilities

  • Deterministic policy evaluation using deployer-authored YAML rules.
  • Author-time policy definition, runtime deterministic enforcement.
  • Per-decision audit records integrated into the SDK's existing telemetry and audit pipeline.
  • Deployer-authored Agent Profile (YAML) that can be used to generate Annex IV Technical Documentation.
  • CI-friendly, byte-deterministic artifacts to support drift detection and governance.

Why Determinism Matters

For compliance-sensitive AI systems, the same:

  • Prompt
  • Action
  • Tool arguments

must always produce the same decision, regardless of runtime instance or deployment replica.

When auditors ask:

"Why did the agent perform action X on Tuesday?"

the answer should always be:

  • Policy Version
  • Rule ID
  • Audit Record

—not:

"The model decided differently."

Deterministic enforcement makes regulatory investigations reproducible, explainable, and auditable.


Describe Alternatives

Alternatives Considered

1. Keep compliance middleware outside the SDK

Current approach

Every Line of Business implements its own compliance middleware.

Drawbacks

  • Multiple incompatible implementations
  • No shared audit integration
  • No shared telemetry integration
  • No standard Annex IV artifact generation
  • Increased maintenance across teams

2. Ship as a separate SAP package

Example:

sap-agent-compliance

Rejected

Agents already depend on the SDK for:

  • AI Core
  • Telemetry
  • Authentication
  • Common infrastructure

Introducing a second SAP package for the mandatory compliance layer creates unnecessary dependency and adoption friction.

Optional SDK extras are a more natural fit.


3. Use non-deterministic policy gates

Examples:

  • LLM-as-a-Judge
  • Learned classifiers
  • AI moderation models

Rejected

Compliance decisions must be reproducible.

A policy engine whose output changes for identical inputs cannot reliably support auditability or regulatory investigations.

For regulated AI systems, deterministic policy evaluation provides a stronger foundation for reconstructable decision-making and consistent governance.

Affected Development Phase

Development

Impact

Inconvenience

Timeline

I already have a working implementation for a mock-agent that demonstrates this approach.

The implementation includes:

  • SDK Module Registry integration
  • @record_metrics integration
  • Audit log integration following the existing auditlog_ng shape
  • py.typed support
  • Per-module documentation (user-guide.md)
  • 40 automated tests
  • 93% test coverage
  • Ruff clean
  • Ty clean
  • pytest-bdd integration scenarios
  • DCO signed

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions