# Cortex Agents Left Unmonitored for a Month — Here’s What Trust Center Found > Source: > Published: 2026-09-14 05:49:27+00:00 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.