AegisAI is the identity layer between AI agents (Copilot, Joule, Claude, ChatGPT, Gemini) and Snowflake. Per-user identity propagation. Snowflake's own access controls stay in charge. Every decision HMAC-audited.
⧉ IN ACTIVE DEVELOPMENT: 14-day sprint to LIVE state. External browser SSO integration, Unity Catalog grant honoring, row access policy verification under per-user session.
⧉ PILOT-ELIGIBLE Q3 2026: Available as part of customer pilot engagements during build. We build against your Snowflake sandbox in parallel with the customer's pilot.
The architectural primitives (per-user OAuth, schema-driven response firewall) are built once at the gateway. Snowflake-specific integration is the connector module.
Snowflake supports column-level masking, row access policies, dynamic data masking, and Unity Catalog grants. The data team spent months wiring them up. Then an 'AI analytics' integration arrives with a service account holding ACCOUNTADMIN — and every grant is bypassed. The first audit catches it. The remediation conversation is awkward.
Snowflake's external browser SSO returns a session token bound to the calling analyst. AegisAI uses that token, not a service account. Row access policies fire. Column-level masks fire. Unity Catalog grants fire. The query history in Snowflake shows the actual user, not the integration account. Your SOC 2 stays happy.
Snowflake-native external browser SSO. The user's identity arrives at Snowflake exactly as if they queried directly.
Catalog grants, schema grants, table grants, and role hierarchy — all enforced by Snowflake against the actual user, not the AegisAI service principal.
Row access policies and column-level masking policies fire automatically. No new policy work.
Snowflake's QUERY_HISTORY view shows the actual analyst's session, not the AegisAI integration. Audit-ready.
Every AegisAI decision is also recorded in the HMAC-chained audit. Double-attribution: Snowflake's view plus AegisAI's.
Snowflake's MFA and network policies still apply per user. AegisAI is transparent to those controls.
Three patterns enterprises try when AI meets Snowflake. Only one survives an audit.
| Capability | Service-account integration | Generic API gateway | AegisAI |
|---|---|---|---|
| Per-end-user audit attribution | ×Integration account at best | ×Token logged, identity lost | ✓Snowflake sees the actual user |
| Snowflake native permissions enforced | ×Bypassed by broad scope | ×Gateway is at wrong layer | ✓Snowflake's IAM is sole arbiter |
| Tamper-evident audit chain | ×Logs only | ×Logs only | ✓HMAC hash chain, re-walkable |
| Fail-closed on infra outage | ×Depends on app code | Partial | ✓Redis / Postgres down → deny |
Yes. AegisAI supports both Snowflake's external browser SSO and OAuth integrations (Azure AD, Okta, Auth0, Ping, etc.). Whatever your data team already wired up.
Warehouse-level permissions are part of Snowflake's grant model. AegisAI propagates the user identity; Snowflake enforces which warehouses they can use.
Yes, natively. AegisAI doesn't bypass row access policies — it ensures the right user identity reaches Snowflake so the policy can fire correctly.
AegisAI works in front of Cortex calls just like it works in front of any SQL query. Per-user audit attribution applies to ML.PREDICT calls the same way.
Yes. Multi-tenant SaaS using Snowflake row access policies for tenant isolation will see each tenant's user identity propagate correctly. Cross-tenant access is structurally impossible.
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.
