Researchers flag AI identity flaw in ServiceNow & Salesforce

Reco researchers said they had identified a security failure mode in ServiceNow and Salesforce involving AI agents triggered by records. The issue centres on how those agents decide which user they are acting for.

The research describes cases in which an agent begins work under the authority of a different user from the person who actually initiated the request. The researchers said this can happen when a platform resolves identity from fields on a record, the record owner, or the account that created the record through an automated process.

The finding does not rely on prompt injection, jailbreaking or stolen credentials. Instead, the researchers argue, the problem arises before a language model is involved, when the platform decides which identity the agent should use for a task.

In one scenario outlined in the research, an AI agent handling support tickets reads the requester field on a newly created record and then acts with that user's access. If a user can alter that field, or if the ticket is created through an email gateway, web form or other integration using an internal service identity, the agent may complete the task with permissions the real requester never had.

Reco said it confirmed the behaviour on ServiceNow and Salesforce using documented product features. It described the issue as a form of confused deputy problem, in which software uses its authority on behalf of the wrong person, and said it reflects configuration and design choices rather than software defects.

ServiceNow paths

On ServiceNow, trigger configurations can define user context in several ways, the researchers said, including a fixed user, a script that returns a user ID, or a field name on the triggering record. When a trigger reads a field such as caller_id or opened_by, the key question is who can write to that field.

Testing on one instance found that ordinary internal users could set some identity-related fields during record creation, even where access control settings suggested tighter restrictions, according to the research. In the example provided, a user submits an incident record through the Table API and supplies the sys_id of an Administrator in the caller_id field. The record is accepted and the field is populated, allowing an agent triggered by that insert to run with the Administrator's authority.

The researchers said some field restrictions failed silently: the record was created, the response returned a successful status, and unauthorised field writes were simply omitted. That can make the behaviour harder to detect because there is no explicit error for defenders to monitor.

For ServiceNow users, the research recommends pinning agents to fixed low-privilege accounts where possible, rather than allowing the principal to be drawn from writable record fields. Where dynamic resolution is unavoidable, it suggests script-based checks and controls such as data policies or before-insert business rules to normalise or reject unsafe values.

Salesforce flows

Salesforce reaches a similar result by a different route, the researchers said. In their testing, an agent invoked from a record-triggered flow ran as the same session user recorded as the creator of the record.

That matters most on external intake paths where there is no human user session to inherit. The research points to Email-to-Case and Web-to-Lead as examples. In Email-to-Case, an external sender can cause a case to be created under an internal configured identity. In Web-to-Lead, anonymous submissions are stamped with the Default Lead Creator account, which the researchers noted must hold broad permissions, including Modify All Data and Send Email.

The researchers also highlighted guest user scenarios, where ownership and creation can point to different identities. On guest-created Salesforce records, CreatedById may refer to a low-privilege guest account while OwnerId points to an internal user nominated by the organisation. In that case, neither identity necessarily represents the person who filled in the form, making both fields unreliable indicators of who the work is really for.

For Salesforce deployments, the report advises assigning any agent exposed to external record creation to a dedicated least-privilege internal account where the platform allows it. It also warns against treating OwnerId as the acting user on guest-created records.

Wider lesson

The broader argument is that record-triggered automation changes the trust model for AI agents. In chat-based interactions, a logged-in user gives the platform a clear identity to inherit or validate. In record-triggered workflows, the platform may have to infer identity from metadata that reflects how a record was created rather than who actually requested the work.

That means the main audit task is not limited to prompts, models and agent tools. Instead, the researchers said, security teams should map each agent trigger, identify every process that can create or modify the relevant records, and test which identities can be stamped onto those records and who can influence the fields the agent reads.

They concluded that the central question for enterprises is simple: “Point at the field, setting, or account that decides who your automation is. Then work out who can influence it, and whether that is the same set of people you would trust with that identity.”