Six concrete scenarios across SAP, cloud data warehouses, SaaS data, NoSQL, multi-cloud federation, and governance. Each one uses the same 9-stage pipeline with the same identity-propagation guarantees.
SAP API Policy 4.2026a, §2.2.2 prohibits direct AI access. AegisAI is the sanctioned architecture pathway — SAP's AUTHORITY-CHECK evaluates against the actual end user, not a service account.
Illustrative: a CFO asks Copilot Studio "show me Q3 revenue by region." The naive integration hands Copilot an SAP service account with broad authority. SAP logs the service account. The SOX auditor wants the actual user. Security wants to know if this scales without becoming an exfiltration risk.
The user's JWT becomes a Trusted RFC ticket protected by SNC level 8/9. SAP receives the request authenticated as the calling user — SAP's AUTHORITY-CHECK runs against that user's actual S_TABU_DIS + P_ORGIN profile. The audit chain records "user=user@customer-domain, decision=ALLOW, masked_fields=[]". A compliance officer can replay the chain end-to-end.
Per-user attribution that survives an SAP audit. Documented BAPIs only (no undocumented RFC sprawl). Trusted RFC + STRUSTSSO2 + SNC instead of static credentials. 4.2026a Section 2.2.2 architecture-leg compatibility, on paper, signed.
Trusted RFC + STRUSTSSO2 + SNC level 8/9
POST /query Authorization: Bearer eyJhbGc... { "intent": "revenue by region Q3", "context": { "system": "sap" } }
Your data team built a Snowflake warehouse with row-level security and Unity Catalog grants per analyst. The AI assistant must respect those grants. AegisAI propagates the external SSO identity so the warehouse enforces what it's already enforcing.
The data team spent months wiring Snowflake row-level security and column-level grants. Then "AI analytics" arrives with a service account and bypasses every grant. The first audit catches it. The remediation conversation is awkward.
Snowflake supports external browser SSO that returns the user's session token. AegisAI calls Snowflake under that token, not a service account. Unity Catalog grants and row-level policies apply to the user, exactly as designed. Same audit pattern works for Databricks (Unity Catalog) and BigQuery (dataset ACL + IAM).
Your existing warehouse permissions stop being a "we'll figure that out later" problem. The AI assistant sees only what the calling analyst sees. The query history in Snowflake shows the actual user, not the integration account.
External browser SSO / Unity Catalog / Workload Identity Federation
POST /query { "intent": "top customers by ARR", "context": { "system": "snowflake", "warehouse": "prod_analytics" } }
Your SaaS apps already enforce field-level permissions per user profile. The AI assistant must respect those profiles. AegisAI uses OAuth per-user so Salesforce / Workday / ServiceNow apply exactly the same field permissions they always do.
Your sales ops team built a Salesforce role hierarchy with field-level security. Reps see opportunity stage but not amount. Managers see amount but not commission split. The AI assistant must respect this. A connected app with broad scope blows the whole thing up.
Salesforce OAuth 2.0 user-agent flow returns a token bound to the calling user. AegisAI uses that token, not an integration user with API Enabled + Modify All Data. The Salesforce platform enforces field-level security per user profile, exactly as designed. Same pattern works for Workday (OAuth + SAML), ServiceNow (OAuth + ACLs), NetSuite (token-based + RBAC).
Your SaaS permission model keeps working. The AI assistant cannot accidentally surface fields the user shouldn't see. The audit trail in each SaaS system shows the actual user, which keeps your SOC 2 happy.
OAuth 2.0 user-agent / OAuth + SAML / per-user impersonation
POST /query { "intent": "open opportunities > $50k", "context": { "system": "salesforce" } }
Your product team built an OIDC-secured Elasticsearch cluster with per-index permissions. The AI search assistant must respect those permissions. AegisAI maps the JWT to the right OIDC realm and Elasticsearch handles the rest.
Your customer-facing AI search uses Elasticsearch behind a multi-tenant SaaS. Tenants must not see each other's data. The naive solution is "we add a tenant filter to every query" — one missed filter is a data breach. The defensive solution is "the index actually enforces tenancy."
Elasticsearch's OIDC realm binds search permissions to the user's JWT claims. AegisAI forwards the JWT verbatim — the user's tenant_id claim becomes the filter Elasticsearch applies natively. Cross-tenant search is structurally impossible. Same pattern works for MongoDB Atlas (Atlas users + per-DB roles), DynamoDB (IAM per-table / per-attribute).
The "we add a tenant filter to every query" anti-pattern disappears. The data store does the enforcement. A misconfigured AI client cannot leak cross-tenant data because the store doesn't return it.
OIDC realm / Atlas users / IAM per-table
POST /query { "intent": "search support tickets containing 'payout'", "context": { "system": "elasticsearch" } }
Real enterprises have data spread across SAP + Snowflake + Salesforce. AegisAI federates one intent into parallel queries against each system, each under the same end-user identity. If one backend is down, the others still answer.
"Show me top 10 customers by total relationship value" requires data from three systems — ARR in Salesforce, support cost from ServiceNow, ERP data from SAP. The naive answer is "we wrote a stored procedure that aggregates these into a single warehouse." That stored procedure breaks when the SAP schema changes, and the warehouse becomes stale fast.
The intent compiler recognizes federation patterns ("across", "in PX1 and PQ1", "all systems"). The execution engine fans out to each backend in parallel under the user's identity at each one. Results are merged in the response firewall. Partial failures (one system down) return partial results with explicit notation in the audit row.
Cross-system queries without the data-warehouse middleman. Each system stays the source of truth. Federation is opt-in per intent — queries can still target a single system when that's the right answer.
Per-backend identity at each hop (Trusted RFC for SAP, OAuth for SaaS, etc.)
POST /query { "intent": "top customers by ARR across SAP, Snowflake, Salesforce", "context": { "federation": "all" } }
Built-in governance queries answer the security questions an analyst would normally walk through SUIM for. Federated across multiple SAP systems in one prompt. Result is HMAC-audited.
Your security team runs quarterly reviews. "Show me everyone with SAP_ALL across our production landscape" today means an analyst opens SUIM in PX1, exports CSV, repeats in PQ1, repeats in PD1, manually deduplicates, ships a spreadsheet to leadership. Tedious. Error-prone. Hard to audit.
Native governance entities: user_authorizations, role_assignments, profile_assignments. Federation sentinels: "in production systems", "across all sap systems", "in PX1 and PQ1". One prompt becomes a federated query across multiple SAP systems, evaluated under the security analyst's own identity. Result lands in the audit chain.
SUIM-equivalent governance queries with one prompt. Audit chain proves who asked, when, what the verdict was. Repeatable. Programmatic. The analyst's quarterly review goes from a day to a minute.
Per-system Trusted RFC for each federated SAP target
POST /query { "intent": "list users with SAP_ALL across production systems", "context": { "system": "sap" } }
30-minute architecture call. We open the operator console and run real queries through your stack — see the audit chain tick up in real time.
