I Built a AI Security Operations Center from a Single Snowflake View

Snowflake released CORTEX_AI_GUARDRAILS_USAGE_HISTORY on June 16, 2026, enabling a security engineer to build a full AI Security Operations Center from a single view. The dashboard computes an Enterprise AI Risk Score (0-100) by weighting injection rates, privileged access, velocity anomalies, and other factors, allowing the CISO to assess security posture with one number. The system uses a single query with pandas-based client-side processing to avoid Streamlit concurrency limits.

Leveraging Snowflake’s new CORTEX AI GUARDRAILS USAGE HISTORY view to build executive risk scoring, UEBA, MITRE ATLAS mapping, compliance automation, and incident monitoring—all from a single query. Our security team had a reasonable question last month: “Which of our Cortex Agents has been targeted by prompt injection attacks, and how often?” I didn’t have an answer. Guardrails were running — we could see that from the Cortex AI settings — but there was no way to query what they were catching. No scan history, no flag counts, no user attribution. The guardrails were a black box protecting a glass house. Then Snowflake shipped CORTEX AI GUARDRAILS USAGE HISTORY on June 16, 2026, and within a week I'd built something that made our CISO lean forward in his chair. I expected the view to tell me what kind of injection was attempted. It doesn’t. GUARDRAILS SIGNAL is a boolean — TRUE or FALSE. That's it. The documentation explains why: the guardrail raises a signal that gets sent to the LLM for adjudication . The LLM decides whether it’s a genuine attack. So TRUE doesn’t mean “attack happened” — it means “something suspicious was detected in this tool’s output.” Your SOC team should investigate, not auto-remediate. This distinction matters because we initially built automated response logic disable agents on flag spike . We pulled that back after realizing we’d be acting on signals, not confirmed incidents. The view is an observability tool, not a control plane. Our first version had 4 separate cached queries: one for summary stats, one for hourly trends, one for top users, one for raw data. It worked locally. In production, it died immediately with: Exceeded maximum number of inbound queries allowed for this instance: 90 Streamlit in Snowflake enforces a hard concurrency limit. Four queries times multiple concurrent users equals instant failure. The fix was obvious in hindsight: one query, all derivation in pandas . We pull 5,000 rows with a single parameterized SELECT, then compute summaries, trends, user risk scores, and compliance checks entirely client-side. Cache TTL at 10 minutes keeps it responsive without hammering the view. The other gotcha: Snowflake’s connector rejects params={"hours": 72} with ProgrammingError: 252004. It wants a list with ? positional markers: params= 72 . Cost me 20 minutes of confusion because the Streamlit docs show the dict style. Security dashboards fail when they show 47 metrics and no conclusion. Our CISO doesn’t want flag rates and token counts — he wants one number that answers “are we okay?” We built a composite Enterprise AI Risk Score 0–100 with weighted components: Injection rate gets 25% weight — the flag rate normalized against our circuit breaker threshold 15% . If we’re at 3% flags, that component scores 20 out of 100. If we’re at 15%+, it maxes at 100. Privileged access gets 20% — each flagged scan from ACCOUNTADMIN or SYSADMIN adds 20 points. One flag from a privileged role is a bigger deal than ten from an analyst role. Velocity anomalies get 15% — any user exceeding 3x their hourly baseline in the last hour gets flagged. This catches automated probing. Off-hours activity 15% , cost spikes 10% , compliance failures 10% , and nested agent chains 5% round out the score. The result: a single number with a color. Green means healthy. Red means call someone. Our weekly security review went from a 40-minute metrics walkthrough to a 5-minute check of one number plus the drift indicator. The GUARDRAIL RESULTS column is an array — one entry per tool use in the request. Each entry contains tool type sql execute, web search, server mcp , indirect prompt injection boolean , and token counts. This is where the real signal lives. We flatten this array to build a tool-type breakdown : which tool types get targeted most? In our environment, web search flags at 4x the rate of sql execute. That tells us external content is the primary injection vector — not surprising, but now we have data. We also map these signals to MITRE ATLAS the AI-specific threat framework . AML.T0051.001 Indirect Prompt Injection maps directly to indirect prompt injection = TRUE. AML.T0051.002 Tool Output Manipulation maps to injections via web search or server mcp tool types. It's not perfect — we can't distinguish jailbreaks from exfiltration attempts — but it gives security teams a common language when reporting to the board. What’s genuinely missing: There’s no prompt text, no response content, no IP address, no geographic data, no model name, and no latency measurement. You can’t do PII scanning, impossible-travel detection, or model comparison from this view alone. For those, you’d need to join with LOGIN HISTORY and QUERY HISTORY — which is on our roadmap but introduces correlation complexity. Traditional User Entity Behavioral Analytics relies heavily on network signals — login location, IP reputation, session patterns. This view has none of that. So we built time-based UEBA instead. For each user, we compute: flag rate obvious , night activity percentage scans between 22:00–06:00 , weekend percentage , token consumption anomaly standard deviations from the user population mean , role diversity users switching between multiple roles , and a composite behavioral risk score weighting all five. It works better than I expected. In our test scenarios, the insider threat user ACCOUNTADMIN at 3 AM with high token counts scores 80+ on behavioral risk while normal analysts score under 10. The separation is clean because the signals compound — night activity alone isn’t alarming, but night + privileged role + high tokens + flags = clear outlier. The technical team cared about MITRE and UEBA. The compliance team cared about one thing: can we generate audit evidence from this? We built 6 automated control checks that run on every data refresh: PAM-001 fails if any privileged role has injection flags SOX . SEC-001 fails if the flag rate exceeds the circuit breaker threshold NIST AI RMF . ACC-001 fails if flags occur outside business hours PCI-DSS . GOV-001 passes if the view has data at all — proving guardrails are enabled EU AI Act . Each check produces a PASS/FAIL with evidence text and a framework attribution. The compliance team can export this as a text report with a SHA-256 integrity hash — tamper-evident, timestamped, and directly mappable to their audit questionnaires. This single feature — not the risk score, not the MITRE mapping — is what got the project promoted from “engineering side project” to “funded initiative.” Youtube Demo: The signal-vs-classification gap matters more than you’d think. We spent two days building automated response logic before realizing we were acting on unconfirmed signals. If your flag rate is 20%, that means 20% of tool outputs looked suspicious to the scanner — not that 20% were actual attacks. Build investigation workflows, not kill switches. Demo mode isn’t optional. The view only has data if your account actively uses Cortex AI features. We added a synthetic data toggle 500 records with realistic attack patterns so we could demonstrate the full 10-tab system to stakeholders without waiting for production traffic. Every internal demo used this mode. One thing the documentation doesn’t mention: The PARENT REQUEST ID field enables reconstructing nested agent chains — agent A calls agent B, which calls a tool. When the tool output gets flagged, both the child and parent request IDs are captured. This is invaluable for tracing multi-hop injection attempts that spread across agent boundaries. My recommendation: Start with the risk score and compliance checks. Those two capabilities alone justify the development time because they answer the two questions every CISO asks: “How bad is it?” and “Can we prove we’re monitoring it?” Snowflake’s CORTEX AI GUARDRAILS USAGE HISTORY view fills a critical observability gap for anyone running agentic AI workloads. It's not a complete security solution — it's one view with boolean signals and cost data — but that's enough to build meaningful monitoring if you're deliberate about what you derive from it. The biggest value isn’t the raw data. It’s the ability to transform a CISO’s “I don’t know” into a score, a trend, and a compliance report — all from a single query against an Account Usage view that Snowflake maintains for you. Full project Streamlit app, SQL infrastructure, 50 unit tests, 5 scenario simulations : cortex-guardrails-project https://github.com/skrz2014/cortex-guardrails-project Documentation : CORTEX AI GUARDRAILS USAGE HISTORY view https://docs.snowflake.com/en/release-notes/2026/other/2026-06-16-cortex-ai-guardrails-usage-history-view This article represents the author’s personal views and experience, not those of any employer. 👏 Give it a clap if it added value 🔗 Share it with your team ➕ Follow for more 📘 Medium: Satish Kumar https://medium.com/u/d170d49944ec 🔗 LinkedIn: satishkumar-snowflake https://www.linkedin.com/in/satishkumar-snowflake/ See you in the next one 👋 I Built a AI Security Operations Center from a Single Snowflake View https://pub.towardsai.net/i-built-a-ai-security-operations-center-from-a-single-snowflake-view-7250f265dee7 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.