AI Agents Can Inherit the Wrong Identity on ServiceNow and Salesforce

By Sophie Lindqvist

Reco researchers confirmed on ServiceNow and Salesforce that record-triggered AI agents can run with another user's authority, including a ServiceNow Administrator. Their report, dated Nov. 13, 2026, says the failure can begin before a language model receives the request.

For enterprises, Reco’s finding turns record metadata into an access-control decision. A request can trigger an agent, but the agent may then read or change data with permissions the actual requester never had.

Reco called the pattern a “confused deputy problem,” in which software uses its authority on behalf of the wrong person. The company said the finding reflects configuration and design choices, not software defects, and that researchers reproduced it with documented product features.

This is not a prompt-injection story. Reco said the issue requires no prompt injection, jailbreaking or stolen credentials. The platform resolves an identity first, then lets the agent act under that identity.

How does record-triggered automation pick the wrong identity?

Reco’s central argument is that record-triggered workflows change the trust model for AI agents. In a chat interaction, a logged-in user gives the platform an identity to inherit or validate. In a record workflow, the platform may infer identity from metadata about how the record was created.

That distinction matters because creation metadata can describe a system or internal account, not the person who asked for the work. Reco said identity resolution can draw from a record field, the record owner, or the account that created the record through automation.

In one support-ticket scenario from the research, an agent reads the requester field on a newly created record. It then acts with that user's access. If the requester can alter the field, the agent may receive more access than that person actually holds.

Reco also identified email gateways, web forms and other integrations that create records with an internal service identity. In those cases, the agent inherits an internal account even though the original request came from outside the platform.

In plain terms, the identity on a record may reflect system plumbing rather than the requester’s intent. Reco said teams must treat trigger configuration as part of the permission model.

What lets a ServiceNow agent act as an Administrator?

On ServiceNow, a trigger can define its user context in three ways, according to Reco’s research:

• A fixed user.
• A script that returns a user ID.
• A field name on the triggering record.

The security question then becomes who can write to the selected field. Reco singled out fields such as caller_id and opened_by, because a trigger that reads either one may use its value to choose the agent’s principal.

Testing on one instance found that ordinary internal users could set some identity-related fields during record creation. That happened even where access-control settings suggested tighter restrictions, according to Reco.

In the clearest test, a user submitted an incident record through the Table API. The user supplied the sys_id of an Administrator in the caller_id field. ServiceNow accepted the record and populated the field, allowing an agent triggered by the insert to run with the Administrator’s authority.

Some field restrictions failed silently, Reco found. The record was created and the API returned a successful status, but ServiceNow omitted the unauthorized field write. Because no explicit error appeared, defenders had less signal for detecting the attempt.

Reco recommends pinning agents to fixed, low-privilege accounts where possible. If dynamic identity resolution remains necessary, its researchers suggest script-based checks, data policies or before-insert business rules to normalize or reject unsafe values.

Reco’s practical takeaway is simple: a writable record field should not choose an AI agent’s privileged identity. ServiceNow teams that need dynamic resolution should add an explicit check between record creation and agent execution.

How does Salesforce produce the same result?

Reco found a similar result through a different route on Salesforce. In testing, an agent invoked from a record-triggered flow ran as the same session user recorded as the record’s creator.

That route matters most on external intake paths, Reco said, because no human user session exists to inherit. The flow instead uses the creation identity stored on the record, and the question is which one the metadata supplies.

With Email-to-Case, Reco said an external sender can cause a case to be created under an internal configured identity. The agent then receives that internal identity without the sender holding its permissions.

Web-to-Lead produces a more explicit default. Reco said anonymous submissions are stamped with the Default Lead Creator account. That account must hold broad permissions, including Modify All Data and Send Email.

Guest records add a third mismatch, according to Reco. A guest-created record may have a low-privilege guest account in CreatedById, while OwnerId points to an internal user nominated by the organization. Neither field necessarily identifies the person who filled in the form, Reco said.

For Salesforce deployments, the report advises assigning an 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.

On Salesforce, a risky identity can arrive through routine intake settings rather than a fake login. Reco’s guidance focuses on controlling the account used for external automation, not on prompts submitted to the model.

What should security teams audit before an agent runs?

Reco said the main audit task extends beyond prompts, models and agent tools. Teams need to map the path from a record’s creation to the identity an AI agent inherits.

The research recommends a specific sequence:

• Map each agent trigger and the field, script, owner or account it uses for user context.
• Identify every process that can create or modify the relevant records.
• Test which identities those processes can stamp onto a record.
• Find out who can influence the fields that the agent reads.
• Compare the people who can influence those fields with the people trusted to hold the selected identity.

Reco summarized the review in one instruction: “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.”

That test applies before an agent acts, Reco said, because record-triggered workflows can silently choose a more privileged identity. A security review that stops at the model or prompt can miss the account that actually carries the request.

For teams deploying these agents now, Reco’s practical question is whether the principal comes from a fixed, trusted source. If it comes from a writable field or default intake account, the workflow needs a least-privilege identity or an explicit validation step.