Agent Permissions in Salesforce Workday Snowflake
Obsidian Security
The strategic edge is that application level permission maps show the real blast radius of an agent, not just that it made a request. In practice, that means building a live graph of who authorized a connector, which OAuth grants and tokens it holds, which role it inherits in systems like Snowflake, and which objects or admin actions that role can touch in Salesforce, Workday, or Snowflake. This is the layer where an agent changes payroll data, exports pipeline records, or queries sensitive tables.
-
Prompt and endpoint tools mainly see that a user or agent talked to an AI app, or that a browser or laptop sent data somewhere. They usually do not resolve the downstream app specific authority. Obsidian ingests OAuth grants, tokens, service accounts, roles, and actions, then ties them back to a common identity across apps.
-
The hard part is app specific semantics. In Snowflake, delegated authorization can pre authorize a role for a client integration, so the important question is not whether OAuth exists, but which role the token can activate and what data that role can read or change. The same logic applies in Salesforce and Workday, where useful security depends on object, field, and workflow level permissions.
-
This creates a different buying motion from classic SSPM. A security team can ask concrete questions across apps, like whether an employee built agent has more Salesforce access than the employee who triggered it, or whether a dormant service account still has broad access to HR and finance systems. That is why this approach expands from posture into runtime decisioning.
The next step is turning these permission maps into default deny controls for agent actions inside major SaaS systems. As more enterprise software exposes agent workflows through OAuth and delegated identities, the winning products will be the ones that can evaluate a planned action against the exact app role, data scope, and business workflow before the write happens.