How should security teams govern AI agents that inherit access through human identities in Salesforce?

Treat AI agents as separate NHIs, not extensions of the user. NHI Mgmt Group recommends mapping every inherited permission to an owning human account, then enforcing least privilege with RBAC, ABAC, and JIT access for the agent’s runtime. Remove shared credentials, require strong authentication, log every action to the user and agent, and continuously review delegated access for drift, overreach, and orphaned privileges.

Why inherited Salesforce access should be governed as agent authority, not user convenience

When an AI agent inherits access through a human identity in Salesforce, the practical question is not whether the agent can technically act under that account, but whether its authority is bounded, attributable, and revocable. Treating the agent as an extension of the user blurs ownership, weakens auditability, and makes privilege creep easier to miss when workflows expand.

The safer model is to govern the agent as its own actor with explicit delegated authority, even if the initial permission source is a human account. That lets teams separate who owns the access from who exercises it, which is critical when agents start reading records, updating objects, triggering automations, or chaining into connected apps and APIs. The Salesforce Security Guide is useful here because Salesforce environments tend to accumulate access through profiles, permission sets, connected apps, and review exceptions rather than through one clean control point.

In practice, the inherited permission should be translated into a governed entitlement for the agent, not left as an implicit side effect of the human user’s role. That matters because Salesforce access often spans business data, automation, and integration paths, so a single overbroad grant can become both a confidentiality issue and a workflow integrity issue.

What “least privilege” means once an agent is acting inside Salesforce

Least privilege for an AI agent is narrower than the user’s full human access. The agent should receive only the objects, fields, actions, and time window required for the task, with explicit constraints on when it may act autonomously and when it must pause for human approval. A good implementation should distinguish read, write, export, and administrative capabilities instead of assuming a role bundle is safe because a person currently uses it.

RBAC is the starting point for stable baseline permissions, but agent governance usually needs ABAC as well because task context changes fast. If the agent’s action depends on case status, customer tier, environment, or data sensitivity, policy should evaluate those conditions at runtime rather than relying on a static profile. JIT access is the right pattern when the agent only needs elevated capability briefly, because standing privilege is what usually turns a harmless automation into a persistent exposure.

The AI Agent Authorisation Guide is directly relevant because it frames task-scoped access, per-action policy decisions, and human approval as the core design choices for agents that act on behalf of people. That same logic applies cleanly to Salesforce when an agent is operating through inherited user access.

How to keep inherited access observable, revocable, and safe over time

Teams need to log the actor, the initiating human, the agent instance, and the specific action taken. Without that split attribution, you cannot tell whether a record change came from the user, the agent, or an automation chain that reused the same session or token. Logging also helps detect drift, such as an agent slowly acquiring access paths that were never intended for its original use case.

Strong authentication still matters, but the control objective changes once an agent is involved. The question is not only whether the user authenticated, but whether the delegated session, token, or connected app can be abused after the user is gone, the task is complete, or the agent has drifted into a broader role. The Zero Trust for AI Agents guide captures the right posture here: verify the principal and request continuously, and remove standing privilege wherever possible.

Salesforce access should also be reviewed as a lifecycle problem, not a one-time approval. If the human owner changes role, leaves the organisation, or no longer sponsors the agent’s use case, the delegated access should expire with it. The AI Agent Observability, Audit and Incident Response Guide is relevant because it emphasises attribution, kill switches, and revocation when an agent begins behaving outside its expected envelope.

Risk and Threat Considerations

Inherited human access creates a privilege-concentration risk: one user account can quietly become the control plane for a machine actor with far more persistence and speed than the original human. If that account is overprovisioned, shared, or insufficiently monitored, the agent can inherit excessive access, and the blast radius can be larger than teams expect.

Failure mechanism: the agent reuses a human session, token, or connected-app grant without a separate authority boundary, so inherited privilege persists after the original business need changes. Attackers or internal misuse can then exploit that trust chain to read, modify, or export Salesforce data at scale.

Impact: unauthorised updates, data exposure, workflow corruption, and weak attribution become more likely, and incident response is harder because the logs may show a legitimate user context even when the agent performed the action.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	Inherited Salesforce access can overextend an agent's effective privilege.
	NHI-07 — Long-Lived Secrets	Delegated Salesforce access often persists through tokens or grants longer than intended.
Recommendation — Restrict agent permissions to the minimum Salesforce actions the task requires. Expire delegated credentials and rotate any secret that enables agent access.
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	The subject is an agent acting through a human identity and inheriting authority.
Recommendation — Bind each agent action to explicit delegated authority and separate it from the human identity.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Inherited access depends on controlling the lifecycle of tokens, secrets, and sessions.
	AC-6 — Least Privilege	Least privilege is central to constraining agent actions in Salesforce.
Recommendation — Manage, expire, and revoke the authenticators that let the agent act in Salesforce. Limit the agent to only the Salesforce permissions needed for the current task.

Practitioner Guidance

What to prioritise: separate ownership from execution. Map each inherited Salesforce permission to a named human owner, then define which actions the agent may perform autonomously and which must require approval. If you cannot name the owner of a permission, treat it as orphaned access and remove it.

What to verify: confirm that the agent does not rely on a shared credential, that its permissions are task-scoped, and that the audit trail distinguishes human initiation from agent execution. The control is not working if you can only see the user identity and not the delegated actor.

Practitioner takeaway: the security goal is not to make the agent look like the user, but to make delegated access smaller, time-bound, and attributable so that Salesforce automation can be governed like a distinct identity problem rather than an invisible extension of human privilege.