Authorization-aware AI for SAP

Primary sources: NIST SP 800-207, Zero Trust Architecture; NIST AI Risk Management Framework Core; OECD AI Principles.

Date checked: 2026-08-11

Confidence: high for the identity, resource, lifecycle, and traceability principles; medium for implementation details because SAP products, identity systems, retrieval stacks, and local roles vary.

Practical implication: An AI layer must not turn broad service-account access into broader access for the requester. Enforce policy before retrieval and before action, then test what the response can reveal indirectly.

Problem this pattern addresses

An AI assistant can combine data from more systems and documents than a user normally sees in one application. If the integration retrieves with a broad technical account and applies access checks only after generation, it can disclose restricted facts through answers, citations, counts, or suggested actions. Authorization therefore has to follow the request across the full AI workflow.

Where this fits

Authorization-aware AI belongs in any SAP support assistant, retrieval workflow, ticket summarizer, analytics interface, or agent that reads operational data. NIST's zero-trust architecture focuses protection on users, assets, and resources rather than assuming trust from network location. For AI, the relevant resource includes source documents, business records, retrieved fragments, generated answers, tool calls, and logs.

The boundary has six stages

Stage	Required control question	Failure example
Identity	Which person or workload is making the request?	A shared assistant session loses the real requester identity.
Intent and scope	Which business purpose, system, organization, and time range are allowed?	A support question silently expands across company codes.
Retrieval	May this identity discover and read every returned source?	Search metadata reveals a restricted customer or personnel record.
Generation	Can the answer expose, combine, or infer restricted information?	An aggregate or summary reveals data not visible in the source UI.
Action	Is this identity allowed to perform this exact operation now?	A broad technical user bypasses the requester's SAP authorization.
Evidence	Who may inspect prompts, sources, outputs, approvals, and logs?	An audit log becomes a second uncontrolled data store.

Preserve the requester context

Do not authorize a response only because the integration can reach the data. Carry a verified requester or workload identity through the retrieval and tool boundary. Map it to the business scope required for the use case, such as system, client, company code, sales organization, purchasing organization, plant, data domain, or support assignment.

Use separate technical credentials where the platform requires them, but apply policy using the requester, resource, action, and context. Re-evaluate authorization for each sensitive retrieval or action instead of treating the first chat login as permanent permission.

Filter before generation

Access checks should occur before restricted material enters the model context. Filtering only the final answer is weaker because the system has already processed data outside the intended boundary and may reveal it indirectly.

• Apply document- and record-level policy before retrieval results are assembled.
• Treat titles, snippets, embeddings, metadata, counts, and citations as potentially sensitive.
• Keep approved operating instructions separate from private tickets and case evidence.
• When sources have mixed authorization, exclude or redact the restricted fragment before generation.
• Return a clear “insufficient authorized evidence” result instead of silently widening access.

Separate recommendation from execution

A model may be permitted to explain an approved procedure without being permitted to execute it. Treat read, recommend, prepare, approve, execute, and verify as separate capabilities. The person who can view a sales-order status may not be allowed to change the order; the person who can diagnose master data may not be allowed to create or approve it.

For any change-capable tool, validate structured inputs, re-check authorization at execution time, show the reviewer the exact proposed action and affected objects, record approval, and verify the postcondition. High-impact actions should remain unavailable when the assistant cannot establish scope or when the request depends on inferred permission.

Test for direct and indirect disclosure

1. Create identities with deliberately different organizational and document access.
2. Test exact identifiers, broad questions, summaries, comparisons, counts, and follow-up questions.
3. Test whether citations, autocomplete, errors, and “no result” behavior reveal restricted existence.
4. Test retrieved documents that contain both public operating guidance and restricted case evidence.
5. Test role removal, temporary access expiry, user transfer, and source reclassification.
6. Repeat the action test independently from the retrieval test.

Evidence to retain

• Identity and authorization policy version used for the request.
• Resource identifiers and classifications considered by retrieval.
• Allowed and rejected sources without copying sensitive values into broad logs.
• Model and retrieval configuration, response, reviewer, approval, tool call, and result.
• Access-test cases, failures, remediation, and retest date.

Operational ownership

Security or identity teams can define controls, but the process owner must still decide the legitimate business purpose and data scope. Knowledge owners classify sources; SAP role owners define source-system access; the AI service owner implements and monitors enforcement; reviewers remain accountable for decisions. NIST's AI RMF treats governance as cross-cutting, which is a better fit than assigning all AI risk to one technical component.

Boundaries

This pattern is architectural guidance, not a completed authorization design. It does not map specific SAP roles or certify compliance. Use current product and identity-platform documentation, local security policy, privacy requirements, and legal review. Retest whenever roles, source classifications, retrieval configuration, model providers, tools, or logging change. The AI-ready documentation pattern covers source status and classification; the AI in Business Decision Framework covers business approval and pilot gates.