Confused Trigger Part 1: When an Outsider Borrows an Agent's Authority

An outsider can borrow your agent's authority without ever holding credentials. The intake trigger is the way in. I call it a Confused Trigger.

‍

It is the classic confused deputy problem, updated for an enterprise workforce powered by autonomous agents. The agent is the deputy because it holds privileges the outsider could never obtain directly, and the intake trigger is how they borrow that authority. There is no zero-day, buffer overflow, or exotic exploit payload here. Every single software component can work exactly as the platform vendor documented, while the combined workflow punches right through a trust boundary nobody intentionally approved.

‍

How It Happens: The Identity Seam

‍

Think about how enterprise intake actually works. Public web forms, inbound support emails, and partner portals exist specifically to take untrusted input from the outside world. An external visitor submitting a contact form that kicks off an intake process is standard business automation. The failure occurs when that submission causes actions beyond the submitter's authorization or the workflow’s intended scope.

‍

Two distinct conditions can produce that failure, and they operate on completely different planes:

‍

Authority (The Confused Deputy): The agent executes with more privilege than the submitter should reach, and its tools act on submitter-supplied data. For example, a downstream tool looks up an account or contact using an email address from the form. An elevated agent can return or modify data the submitter has no right to inspect, with zero manipulation of the underlying model. That is textbook confused deputy.

‍

Steering (Prompt Injection): Untrusted text lands in the agent’s context window, and a prompt injection influences which tools the agent calls and with what arguments. This path depends on model comprehension and semantic parsing. Elevated authority makes the resulting blast radius catastrophic.

‍

Both paths only matter if the agent holds elevated authority. That brings us to the core architectural question: which identity does the agent resolve to?

‍

The enterprise platform vendors document the individual pieces. Salesforce requires a Web-to-Lead Default Lead Creator to hold ‘Modify All Data’ and ‘Send Email’ permissions. Its Automated Case User—attributed to automated case actions including Web-to-Case creation—must hold ‘Modify All Data’, ‘Send Email’, and ‘Access Activities’. Those privileged intake accounts exist by platform design. 

‍

Agent execution identity, however, is a separate matter. In Salesforce, agents invoked through record-triggered Flows run as the transaction's session user—which, on intake paths, inherits the Default Lead Creator or Automated Case User. In ServiceNow AI Agent Studio, triggers configured in ‘sn_aia_trigger_configuration’ can resolve the execution principle dynamically from record fields (such as ‘caller_id’ or ‘opened_by’) or execute as dedicated service accounts.

‍

On their own, none of these platform settings represent an exploit. The exposure sits where unauthenticated intake records and autonomous agent execution meet.

‍

The "Hardcoded Script" Mental Model: Why This Is Not Prompt Injection

‍

Whenever I describe this failure mode to security leaders, the immediate instinct is to file it under indirect prompt injection. That is a dangerous categorization mistake. Confusing the two causes security teams to deploy defenses in the wrong place, leaving the actual vulnerability wide open.

‍

Indirect prompt injection is an attack on the model context window. An adversary plants malicious text in an email body, ticket description, or web document, hoping the model interprets that data as instructions. The attack runs entirely through semantic parsing.

‍

A Confused Trigger does not involve the model at all during identity resolution. The identity is resolved at the trigger layer before the language model is ever invoked. The record field is evaluated, the session principal is stamped, and the agent initializes already running under that authority. Nothing the agent reads needs to be hostile. The agent is given truthful instructions about its task and lied to by the platform architecture about who requested the work.

‍

The cleanest proof of this distinction is a simple thought experiment: take the model out of the architecture entirely.

‍

If you replace the autonomous agent with a hardcoded Python script that reads the requester field, looks up their entitlements, and executes actions on their behalf, prompt injection ceases to exist. There is no model to manipulate, no semantic ambiguity, and nothing to inject into. Yet the Confused Trigger survives completely intact. The script still runs under the authority of the forged or inherited identity, and sensitive data is still exposed.

‍

This is why point guardrails, input sanitization, delimiter tagging, and output filters fail to catch this. In our research on where agents come from, we found that agents deployed inside third-party environments fail through architectural trust paths because none of those point tools inspect the identity binding between the intake trigger and runtime execution. The agent's guardrails hold, its system prompt remains pristine, and it executes its job faithfully. It simply does so on behalf of the wrong principal.

‍

Proof Matrix: Telemetry from Test Org Runs

‍

‍

Key finding from telemetry: In the ServiceNow scenario, `task.opened_by` carried an admin-only write ACL. However, at record insert via the Table API, the field security check failed silently—the API returned HTTP 201 Created, accepted the unauthenticated value, and triggered downstream execution without generating a single security alert.

‍

The Real Enterprise Blast Radius: Three Critical Seams

‍

To understand why Confused Triggers represent a systemic executive risk, consider an everyday enterprise scenario: an inbound lead qualification workflow.

‍

For fifteen years, marketing teams have embedded Web-to-Lead forms on public websites. An anonymous prospect submits their contact information. A lead record is created in Salesforce. Historically, that record sat in a queue until a sales development representative manually reviewed it.

‍

Today, the enterprise introduces an autonomous agent to enrich and route inbound leads. A record-triggered Flow fires on every new Lead insert and passes execution to the agent. The submitter on the public internet controls several fields, including open-ended text fields. The business team scoped this project simply to accelerate lead qualification.

‍

When viewed through an architectural security lens, three seams emerge:

‍

1. The Identity Disconnect: Enterprise platforms track who created a record (‘CreatedById’) separately from who owns it (‘OwnerId’). On web and guest forms, those point to completely different entities. In Salesforce digital experience sites, ‘CreatedById’ is a low-privilege guest user, while ‘OwnerId’ defaults to a nominated internal administrator. If a downstream agent inherits authority from ‘OwnerId’, an anonymous web visitor commands an agent executing with administrative access.

‍

2. The Agent's Data Reach: If the agent can only read the lead and stamp a routing picklist value, exposure is contained. But if the agent has access to query related Accounts, inspect Opportunities, update contacts, or call out through connected enterprise tools, that anonymous form submission sits directly in front of core enterprise data.

‍

3. The Content Plane: Unvalidated text from the outside world feeds straight into the agent's context window. When an external prompt injection is combined with an execution context holding administrative authority, the attacker is no longer merely manipulating text. They are commanding an internal administrative session.

‍

Email-to-Case, Web-to-Case, and ServiceNow ticket intake follow this exact anatomy. An inbound event creates a record, a trigger fires, and an execution context gets assigned. It is the default automation pattern across the modern enterprise.

‍

The Limits of Point Defenses: Why Proxies and Static Scanners Fall Short

‍

Most enterprise security programs attempt to address agentic risk using legacy security tooling or narrow point controls:

‍

Network Proxies and Perimeter Firewalls: Proxies inspect external HTTP traffic. But once a web form submission or API call lands legally on a public-facing endpoint, the proxy’s job is complete. It has zero visibility into how internal database events trigger downstream autonomous agents.

‍

Prompt Firewalls and LLM Guardrails: Content filters inspect conversational text for malicious patterns. But as demonstrated by the hardcoded script model, a Confused Trigger subverts the runtime execution identity before prompt evaluation occurs. The prompt itself can be completely benign.

‍

Static Posture Scanners (Legacy SSPM): Periodic posture scanners inspect static configuration settings against vendor compliance baselines. But because the Default Lead Creator or ServiceNow AI User is configured exactly as vendor documentation prescribes, static scanners mark the configuration as compliant. They cannot map the dynamic, cross-application relationship between an unauthenticated webhook, a record-triggered workflow, and the privileged data reach of an autonomous agent.

‍

Practical Controls

‍

Platform administrators must keep intake accounts privileged because platform architecture requires it. The operational objective is keeping that authority out of agent execution. Security teams can implement six architectural controls immediately:

‍

1. Decouple Execution from Intake Creators: Never allow an externally triggered agent to resolve to the Default Lead Creator, Automated Case User, or any identity derived from an externally writable field. Pin the agent to a dedicated, least-privilege execution principal.

‍

2. Enforce Least Privilege and Understand Masking Trade-Offs: Dedicated agent service accounts require strictly scoped permissions. Dynamic agents require role masking (such as ServiceNow ‘sys_agent_access_role_configuration’). However, recognize that role masking narrows reach (the dial) without fixing the identity seam (the gate), and cannot be configured for ServiceNow components executing as dedicated AI users.

‍

3. Treat ‘OwnerId’ and External Fields as Untrusted: On guest and public web forms, ‘OwnerId’ is an internal account and ‘CreatedById’ is a guest user—neither represents the submitter. Never resolve execution identity or access scope from unauthenticated record metadata.

‍

4. Scope Tool Parameters Strictly: Hardcode tool filters and query parameters so submitter-supplied values cannot widen what an agent reads or modifies. An agent qualifying leads has no architectural justification for querying broader CRM Account tables.

‍

5. Enforce Human-in-the-Loop Approval Gates on High-Impact Tools: Require explicit runtime approvals for consequential actions, including bulk data exports, record deletion, privilege assignments, and external API mutations.

‍

6. Audit the Complete Operational Chain: Evaluate the entire path from submission to tool execution. Reviewing configuration settings in isolation misses the vulnerability created by how they interconnect.

‍

A Systemic Solution

‍

To close the Confused Trigger gap permanently, security organizations must move beyond point interception and periodic posture audits. Autonomous agents require continuous, identity-first governance across the third-party ecosystem.

‍

This is why we built the Reco Graph:

‍

Continuous Ecosystem Mapping: Reco continuously maps every human identity, autonomous agent, third-party application, and permission chain into a single, unified risk plane. Across more than 290 integrations and over 1,000 detection controls, Reco detects agent proliferation and uncovers hidden execution paths.

‍

Trigger Provenance & Identity Binding: The Reco Graph analyzes the end-to-end operational chain: tracing an event from its external ingress point (e.g., Salesforce Web-to-Lead, ServiceNow Table API) through execution context assignment, directly identifying where untrusted inputs trigger privileged internal sessions.

‍

Cross-Application Blast Radius Analysis: Unlike legacy per-application posture checkers, Reco evaluates what an agent can reach downstream—mapping effective permissions across Salesforce, ServiceNow, cloud data warehouses, and internal APIs. When an agent holds excessive data access or destructive tool permissions, Reco surfaces the deviation and provides automated precision remediation.

‍

Dual Coverage Across Sockets and Cloud: Reco provides full visibility across local developer ‘stdio’ subprocesses and cloud ‘SSE’ connections, ensuring complete oversight wherever agents are authored, tested, or deployed.

‍

Standing Behind the Deployment

‍

A lot of security conversations stop at whether each configuration setting matches vendor documentation. But \"working as documented\" does not mean the combined system is safe.

‍

A compliance auditor asks whether controls exist on paper. A Chief Security Officer asks whether the business can stand behind the decision to deploy.

‍

As organizations navigate the intersection of identity, third-party applications, and agentic governance—retiring legacy SSPM silos in favor of unified Agent Security—I hold our teams to four operational baselines before approving any agent wired to external triggers:

‍

A Single Named Owner: Someone who is personally accountable for what the agent can do, possesses the authority to disable it, and owns the residual risk. Vulnerabilities thrive when ownership is fragmented across platform administrators, business units, and security teams.

‍

Evidence Over Assurances: A live, continuous inventory of external triggers, the identity each runs under, and actual telemetry from the Reco Graph. A vendor stating their platform works as designed tells me nothing about how our internal teams configured it.

‍

Defined Risk Thresholds: Agents that only classify or route text can move rapidly with lightweight guardrails. Agents that touch sensitive customer data, modify records, or connect to external systems from an external trigger require explicit architectural sign-off and runtime gates.

‍

An Incident Story That Holds Up: If an external input causes an agent to take an unauthorized action, I must be able to tell our board, our customers, and regulators exactly who started it, what was affected, and how it was contained.

‍

We should keep adopting agents. But we have to build on evidence: knowing exactly who can start an action, whose authority it borrows, what systems it can touch, and who is on the hook when something breaks.

‍

Technical Deep Dives in This Series

‍

For engineering teams and platform architects responsible for securing these workflows directly in code, explore the technical teardowns in this series:

‍

Confused Trigger Part 2: Breaking Down Salesforce Web-to-Lead and Agentforce Flows 

A code-level guide to Flow execution contexts, guest record ownership splitting, and securing Agentforce Apex actions.

‍

Confused Trigger Part 3: Exploiting ServiceNow AI Agent Studio via Table API

A deep dive into REST Table API field security, ‘sn_aia_trigger_configuration’ audit scripts, and role masking implementations.

‍