Topic starter
11/11/2026 6:05 pm
TL;DR: Reviewer friction comes from unresolved human attribution and shared agent credentials, not from the Cortex workflow itself, according to TrustLogix. For practitioners, the control question is whether each request can be tied to identity, entitlement and declared purpose before data access is allowed.
Editorial analysis by NHI Mgmt Group, based on content published by TrustLogix: “Extending Snowflake's Identity Model to AI Agents”.
Key questions
Q: What is the difference between RBAC for humans and access control for AI agents?
A: RBAC for humans groups people into roles that usually reflect job function.
Q: How do AI agents get attributed in audit logs?
A: AI agents are attributed in audit logs by recording the agent identity, the acting service account or token, the tool call, and the human owner or delegate responsible for the action.
Q: What are the best practices for least privilege enforcement for AI agents?
A: Least privilege enforcement for AI agents means granting only the minimum data, tools, and actions needed for the current task.
Practitioner guidance
- Resolve agent requests to human identity Require on-behalf-of token exchange for agent workflows so every data request carries attributable human context into review and audit.
- Separate entitlement from purpose checks Use ABAC for baseline eligibility, then add a request-purpose decision step for agent actions that can touch sensitive or regulated data.
- Keep policy inside the data platform Apply native masking and row-access policies at the object layer so sensitive data remains governed even when the agent runtime changes.
Bottom line: AI agent governance fails when reviewers cannot connect a request to a human identity, even if the platform can authenticate the call.
Glossary terms: On-behalf-of Token, Managed MCP Server, Attribute-Based Access Control, Policy decision point
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/11/2026 6:07 pm
Attribution, not authentication, is the governance fault line for AI agents. A platform can authenticate an agent and still leave reviewers unable to answer who actually initiated the request. That is why shared service credentials create friction in regulated workflows: identity exists, but accountability does not travel cleanly with the call. Practitioners should treat traceable attribution as a control requirement, not a reporting convenience.
A few things that frame the scale:
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: When should teams require request-purpose checks for agents?
A: Teams should require request-purpose checks whenever an agent can access sensitive data, trigger external actions, or choose between tools with different risk levels. The check compares the stated purpose against policy before execution, so the runtime can block off-scope calls, require human approval for unusual requests, and keep delegated authority aligned to the approved task.
👉 Read our full editorial: Intent-aware gateway controls make AI agent access reviewable