Back

Inside Veza’s AI Agent Security for Salesforce Agentforce and Einstein Bots: A Technical Deep Dive

How Veza Models Every Bot, Run-As User, Profile, and Permission Set in a Single Access Graph

When we launched AI Agent Security for Salesforce Agentforce and Einstein Bots in December, we promised customers one thing: that every bot in their Salesforce org would show up in the Access Graph as a first-class identity — with the user it runs as, every Profile and Permission Set it inherits, and every object, field, and record it can reach traced end-to-end.

Five months in, the most common question we get from Salesforce admins and security architects is “show me exactly how it works.” This post is that walkthrough.

Key takeaways

  • Every Agentforce agent and Einstein Bot is an identity in Salesforce. Veza captures the bot definition as SalesforceBotDefinition and classifies it as an AI Agent in the Access Graph.
  • Bots inherit access through the Salesforce user they’re tied to. Profiles, Permission Sets, Permission Set Groups, and sharing rules apply to bots exactly as they do to humans.
  • Discovery is automatic. If Agentforce or Einstein Bots are configured in the org, Veza picks them up on the next extraction. No new connector, no separate datasource.
  • Inbound and outbound are both modeled. Who can invoke or administer each bot (inbound) and what objects, fields, and records it can read or write (outbound) live in the same graph.
  • Bot subtypes are first-class. A bot_definition_type property distinguishes Agentforce agents from classic Einstein Bots so you can filter, report, and run reviews on each independently.

Why Agentforce and Einstein Bots Need Identity-First Governance

Agentforce and Einstein Bots are not chat widgets. They open and close cases, update Accounts and Opportunities, run Apex actions, query custom objects, and read whatever the user or profile they’re tied to is allowed to read. They participate in the same IAM model as any other Salesforce identity — Profiles, Permission Sets, Permission Set Groups — and they inherit access through that identity exactly as a human would.

Yet most security teams cannot quickly answer:

Which bots exist, what user do they run as, and what objects and fields can they actually reach?

That’s the gap Veza closes. For every bot in your Salesforce org, Veza answers the question we were built to answer:

What can take what action on what data — across every AI Agent in Salesforce?

What Veza Discovers in Salesforce

Veza extends the existing Salesforce IAM integration to model bot definitions as first-class agents in the Access Graph. Discovery is automatic — if Agentforce or Einstein Bots are configured in the org, Veza picks them up on the next extraction.

The following entities and relationships are visible:

  • Bot Definitions — every bot defined in the org, captured as SalesforceBotDefinition and classified as an AI Agent
  • Bot subtype — the bot_definition_type property distinguishes Agentforce agents from classic Einstein Bots, so you can filter and report on each
  • The Salesforce user the bot runs as — resolved from the bot definition and connected into the standard Salesforce identity model
  • Profiles, Permission Sets, and Permission Set Groups — the same access bundles that govern human users now resolve to bots through their associated user
  • Object Permissions — read, create, edit, and delete on standard and custom objects, surfaced as effective permissions on the bot itself

A note on run-as semantics: each bot definition carries a BotUserId that resolves to the dedicated Salesforce user the bot runs as. Veza follows that link to map effective permissions; for bots that execute in the invoking user’s context instead, that path falls out of the standard Salesforce user-to-permission graph and is reasoned about there.

A Worked Example: A Service Cloud Agentforce Agent on Patient Records

Picture an Agentforce agent named patient-intake-agent running for a healthcare services org:

  • It’s tied to the bot user agentforce-intake@org.example.com
  • That user holds the Service Agent Profile and the Patient Intake PSG Permission Set Group
  • Through that PSG it has Read and Edit on the custom Patient__c object, including the SSN__c and Diagnosis__c fields
  • It can run an Apex action that posts to an external claims API
  • 47 Salesforce users across 6 profiles can invoke the agent through the customer-facing channel

Before Veza, surfacing all of that meant pulling Profile XML, Permission Set XML, sharing rule exports, bot config screens, and field-level security reports — and even then, no one could traverse it. With Veza, a security architect opens the Access Graph, types “show me what patient-intake-agent can read on Patient__c,” and gets the answer in one query — including the human invokers upstream.

That’s the difference identity-first modeling makes for AI agents on regulated customer data.

Answering Critical Security Questions

How do I see what an Agentforce bot can actually reach?

Agentforce and Einstein Bots do not hold permissions directly. They participate in Salesforce’s standard IAM model and inherit access through the user, profile, and permission sets they are associated with. Veza models that delegation as a clear graph path:

Salesforce Bot Definition → ASSOCIATED_WITH_USER → Salesforce User
                          → HAS_PROFILE / HAS_PERMISSION_SET → Profile / Permission Set
                          → HAS_EFFECTIVE_PERMISSION → Object / Field / Record

Questions answered in a single query:

  • Which bots can read or write the Account, Contact, Case, or Opportunity object?
  • Which bots can access custom objects holding regulated data — PII, PHI, payment data?
  • Does any bot inherit a profile or permission set with Modify All Data, View All Data, or other broadly privileged permissions?
  • Which bots share a Profile or Permission Set Group, and therefore share blast radius?

Who can invoke or manage these agents?

In Salesforce, the right to invoke or administer a bot flows through standard Profile and Permission Set assignments — bot-management permissions and channel-level visibility. Veza wires that into the graph:

Salesforce User → HAS_PROFILE / HAS_PERMISSION_SET → Permission
                                                  → ON_RESOURCE → Bot Definition

Questions answered:

  • Who in the org can invoke or administer each bot?
  • Which bots are exposed to a broad profile versus locked down to a specific permission set?
  • When a rep changes role, which bots do they retain — or lose — administrative access to?

What’s actually running under each bot?

Bots in Agentforce can invoke topics, actions, Apex, Flow, and external services. Veza inventories the bot definitions and the user identities they run as, so you can see the full surface area of what each bot is configured to do — and govern it the same way you govern any other identity that touches Salesforce data.

Questions answered:

  • Which bots are active, and which are draft or deactivated?
  • Which bots run as a dedicated bot user versus the invoking user’s context?
  • Where Agentforce agents are wired to platform models, which capabilities are bound and how broad is their data reach?

What This Unlocks for Security and IAM Teams

For every Salesforce bot, Veza surfaces:

  • The bot and the Salesforce user identity it runs as
  • The Profiles, Permission Sets, and Permission Set Groups it inherits through that identity
  • The standard and custom objects it can effectively reach
  • The bot subtype — Agentforce versus Einstein — for clean reporting and review scoping
  • Who in the organization can invoke or administer each bot

That visibility plugs into everything Veza already does:

  • Access Reviews — bots become reviewable entities alongside humans and integration users, with the same campaign cadence and reviewer assignments
  • Blast Radius — over-privileged bots surface against the same risk model as any other identity in Salesforce
  • Rules & Alerts — trigger on a new bot without an owner, a bot tied to a profile with Modify All Data, or a bot newly granted access to a sensitive custom object
  • Access Graph search — natural-language and graph queries traverse the full chain from human invoker to bot to record

Compliance teams care because this maps directly to SOX, HIPAA, GDPR, and PCI requirements for least-privilege access and audit-ready evidence on AI-driven access to customer records.

Frequently Asked Questions

Do I need a new connector to enable Veza for Agentforce or Einstein Bots? No. If you already have the Veza Salesforce IAM integration in place, bot discovery is automatic on the next extraction. There’s no separate connector, no additional datasource, and no agent runtime to deploy.

Does Veza distinguish Agentforce agents from classic Einstein Bots? Yes. The bot_definition_type property on each SalesforceBotDefinition distinguishes them, so you can filter, report, and scope reviews on each independently.

How does Veza handle the dedicated bot user a bot is tied to? Each SalesforceBotDefinition carries a BotUserId that points at the Salesforce user the bot runs as. Veza follows that link into the standard Salesforce identity graph so a reviewer can see exactly what that user can read or write. For bots executing in the invoking user’s context, the same Salesforce user-to-permission graph already captures what that human can do.

Can I run access reviews on bots the same way I do for human users? Yes. Bots become reviewable entities in Veza Access Reviews, with the same campaign cadence, reviewer assignment, and risk-based prioritization you already use for humans and integration users.

Does Veza alert when a bot is tied to an over-privileged profile? Yes. Rules & Alerts can trigger on bots inheriting Modify All Data, View All Data, profile-wide PSGs, or any custom risk pattern your team defines.

Does Veza model object-level permissions on custom objects? Yes. Read, create, edit, and delete permissions on both standard and custom objects surface as effective permissions on the bot itself — including custom objects holding PII, PHI, or payment data.

Getting Started

Veza AI Agent Security for Salesforce Agentforce and Einstein Bots is generally available for existing Salesforce IAM integrations. Once Agentforce or Einstein Bots are configured in the org, Veza picks up bot definitions and their associated users on the next extraction.

Related Reading

Veza Expands AI Agent Security to Azure AI Foundry (launch blog)

Inside Veza’s AI Agent Security for Microsoft Copilot Studio (deep dive)

Inside Veza’s AI Agent Security for Amazon Bedrock Agents (deep dive)

Inside Veza’s AI Agent Security for Google Cloud Vertex AI (deep dive)

Table of Contents