A sanctioned pathway for AI agents accessing enterprise data.

Executive summary

In April 2026, SAP published version 4.2026a of its API Policy.^[1] Section 2.2.2 prohibits API use for "interaction or integration with (semi-) autonomous or generative AI systems that plan, select, or execute sequences of API calls" — except through SAP-endorsed architectures, data services, or service-specific pathways. That definition of an agent captures essentially every AI tool currently being deployed against enterprise data.

AegisAI uses no LLMs, no ML models, and no probabilistic classifiers in the request path. Every deny decision is reproducible from inputs. The "AI" in the name refers to the AI agents calling AegisAI from the other side of the gate; AegisAI itself is deterministic Python. See §2.1.

For the SAP-customer side of the market, this is not a future problem. Microsoft Copilot, Joule, internal RAG pipelines, and the long tail of AI agents accessing SAP data must now route through a sanctioned interface or stop. There is no third option.

AegisAI is that interface. It sits between AI agents and SAP (and AWS, Azure, GCP) data systems, applying nine deterministic stages to every request: rate-limiting, request-ceiling enforcement, JWT authentication, identity propagation to SAP (SAP is the sole authorisation arbiter — see §3.4 and ADR 0002), adaptive trust evaluation, deterministic policy, parameterised query planning, schema-driven response masking, and a tamper-evident HMAC audit chain.

This whitepaper covers, in order:

• §1. The policy moment and what 4.2026a actually says.
• §2. Design invariants AegisAI was built against.
• §3. The nine-stage request pipeline, stage by stage.
• §4. Threat model: what we mitigate and how.
• §5. Mapping AegisAI to the policy's four preamble goals.
• §6. Pilot path and commercial deployment models.
• §7. Honest residuals and detection limits — the 6% we haven't delivered, and the patterns AegisAI does not catch.
• §9. References.

A reader interested only in the architecture can start at §3. A reader doing diligence should read end to end.

The one-line framing. AI can assist SAP. It is not meant to run SAP. AegisAI is the layer that keeps that distinction enforceable: it lets agents analyse, support decisions, and trigger defined API interactions — while structurally preventing the autonomous plan-select-execute sequences §2.2.2 forbids.

Architectural convergence. During Q1-Q2 2026 the SAP-architect community began publishing reference diagrams for "AI Control & Mediation Layers" sitting between agentic AI orchestrators and SAP business systems. The independently-drawn pattern includes the same layers AegisAI shipped: AI Gateway / Agent Interface, Policy Enforcement (RBAC, scope, throttling, usage control), Orchestration & Guardrails (intent validation, business rules, safety checks), Observability & Audit, and AI Services. AegisAI is not the only credible answer in this shape, but it is one of the first production-grade implementations of it.

1. The policy moment

1.1 What SAP API Policy 4.2026a actually requires

The load-bearing sentence is Section 2.2.2:^[1]

"Except through and within the limits of SAP-endorsed architectures, data services, or service-specific pathways expressly identified and intended for such purposes, SAP prohibits API use for: (a) interaction or integration with (semi-) autonomous or generative AI systems that plan, select, or execute sequences of API calls, and (b) scraping, harvesting, or systematic and/or large-scale data extraction or replication."

Two things to notice. First, the prohibition is on direct AI agent access and on bulk extraction. Second, the carve-out is broad: a "SAP-endorsed architecture" is one of three valid shapes, alongside SAP-built data services and SAP-built service-specific pathways. AegisAI fits the architecture leg — a sanctioned control plane that any agent can use without SAP having to ship per-vendor pathways.

The policy also defines an "agent" with unusual precision — "(semi-)autonomous or generative AI systems that plan, select, or execute sequences of API calls". That definition is wide enough to cover Microsoft Copilot, SAP Joule, custom RAG pipelines, internal LLM-driven automations, and most production AI tooling against SAP today. If your AI plans, selects, or executes sequential calls, it is an agent under SAP's own framing — and Section 2.2.2 applies.

1.2 The policy's four preamble goals

The policy preamble names four things its controls are designed to do:^[1]

"...controls designed to safeguard solution health and security, promote equitable access, prevent API misuse, and support the enforcement of this API Policy."

All four are tractable with a properly-architected control plane. AegisAI was designed against these specific concerns — not around them. §5 maps each to a shipping capability.

1.3 Why a sanctioned layer is the only viable answer

Three deployment patterns are possible for AI-on-SAP under 4.2026a:

• Inside the AI app. Each Joule / Copilot / internal tool ships its own SAP integration. Every vendor reinvents the authorisation flow; audit format differs across tools; SAP's policy is still violated by the weakest implementation.
• Inside SAP itself. SAP ships a built-in AI gateway. Tied to SAP release cycles (years); AI-vendor-specific; doesn't help with non-SAP data systems (RDS, Synapse, BigQuery).
• As a separate sanctioned layer. One control plane, multiple AI tools, multiple data systems, customer-owned audit log, AI-vendor-neutral. AegisAI is in this category.

The third pattern is the one 4.2026a tacitly endorses by allowing "SAP-endorsed architectures" without insisting they be SAP-built.

1.4 AegisAI is a sanctioned pathway, not a bypass

A careful reader will go to Section 3 of the policy next:

"Customers, partners, and third parties must not bypass, disable, or otherwise circumvent API Controls, including through intermediary services, custom code or developments, proxies, gateways, impersonation techniques, or similar mechanisms."^[1]

This is the right question to ask of any control plane — and AegisAI must answer it directly, because at first glance an "intermediary gateway" is exactly what AegisAI is.

The distinction is whether the layer strengthens or weakens the controls SAP's APIs already enforce. A bypass disables limits, masks identity, or removes the audit trail. A sanctioned pathway does the opposite. AegisAI:

1. Adds rate limits SAP cannot enforce on aggregate AI traffic per user. Per-user and per-tenant fixed-window counters in Redis (§3.1) are tighter than direct API access; an agent that would otherwise hammer SAP at machine speed is now bounded.
2. Adds request ceilings SAP does not impose at the HTTP layer. Body / URL / wall-time caps (§3.2) refuse oversize and slow-loris traffic before it reaches SAP.
3. Propagates identity rather than masking it; SAP is the sole authorisation arbiter. AegisAI does not make authorisation decisions about SAP data. The calling user's SAP identity flows end-to-end via Trusted RFC (on-prem) or SAML Bearer Assertion / Principal Propagation (cloud). SAP's runtime AUTHORITY-CHECK evaluates against the end user's profile, not a service account. AegisAI relays SAP's decision verbatim — including denials. See §3.4 and ADR 0002.
4. Calls only documented interfaces under the user's identity. Trusted RFC user assumption, SAML Bearer exchange, OData with end-user bearer tokens, plus customer Z-RFCs through an explicit extension point. No undocumented, internal, or reserved-namespace endpoints (§3.4 / §3.8).
5. Records every decision in a tamper-evident audit chain SAP can re-walk. Postgres-backed HMAC chain with public integrity probe (§3.10). The audit exceeds what direct API access leaves behind.
6. Refuses to serve when its own dependencies are unhealthy. Redis / audit DB / JWKS down → fail-closed (§2.4 / §3.10). A bypass would degrade silently; AegisAI returns 503.

If a hostile reviewer asks "is this an intermediary gateway?", the honest answer is yes — and the immediate follow-up is "and here are the six places it tightens, not loosens, the controls the policy is concerned with." Section 3 reads as a prohibition on circumvention by gateway, not on enforcement by gateway.

2. Design invariants

AegisAI was built against four invariants. Every architectural decision is downstream of these.

2.1 Deterministic

Same identity + same intent + same context + same data = same response. Every time. No probabilistic security decisions; no black-box LLM in the policy path. The policy engine evaluates a deny-by-default expression set against a fixed AST whitelist. The query planner emits parameterised SQL with :named placeholders, never string interpolation. The response firewall applies a configured MaskStrategy based on field tags, not heuristic detection.

This isn't a stylistic preference. Probabilistic guardrails ("do not return PII" prompts, output keyword blocklists) are a hope, not a control. SAP's stability and governance goals require deterministic enforcement. We deliver it.

2.2 Defense in depth

Seven independent layers can each deny: rate-limit middleware, request-ceiling middleware, JWT verification, SAP/cloud authority lookup, adaptive trust evaluation, policy expression set, query planner subset check. A single bypass cannot leak data on its own. No layer trusts the prior one to have caught everything.

2.3 Identity-propagating; SAP-as-sole-arbiter

The JWT's sub and tenant_id flow all the way into the SAP RFC / OAuth call. SAP enforces authority on the same identity AegisAI verified, not on a generic service account. AegisAI does not pre-fetch the user's authority tree, does not duplicate SAP's authority logic, and does not make its own allow/deny decision about SAP data. SAP's runtime AUTHORITY-CHECK is the sole arbiter of whether the user can see what was asked for; AegisAI's job is to verify identity, propagate it, log the audit trail, and relay SAP's response. This is a deliberate architectural decision (ADR 0002) — it narrows AegisAI's accountability surface, eliminates the silent-deny failure mode of a pre-flight check, and matches the trust posture enterprise SAP customers expect.

2.4 Fail-closed by default

Infrastructure outage (Redis, audit DB, JWKS endpoint) denies before it serves. Explicit environment opt-in can toggle degraded-mode for non-production tiers; PRODUCTION ignores those opt-ins.

3. The nine-stage request pipeline

A POST /query traverses nine deterministic stages. Any one of them can deny the request.

POST /query
     |
     v
[Stage 1]  Rate-limit middleware           (Redis-backed)
[Stage 2]  Request-ceiling middleware      (body / URL / timeout)
     |
     v
[Stage 3]  Authenticate                    (JWT; HS/RS/ES/PS + JWKS)
[Stage 4]  Identity Propagation            (Trusted RFC / SAML Bearer)
[Stage 5]  Adaptive trust                  (Redis-backed signals)
[Stage 6]  Policy                          (safe-AST expression set)
[Stage 7]  Plan                            (parameterised SafeQuery)
[Stage 8]  Execute                         (MODE-gated backend)
[Stage 9]  Mask                            (schema-driven firewall)
     |
     v
[Audit]    Tamper-evident HMAC chain       (Postgres + row lock)
     |
     v
{ decision, data, trust_*, trace_id, trace }

3.1 Stage 1 — Rate-limit middleware

Per-user and per-tenant fixed-window counters in Redis. Returns HTTP 429 with an accurate Retry-After header (seconds until the current window rolls). Fails open on Redis hiccup; the trust system in stage 5 is the real gate.

3.2 Stage 2 — Request-ceiling middleware

ASGI-level enforcement of:

• Body size ≤ AEGIS_MAX_BODY_BYTES (default 64 KB) → HTTP 413
• URL length ≤ AEGIS_MAX_PATH_BYTES (default 2 KB) → HTTP 414
• Per-request wall time ≤ AEGIS_REQUEST_TIMEOUT_S (default 10 s) → HTTP 504

Both Content-Length and streaming http.request body counts are checked, so a missing or lying Content-Length doesn't bypass the cap.

3.3 Stage 3 — Authenticate

JWT verification supporting HS256, RS256, ES256, and PS256. JWKS rotation cached process-wide via PyJWKClient. iss, aud, exp, nbf, signature, and configurable clock-skew leeway all enforced. Admin-claim resolution accepts list, comma-separated, and space-separated encodings (Okta, Azure AD, PingFederate flows).

3.4 Stage 4 — Identity Propagation (SAP is sole arbiter)

This stage was reframed in ADR 0002. The decisive question — "is this user authorised to see this data?" — is answered exclusively by SAP's runtime AUTHORITY-CHECK evaluation against the user's actual SAP authorisation profile, exactly as it would be for any other SAP-integrated application. AegisAI does not walk the authority tree, does not pre-validate the intent against the user's roles, and does not make its own allow/deny decision. The customer's BASIS team configured authority once; AegisAI does not duplicate or re-implement that logic.

What Stage 4 does do is bind the request to the end user's SAP identity so SAP's check evaluates against the right profile:

• SAP ERP 6.0 EHP 8 / S/4HANA on-prem: Trusted RFC + SNC + STRUSTSSO2. The AegisAI service user is granted S_RFCACL for the AegisAI source system ID with Type = Trusted System. The RFC connection passes the end user's SAP username via RFC_USER; all subsequent BAPI calls run as the end user.
• S/4HANA Cloud / BTP / IAS-fronted: OAuth2 SAML Bearer Assertion or Principal Propagation. AegisAI exchanges the end user's JWT for a SAP-issued bearer at SAP's token endpoint and calls SAP APIs with the user-bound bearer.

For cross-cloud requests, Stage 4 also runs identity-binding rather than authority decisions:

• AWS: iam:AssumeRole with the end user's identity in RoleSessionName; permissions are evaluated by AWS at call time.
• Azure: Service-principal token exchange under the user's context; RBAC is evaluated by Azure at call time.
• GCP: Service-account impersonation with the end user as delegated principal; IAM is evaluated by GCP at call time.

A connector whose identity-propagation channel is unavailable fail-closes. A connector that's not configured is "not in scope" in LOCAL mode and a hard deny in PRODUCTION.

Why we changed this. A pre-flight authority check duplicates SAP's logic and creates two failure modes: a wrongly-passing pre-flight (caught by SAP's defence-in-depth, harmless) and a wrongly-denying pre-flight (silently blocks legitimate work, debug-hostile because the trace is in AegisAI logic, not SAP logic). Removing the pre-flight check eliminates the second failure mode entirely. The trade-off — a small additional load on SAP for clearly-unauthorised requests — is absorbed by AegisAI's per-user / per-tenant rate limits before SAP sees pathological cases.

A new env var, AEGIS_AUTHORIZATION_MODE, controls the path taken at Stage 4: relay (default for PRODUCTION, SAP / cloud IAM is sole arbiter) or pre-flight (default for LOCAL / DEV, fixture-based stub walker for tests and demos). PRODUCTION refuses to start in pre-flight mode, and refuses to operate in relay mode if no identity-propagation channel is configured.

3.5 Stage 5 — Adaptive trust

Tenant-scoped Redis ledger. Signals collected per user:

• Frequency over a configurable window (default 1 hour).
• Scope expansion — new scope values vs recent.
• Coverage ratio — fraction of authorised scope touched.
• Revisit ratio — repeat-access patterns.
• Coordination — arithmetic-progression detection across users (catches multi-user exfiltration).
• Global coverage growth rate — distinct new scope values per second across all users in the tenant.

Score combines these into 0.0..1.0. Trust levels: HIGH ≥ 0.8, MEDIUM ≥ 0.4, otherwise LOW. Rate limits and request restrictions adjust per level.

This is the stage that addresses the policy's "sequences of API calls" concern directly: AegisAI watches the sequence shape, not just the individual call.

3.6 Stage 6 — Policy

Priority-weighted expression set evaluated by a safe AST whitelist. Only len, any, all, min, max, abs, str, int, float, bool callables are allowed. Lambdas, comprehensions, imports, and dunder attribute access are rejected at compile time. Conflict resolution: highest priority wins; deny wins on tie; default deny if nothing matches.

3.7 Stage 7 — Plan

Intent compiler validates and structures the request. Query planner emits a SafeQuery dict:

{
  sql:               "SELECT id, customer, amount FROM sales
                      WHERE tenant_id = :tenant_id
                        AND bukrs IN (:bukrs_0)",
  params:            {tenant_id: "tenant_a", bukrs_0: "1000"},
  entity:            "sales",
  fields:            ["id", "customer", "amount", ...],
  tenant_id:         "tenant_a",
  row_policy_names:  ["tenant_isolation"]
}

User-derived values appear only as :named placeholders. Tenant isolation is rendered as a row policy on every entity.

3.8 Stage 8 — Execute

MODE-gated dispatch. MODE=PRODUCTION requires the real backend. The SAP simulation refuses to run in PRODUCTION; the in-memory fixture dataset refuses to run in PRODUCTION. Backend selection follows the request's context.system:

• sap → SAPAdapter (pyrfc + OData) under the user's identity.
• aws → RDS Data API or Redshift Data API.
• azure → Synapse SQL endpoint.
• gcp → BigQuery client API.

3.9 Stage 9 — Mask

The response firewall walks every row, looks up each field's FieldTag, and applies the configured MaskStrategy: NONE | REDACT | HASH | PARTIAL | AGGREGATE | DROP. Untagged fields that contain PII-shaped content (SSN, email, credit card) fail the request — that's a schema-drift / leaky-connector signal worth surfacing.

If every field of a row was redacted, the firewall fails closed rather than returning {}.

3.10 Audit append

Every decision lands in a Postgres-backed table. Per-row computation:

canonical = canonical_json(payload)            # sorted keys, compact
prev      = previous row's row_hash            # via SELECT ... FOR UPDATE
row_hash  = sha256(prev || canonical)
hmac_sig  = HMAC-SHA256(AEGIS_AUDIT_HMAC_KEY, row_hash)

A row-level lock on the previous row prevents chain races under concurrent writes. The HMAC prevents an attacker who writes directly to the database from extending the chain undetected — they'd need the key, which lives in your KMS or Vault.

GET /api/audit/verify (admin-gated) walks the full chain end to end and returns the first break id if any. GET /api/audit/integrity (unauthenticated, low-information) is the same check intended for k8s probes.

4. Threat model

Not yet mitigated and explicitly on the roadmap: cross-region encryption-at-rest key management, formal third-party pen-test, DDoS upstream of the gateway, and an automatic kill-switch on chain-break.

5. Mapping to the policy's four preamble goals

The policy preamble names four things its controls exist to do.^[1] Each maps to a specific shipping capability in AegisAI v1.0.

Goal 1 — Safeguard solution health and security

• JWT verification (HS256 / RS256 / ES256 / PS256) with JWKS rotation; mandatory iss, aud, exp, nbf.
• Identity propagation to SAP via Trusted RFC + STRUSTSSO2 (on-prem) or SAML Bearer Assertion / Principal Propagation (cloud). SAP enforces authority on the end user's actual profile, not a service account; AegisAI does not duplicate or override SAP's authority logic (ADR 0002).
• Schema-driven response firewall: per-field classification (PUBLIC / INTERNAL / CONFIDENTIAL / RESTRICTED) × user clearance × SAP-validated authority result. Display formatting only; never authorisation.
• Fail-closed defaults at every layer (Redis / audit DB / JWKS outage denies before it serves).
• PRODUCTION refuses to start with default secrets, refuses to run in pre-flight authorisation mode, and refuses to run in relay mode without an identity-propagation channel configured.

Goal 2 — Promote equitable access

• Per-user and per-tenant fixed-window rate limits in Redis (§3.1) — one tenant cannot monopolise SAP capacity at the expense of another.
• Trust-based throttling drops misbehaving callers in proportion to their score, leaving capacity for well-behaved ones.
• ASGI-level request ceilings (§3.2) prevent oversize / slow-loris requests from starving the gateway and downstream SAP.
• One well-behaved client to SAP, not thousands of agents — the load shape SAP sees is bounded and predictable.

Goal 3 — Prevent API misuse

• Intent compiler validates and structures every request; vague, scope-expanded, or syntactically suspicious intents are rejected at compile time before any backend is touched.
• Deterministic policy engine evaluates a deny-by-default expression set against a fixed AST whitelist — no probabilistic guardrails to second-guess.
• Adaptive trust signals (§3.5) — frequency, scope expansion, coverage growth, cross-user coordination — directly address the policy's "sequences of API calls" concern.
• Documented BAPIs only; no undocumented or reserved-namespace interfaces; no ODP large-scale extraction patterns.
• Parameterised SafeQuery planner — no string interpolation, no SQL injection surface, even on the LOCAL fixture path.

Goal 4 — Support the enforcement of this API Policy

• SAP is the sole authorisation arbiter (ADR 0002) — every request executes against the end user's SAP identity, and SAP's runtime AUTHORITY-CHECK decides allow / deny. AegisAI records SAP's verdict verbatim (including the failing authority object on a denial) into the audit chain. No AegisAI-internal authority logic competes with or second-guesses SAP's enforcement.
• Tamper-evident HMAC audit chain (§3.10) — Postgres-backed with SELECT ... FOR UPDATE row lock so the chain stays linear under multi-pod writes. SAP's authorisation outcome is part of every audit row.
• Public integrity probe (/api/audit/integrity) suitable for Prometheus / k8s CronJob monitoring.
• Admin-gated chain re-walk (/api/audit/verify) returns the offending row id on first mismatch.
• OpenTelemetry from day one — every decision carries a trace_id that joins traces, logs, and audit rows.
• Single audit format across SAP, AWS, Azure, GCP — auditor doesn't have to learn a different shape per data system. Each platform's native authority decision is the recorded truth; AegisAI is the consistent envelope.

6. Pilot path and commercial deployment models

6.1 Pilot — vendor-hosted on Render

• 14-day pilot on Render-hosted infrastructure.
• Non-production sandbox data only. The pilot agreement excludes customer PII, regulated data, and cross-tenant data by contract.
• Free; pilot infrastructure costs ~$24/month, paid by AegisAI.
• Outcome: written readout, audit-log export, and four success criteria (functional accuracy, trust signal validity, audit integrity, latency).

6.2 Commercial — self-hosted Helm chart

• AegisAI runs in the customer's Kubernetes cluster (EKS / AKS / GKE / on-prem).
• Customer's data never leaves their environment. AegisAI vendor sees no row-level data; we see metadata for support.
• Vendor sells support, upgrades, customer-success.
• Non-root, read-only-rootfs, seccomp-default Helm chart ships with the product.

This is not SaaS. AegisAI's data-plane access pattern (the gateway sees every query and response in order to mask) makes SaaS data-plane access unacceptable to enterprise SAP customers. Self-hosted Helm is the primary commercial model.

6.3 Commercial — BYOC managed (premium tier)

• AegisAI vendor deploys into the customer's AWS / Azure / GCP account using cross-account IAM.
• Customer keeps the keys; vendor keeps the operational SLA and upgrade cadence.
• Premium tier; for customers who want self-hosted's data residency with SaaS-style operational hands-off.

7. Honest residuals

AegisAI v1.0 is approximately 94% production-ready by an internal scorecard. The residual 6% is:

• External pen-test against a customer-shaped staging deployment. Scheduled, not yet completed.
• SOC 2 Type I and ISO 27001 control mapping started against CC6 / CC7 / CC8; full attestation in flight.
• Customer-specific SAP Z-RFCs. The structural parser is in place; older or heavily-customised SAP installations need per-customer mapping work (typically a few hours per shop).
• Live KMS / Vault wiring. The provider classes are implemented and tested in unit tests; each customer site needs its own credentials and IAM bindings.
• GDPR retention posture. Append-only audit chain reconciled with right-to-be-forgotten through retention windows + data minimisation; documented as a policy decision, not as automatic deletion.

We list these explicitly because saying "we're 100% ready" is the kind of claim that erodes trust the moment a buyer's diligence team finds the gap. The 94% is real and verifiable; the 6% is a punch list, not a hidden weakness.

7.1 Detection limits — what AegisAI does not catch

The trust scorer in §3.5 is one of seven independent denial layers, not a panacea. Reviewers should know what it does not catch, so the rest of the architecture is being asked to do its share of the work:

• An agent that stays inside its authorised scope and queries at human-typist rate is not flagged by frequency, scope-expansion, coverage-growth, or coordination signals. It is gated only by stages 3 (auth), 4 (SAP authority), 6 (policy), and 9 (response masking). If those four are correctly configured for the user, the request is allowed — which is correct, but it means the trust scorer adds nothing in the well-behaved case.
• A first-time legitimate query has no behavioural history to score against. The trust scorer biases LOW until enough signal accumulates; legitimate traffic is rate-limited conservatively at the start of a session.
• Coordinated extraction across many tenants is invisible. All trust signals are tenant-scoped on purpose (privacy); the scorer cannot see a multi-tenant pattern.
• Semantic exfiltration — an agent asking "what is the median salary by department" instead of pulling individual rows — is not prevented by the trust scorer. It is prevented (or not) by the response firewall's aggregation strategy and by whether the user has clearance for the underlying field.
• Compromised IdP / stolen JWT. AegisAI verifies the signature, audience, and expiry; it does not detect that Alice's laptop was breached this morning and the attacker is using her token. Mitigation lives in the IdP (short token TTLs, anomaly detection on sign-in) — not in AegisAI.
• Insider abuse with full clearance. A user who is legitimately authorised to see the data they are exfiltrating cannot be stopped by a clearance-based control. AegisAI's contribution here is the audit chain — who saw what, when — not prevention.

These are not bugs; they are the boundary of what a deterministic policy gate can do. A complete defensive posture combines AegisAI with IdP hygiene, DLP, and post-hoc behavioural analytics on the audit chain.

8. Conclusion

SAP API Policy 4.2026a, Section 2.2.2 turns "AI-on-SAP" from an architectural debate into a compliance requirement. Enterprises that want to ship AI features against SAP data have two choices: route through a sanctioned, structured control plane, or stop.

AegisAI is one such control plane. It maps to each of the policy's four preamble goals (§5); it propagates identity end to end and lets SAP be the sole authorisation arbiter (ADR 0002) — there is no AegisAI-internal authority logic competing with SAP's AUTHORITY-CHECK; it records every decision, including SAP's authority verdict, into a tamper-evident audit chain; and the same identity-propagation, audit, and intent-translation architecture serves AWS, Azure, and GCP data systems whose own policy responses are likely to follow.

We expect more layers like AegisAI to emerge over the next 18 months. We're early; we're production-ready; and we're looking for the design partners who help us shape v2.

9. References

1. SAP API Policy v.4.2026a. SAP SE, April 2026. Sections 1 (API Availability), 2 (API Controls — Specific and General, including §2.2.1 and §2.2.2), 3 (Monitoring and Remedies), and 4 (Compliance). Direct quotes in §1.1, §1.2, §1.4, and §5 of this whitepaper are taken verbatim from this document. The full text is two pages; readers can request the version of record from their SAP account team or the Documentation supplied with their SAP solution. Citation note: the policy includes the copyright stamp "© 2026 SAP SE or an SAP affiliate company. All rights reserved. See Legal Notice on www.sap.com/legal-notice for use terms, disclaimers, disclosures, or restrictions."
2. RFC 7519 — JSON Web Token (JWT). Internet Engineering Task Force, May 2015. datatracker.ietf.org/doc/html/rfc7519. Used in §3.3 (Authenticate) for iss / aud / exp / nbf claims and signature verification.
3. RFC 7517 — JSON Web Key (JWK) and JSON Web Key Set (JWKS). Internet Engineering Task Force, May 2015. datatracker.ietf.org/doc/html/rfc7517. Used in §3.3 for the JWKS-rotation pattern via PyJWKClient.
4. RFC 6749 — The OAuth 2.0 Authorization Framework. Internet Engineering Task Force, October 2012. datatracker.ietf.org/doc/html/rfc6749. The IdP-issuer pattern AegisAI relies on for the connector kits — AegisAI is a resource server, not an authorization server, per RFC 6749 terminology.
5. NIST SP 800-207 — Zero Trust Architecture. National Institute of Standards and Technology, August 2020. doi.org/10.6028/NIST.SP.800-207. The deterministic, identity-propagating, fail-closed posture described in §2 follows NIST 800-207's tenets — every request is authenticated and authorised regardless of network position.
6. OWASP Top 10 for Large Language Model Applications, v1.1. OWASP Foundation, 2024. owasp.org/www-project-top-10-for-large-language-model-applications. LLM06 (Sensitive Information Disclosure), LLM07 (Insecure Plugin Design), and LLM08 (Excessive Agency) are exactly the risks AegisAI's response firewall (§3.9), policy engine (§3.6), and trust scorer (§3.5) are designed to mitigate.
7. MITRE ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems. atlas.mitre.org. The threat model in §4 is informed by ATLAS's enumeration of ML-system attack surfaces, particularly the agent-as-attacker patterns translated to the agent-against-API setting.
8. SAP Authorization Concept (SAP Online Help). Documentation for BAPI_USER_GET_DETAIL, SUSR_GET_PROFILE_AUTH_OBJECTS, and the auth-object → field-value model (e.g. P_ORGIN, P_PERNR, F_BKPF_BUK) used throughout §3.4 and §5 (Goal 1). Customer SAP basis teams are the authoritative reference; Documented Use only, per §1.1 of the API Policy.