Cortex Agents Left Unmonitored for a Month — Here’s What Trust Center Found

Snowflake's Cortex AI Guardrails reached General Availability on April 20, 2026, with CoWork and Cortex Agent support added May 14, 2026, and the CORTEX_AI_GUARDRAILS_USAGE_HISTORY view became available June 16, 2026, according to the company's release notes. An initial Cortex Agent deployment that began in May left three agents running unmonitored across customer support triage, internal knowledge lookup, and a data quality pipeline, with the Trust Center AI Security tab showing no agents visible, no scanners running, and no guardrails active. Enabling guardrails account-wide requires setting CORTEX_ENABLED_CROSS_REGION to ANY_REGION, AWS_US, or AWS_GLOBAL first, since the parameter otherwise accepts the value but scans nothing, and the AI Security scanner package remains in Preview for all accounts.

An initial Cortex Agent deployment began in May. By June, three agents were running across different teams — handling customer support triage, internal knowledge lookup, and a data quality pipeline. None had guardrails enabled. None were being monitored for prompt injection. The required configuration had not been set up. The AI Security tab in Trust Center showed everything at zero — no agents visible, no scanners running, no guardrails active. The environment was not necessarily clean. Nothing was being monitored. This article walks through the next steps: enabling the AI Security scanner package, turning on Cortex AI Guardrails, and building a monitoring layer that reports when something goes wrong. The entire process takes less time than expected — the hard part is knowing these capabilities exist in the first place. The AI Security tab before any configuration — a complete blind spot. Note: The AI Security scanner package is currently in Preview available to all accounts . Cortex AI Guardrails reached General Availability on April 20, 2026, with CoWork and Cortex Agent support added May 14, 2026. The CORTEX AI GUARDRAILS USAGE HISTORY view became available June 16, 2026. Check Snowflake release notes for the latest status. An initial attempt to enable guardrails may fail silently — the parameter accepts the value but guardrails do not actually scan anything. The issue: cross-region inference must be enabled first. The documentation mentions this as a prerequisite, but the error behavior does not make it obvious. This parameter must be set first, or guardrails have nothing to route through: ALTER ACCOUNT SET CORTEX ENABLED CROSS REGION = 'ANY REGION'; Valid values that satisfy the guardrails prerequisite are ANY REGION, AWS US, or AWS GLOBAL — choose based on data residency requirements. Any of the three satisfies the guardrails prerequisite. The other prerequisite is the SNOWFLAKE.TRUST CENTER ADMIN application role. Running as ACCOUNTADMIN provides this implicitly. To delegate scanner management to a security team without granting ACCOUNTADMIN: GRANT APPLICATION ROLE SNOWFLAKE.TRUST CENTER ADMIN TO ROLE trust center admin role; One detail the documentation does not emphasize: TRUST CENTER VIEWER is sufficient to see the AI Security tab and all findings. TRUST CENTER ADMIN is only needed to enable/disable scanner packages and manage violation lifecycle. The enablement itself is straightforward. One statement protects Cortex Code, CoWork, and all Cortex Agents in the account simultaneously: bash ALTER ACCOUNT SET AI SETTINGS = $$ guardrails: advanced prompt injection: - enabled: true$$; Verify it took effect: SHOW PARAMETERS LIKE 'AI SETTINGS' IN ACCOUNT; Confirming guardrails are active account-wide. What guardrails actually do at runtime: they scan every request — including content returned by tool calls web search results, MCP server responses, SQL execution output — for patterns associated with prompt injection and jailbreak attempts. The GUARDRAILS SIGNAL column in the usage history view indicates whether a scan was flagged. The LLM then uses that signal to decide whether to refuse the request. One important implementation detail: guardrails scan each tool use independently. A single agent request that calls three tools produces three rows in the usage history view — one per tool use scanned. This matters when evaluating cost token-based billing versus detection coverage. To disable guardrails if needed : ALTER ACCOUNT UNSET AI SETTINGS; The scanner package enabled through the Trust Center UI under Scanner Packages AI Security Enable runs once daily by default. On its first run in a typical account, it may surface HIGH-severity findings that are commonly overlooked: Cortex Search Service Privileged Roles — Cortex Search Services owned by ACCOUNTADMIN. Since these run with owner’s rights, they inherit every privilege of that role. The fix is transferring ownership to a dedicated service role with minimal permissions. Cortex Code CLI PAT Without Role Restriction — PATs issued for CLI access without ALLOWED ROLES set. A compromised token would have broad access. Adding role restrictions and ensuring a network policy is attached resolves this. Sensitive Data Accessed by Agent — Agents accessing columns tagged with SNOWFLAKE.CORE.PRIVACY CATEGORY via data classification without any masking policy applied. The agents can read raw PII. The scanner catches what a standard access review process might miss. Guardrails Not Enabled — Before the ALTER ACCOUNT statement is applied, this shows as a violation. After enabling, it clears on the next scanner run. The CORTEX AI GUARDRAILS USAGE HISTORY view is where ongoing operations happen. Unlike the scanner which runs daily , this view captures every guardrail scan in near-real-time. Find all flagged requests from the last 72 hours: SELECT USER NAME, AGENTIC SOURCE, USAGE TIME, GUARDRAILS SIGNAL, GUARDRAIL RESULTSFROM SNOWFLAKE.ACCOUNT USAGE.CORTEX AI GUARDRAILS USAGE HISTORYWHERE GUARDRAILS SIGNAL = TRUE AND USAGE TIME = DATEADD 'hour', -72, CURRENT TIMESTAMP ORDER BY USAGE TIME DESCLIMIT 50; The AGENTIC SOURCE column identifies which surface triggered the detection: | Value | Surface || ---------------------- | ------------------------------- || CORTEX CODE SNOWSIGHT | Cortex Code in browser || CORTEX CODE CLI | Cortex Code CLI || CORTEX CODE DESKTOP | Cortex Code Desktop || CORTEX AGENT | Cortex Agents || SNOWFLAKE INTELLIGENCE | Snowflake Intelligence CoWork | This is useful for isolating whether a threat came from an interactive session or an automated agent. For a daily operational summary: WITH daily stats AS SELECT DATE TRUNC 'day', USAGE TIME AS scan date, AGENTIC SOURCE, COUNT AS total scans, SUM CASE WHEN GUARDRAILS SIGNAL THEN 1 ELSE 0 END AS flagged FROM SNOWFLAKE.ACCOUNT USAGE.CORTEX AI GUARDRAILS USAGE HISTORY WHERE USAGE TIME = DATEADD 'day', -14, CURRENT TIMESTAMP GROUP BY 1, 2 SELECT scan date, AGENTIC SOURCE, total scans, flagged, ROUND flagged / NULLIF total scans, 0 100, 2 AS flag rate pctFROM daily statsORDER BY scan date DESC, flagged DESC; End-to-end detection and alerting flow: User Request → Cortex Agent → Guardrail Scan → GUARDRAILS SIGNAL → ACCOUNT USAGE view → Alert Task → Email. Email notifications can be configured when flagged requests exceed a defined threshold. Snowflake ALERTs paired with SYSTEM$SEND EMAIL handle this without any external tooling. Important: Recipients in ALLOWED RECIPIENTS must be validated email addresses belonging to users in the account. If the email is not associated with a Snowflake user, the CREATE will fail. Verify with SHOW USERS check the EMAIL column . CREATE OR REPLACE NOTIFICATION INTEGRATION ai guardrail alerts TYPE = EMAIL ENABLED = TRUE ALLOWED RECIPIENTS = 'security-team@company.com' ;CREATE OR REPLACE ALERT guardrail detection alert WAREHOUSE = COMPUTE WH SCHEDULE = 'USING CRON 0 UTC' IF EXISTS SELECT 1 FROM SNOWFLAKE.ACCOUNT USAGE.CORTEX AI GUARDRAILS USAGE HISTORY WHERE GUARDRAILS SIGNAL = TRUE AND USAGE TIME = DATEADD 'hour', -1, CURRENT TIMESTAMP HAVING COUNT = 3 THEN CALL SYSTEM$SEND EMAIL 'ai guardrail alerts', 'security-team@company.com', 'AI Guardrail Alert: Multiple detections in last hour', 'Three or more prompt injection signals detected in the past hour. Review CORTEX AI GUARDRAILS USAGE HISTORY.' ;ALTER ALERT guardrail detection alert RESUME; The threshold of three detections per hour is conservative for most environments. The appropriate threshold depends on how many agents are deployed and how frequently they interact with external tools. Starting with a lower threshold and adjusting over time is generally recommended rather than risking missed early security signals. The surprise: The “Sensitive Data Accessed by Agent” finding. Organizations may invest in data classification — tagging PII columns with privacy categories — while overlooking one important detail: agents inherit their caller’s permissions and can read those columns in raw form. Classification without masking policies provides visibility without protection. The scanner makes that gap impossible to ignore. The limitation the documentation does not emphasize: The AI Security scanner package is in Preview. It works, runs daily, and generates real findings — but the scanner list may change. Alerting should be built around the current scanners with the understanding that future additions could shift the baseline. Also, the scanner package cannot currently be enabled programmatically through SQL — it is available only through the Trust Center UI Scanner Packages tab . Recommendation: Enable Cortex AI Guardrails and the AI Security scanner package together rather than separately. Guardrails without the scanner provide runtime protection but no posture visibility. The scanner without guardrails immediately reports a HIGH-severity finding indicating that guardrails are disabled. Enabling both during the same configuration session results in a cleaner initial scanner run and a more complete AI security posture. One more consideration: the CORTEX AI GUARDRAILS USAGE HISTORY view has up to a few minutes of latency. Sub-minute alerting should not be built against it. Hourly monitoring is the appropriate cadence for most environments. Going from a completely empty AI Security tab to full monitoring requires approximately 30 minutes of configuration. The challenge is not the implementation itself, but understanding how the available capabilities fit together. The AI Security scanner identifies configuration issues. Cortex AI Guardrails provide runtime protection against prompt injection and jailbreak attempts. The CORTEX AI GUARDRAILS USAGE HISTORY view delivers the operational audit trail needed for monitoring, investigations, and alerting. Together, these capabilities form the minimum viable AI governance layer for organizations running Cortex Agents in production. If the AI Security tab still shows all zeros, the environment is not necessarily secure — it may simply lack visibility. Follow me on Medium: Satish Kumar https://medium.com/u/d170d49944ec or on Linkedin: @satishkumar-snowflake Cortex Agents Left Unmonitored for a Month — Here’s What Trust Center Found https://pub.towardsai.net/cortex-agents-left-unmonitored-for-a-month-heres-what-trust-center-found-94bce70a3d39 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.