{"slug": "cortex-agents-left-unmonitored-for-a-month-heres-what-trust-center-found", "title": "Cortex Agents Left Unmonitored for a Month — Here’s What Trust Center Found", "summary": "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.", "body_md": "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.\n\nThe 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.\n\nThis 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.\n\n*The AI Security tab before any configuration — a complete blind spot.*\n\n*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.*\n\nAn initial attempt to enable guardrails may fail silently — the parameter accepts the value but guardrails do not actually scan anything.\n\nThe 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:\n\n```\nALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'ANY_REGION';\n```\n\nValid 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.\n\nThe 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:\n\n```\nGRANT APPLICATION ROLE SNOWFLAKE.TRUST_CENTER_ADMIN TO ROLE trust_center_admin_role;\n```\n\nOne 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.\n\nThe enablement itself is straightforward. One statement protects Cortex Code, CoWork, and all Cortex Agents in the account simultaneously:\n\n``` bash\nALTER ACCOUNT SET AI_SETTINGS = $$  guardrails:    advanced_prompt_injection:      - enabled: true$$;\n```\n\nVerify it took effect:\n\n```\nSHOW PARAMETERS LIKE 'AI_SETTINGS' IN ACCOUNT;\n```\n\n*Confirming guardrails are active account-wide.*\n\nWhat 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.\n\nOne 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.\n\nTo disable guardrails (if needed):\n\n```\nALTER ACCOUNT UNSET AI_SETTINGS;\n```\n\nThe 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:\n\nCortex 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.\n\nCortex 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.\n\nSensitive 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.\n\nGuardrails Not Enabled — Before the ALTER ACCOUNT statement is applied, this shows as a violation. After enabling, it clears on the next scanner run.\n\nThe 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.\n\nFind all flagged requests from the last 72 hours:\n\n```\nSELECT 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;\n```\n\nThe AGENTIC_SOURCE column identifies which surface triggered the detection:\n\n```\n| 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) |\n```\n\nThis is useful for isolating whether a threat came from an interactive session or an automated agent.\n\nFor a daily operational summary:\n\n```\nWITH 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;\n```\n\n*End-to-end detection and alerting flow: User Request → Cortex Agent → Guardrail Scan → GUARDRAILS_SIGNAL → ACCOUNT_USAGE view → Alert Task → Email.*\n\nEmail notifications can be configured when flagged requests exceed a defined threshold. Snowflake ALERTs paired with SYSTEM$SEND_EMAIL handle this without any external tooling.\n\n*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).*\n\n```\nCREATE 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;\n```\n\nThe 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.\n\nThe 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.\n\nThe 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).\n\nRecommendation: 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.\n\nOne 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.\n\nGoing 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.\n\nThe 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.\n\nTogether, these capabilities form the minimum viable AI governance layer for organizations running Cortex Agents in production.\n\nIf the AI Security tab still shows all zeros, the environment is not necessarily secure — it may simply lack visibility.\n\nFollow me on Medium: [Satish Kumar](https://medium.com/u/d170d49944ec)\n\nor on Linkedin: @satishkumar-snowflake\n\n[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.", "url": "https://wpnews.pro/news/cortex-agents-left-unmonitored-for-a-month-heres-what-trust-center-found", "canonical_source": "https://pub.towardsai.net/cortex-agents-left-unmonitored-for-a-month-heres-what-trust-center-found-94bce70a3d39?source=rss----98111c9905da---4", "published_at": "2026-09-14 05:49:27+00:00", "updated_at": "2026-09-14 05:57:58.779926+00:00", "lang": "en", "topics": ["ai-safety", "ai-agents", "ai-policy", "ai-products"], "entities": ["Snowflake", "Cortex AI Guardrails", "Cortex Agents", "Trust Center", "CoWork", "CORTEX_AI_GUARDRAILS_USAGE_HISTORY", "SNOWFLAKE.TRUST_CENTER_ADMIN", "Cortex Search Services"], "alternates": {"html": "https://wpnews.pro/news/cortex-agents-left-unmonitored-for-a-month-heres-what-trust-center-found", "markdown": "https://wpnews.pro/news/cortex-agents-left-unmonitored-for-a-month-heres-what-trust-center-found.md", "text": "https://wpnews.pro/news/cortex-agents-left-unmonitored-for-a-month-heres-what-trust-center-found.txt", "jsonld": "https://wpnews.pro/news/cortex-agents-left-unmonitored-for-a-month-heres-what-trust-center-found.jsonld"}}