ForcedLeak shows how prompt injection breaks AI CRM trust boundaries

At a glance

What this is: Noma Security’s analysis of ForcedLeak shows how indirect prompt injection can turn routine CRM data handling into a data exfiltration path through AI agents.

Why it matters: It matters because IAM, PAM, and AI governance teams now have to treat user-controlled content, agent permissions, and outbound data flows as one control problem.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Noma Security's analysis of the ForcedLeak AI agent vulnerability

Context

ForcedLeak is best understood as an AI agent governance failure rather than a narrow application bug. The core issue is that AI systems can be prompted by untrusted content, then execute actions inside trusted enterprise workflows with more authority than the original data source should ever receive. In identity terms, that creates a provenance problem: the system cannot reliably distinguish a legitimate business request from attacker-supplied instructions embedded in ordinary records.

For IAM and NHI programmes, the article lands on a familiar but newly urgent boundary. AI agents behave like privileged runtime actors when they can read customer data, call tools, and send data outward, so access decisions must account for both input trust and output control. This is now a governance problem for CRM owners, AI security teams, and identity teams together, not an isolated AI feature issue.

Key questions

Q: How should security teams reduce indirect prompt injection risk in AI systems?

A: Security teams should limit what AI systems can read, separate untrusted content from privileged actions, and apply least privilege to every connected agent. The strongest posture combines content filtering, allowlisted sources, short-lived sessions, and explicit approval for sensitive actions. If any one of those layers is missing, the attack path remains open.

Q: When does AI governance become an IAM and NHI problem?

A: It becomes an IAM and NHI problem as soon as autonomous systems use credentials, APIs, or delegated access to perform actions. At that point, the quality of identity assignment, privilege scope, logging, and lifecycle control determines whether the system can be governed and audited responsibly.

Q: What do security teams get wrong about trusted URL allow lists?

A: They often treat an allow list as a complete exfiltration control when it only narrows destinations. A capable attacker can still use permitted outbound paths to move sensitive information if the AI agent is allowed to assemble or relay data. Egress policy, content inspection, and action scope all have to work together.

Q: Who is accountable when an AI agent accesses sensitive data it was not meant to use?

A: Accountability sits with the team that approved the agent, its connectors, and its policy boundaries, not with the runtime behaviour alone. Organisations need ownership for intent, permissions, monitoring, and validation so they can prove whether the agent stayed inside its approved purpose. Without that, audit and regulatory response become retrospective guesswork.

Technical breakdown

How indirect prompt injection turns trusted data into instructions

Indirect prompt injection occurs when attacker-controlled text is stored in a system that the AI later reads as if it were normal business content. The payload does not need to look like a command to a human. The dangerous part is that the model or agent may treat the content as instructions during a later user query, especially when the application merges user intent with retrieved records. That collapses the trust boundary between data and control plane. In CRM and ticketing workflows, any field that can later be retrieved by an AI agent becomes a potential instruction carrier.

Practical implication: classify user-controlled fields as untrusted inputs even when they are stored in trusted business systems.

Why trusted URLs matter in agentic data exfiltration

Agentic exfiltration often uses the model’s own allowed actions against the environment. If an AI can fetch images, load external content, or call whitelisted endpoints, attackers can encode sensitive output into seemingly benign outbound requests. That makes allow lists necessary but not sufficient, because the agent still needs egress rules, content inspection, and destination validation. The key risk is not only data leaving the environment, but the AI system itself being used as the transport mechanism. This is especially dangerous when the agent operates with a user’s normal business permissions.

Practical implication: control outbound tool use and egress separately, even when URLs are already on an allow list.

AI agent inventories and permission scope are now core controls

Once AI agents can act inside enterprise workflows, they become non-human identities in practice, even if they are not autonomous in the strictest sense. That means they need visibility, ownership, scoped permissions, logging, and lifecycle controls similar to other privileged machine actors. The article points to the need for real-time prompt injection detection and agent inventories because you cannot govern what you cannot enumerate. Without a complete inventory, teams cannot tell which agents process external data, which can call external tools, or which can expose sensitive CRM records.

Practical implication: inventory all production AI agents and bind each one to an owner, purpose, and least-privilege permission set.

Threat narrative

Attacker objective: The attacker wants to use the enterprise AI workflow itself to exfiltrate sensitive CRM data and potentially manipulate records without triggering obvious user friction.

1. Entry occurs when an attacker submits malicious content through a normal-looking CRM intake field such as a lead form or description field.
2. Credential or trust abuse occurs when an employee later queries the AI and the agent treats the hidden instructions as part of the legitimate request.
3. Impact occurs when the agent retrieves sensitive CRM data and sends it to an attacker-controlled destination through permitted outbound channels.

NHI Mgmt Group analysis

ForcedLeak is not just a prompt injection bug. It is a trust-boundary collapse between enterprise data, user intent, and agent execution. Once untrusted text can influence an AI system that also holds business permissions, the organisation has effectively merged content handling and access control into one failure domain. That is why classic application security checks miss the real risk. Practitioners need to treat AI-mediated workflows as governed execution paths, not passive search or summarisation features.

AI agents are becoming non-human identities by function, even when they are not autonomous by design. When an agent can read records, call tools, and transmit outputs, it behaves like a privileged workload with decision-making authority. That makes NHI governance directly relevant to AI security programmes, especially for service accounts, API-backed agents, and CRM integrations. The right question is not whether the system is “an identity” in name, but whether it can move data and invoke actions under persistent credentials.

Provenance trust gap: the control failure is assuming retrieved enterprise data is safe because the source system is trusted. ForcedLeak shows that the source may be trusted while the embedded content is not, and the AI cannot reliably infer the difference without explicit policy. That means organisations need policy layers that distinguish human-authored content, third-party submissions, and machine-generated instructions before any agent processes them. Practitioners should redesign AI workflows around provenance, not just authentication.

Trusted URL allow lists are a containment control, not a full governance model. They can reduce one exfiltration path, but they do not answer which agents may inspect which records, what content they may process, or how far their permissions extend. The broader market signal is that AI security is converging with identity governance, because privilege scope and data provenance now determine whether an agent becomes a business assistant or a breach path. Practitioners should evaluate AI controls through that lens.

Security teams should expect more zero-click agent abuse as enterprise AI adoption expands. The article describes a path where the payload sits dormant until ordinary business interaction activates it, which makes detection and review windows unreliable. That is a governance problem, not just a detection problem, because the attack can ride on approved workflows and approved credentials. Practitioners should assume the next control gap will be in how AI systems interpret trusted data, not only in how they reach external tools.

What this signals

Provenance controls will become a baseline requirement for any AI workflow that touches enterprise data. The practical shift is from asking whether an agent is authenticated to asking whether each input, record, and output is provenance-aware before execution. For teams building governance around AI-integrated CRM or support systems, the relevant external reference point is the NIST AI Risk Management Framework, which supports a risk-based approach to governance, mapping, and monitoring.

AI security programmes will increasingly overlap with NHI governance because agent permissions behave like machine privileges. That means access reviews, lifecycle ownership, and outbound control paths need the same discipline that identity teams already apply to service accounts and API keys. The organisational gap is not model quality, it is control ownership across the agent, the data source, and the egress path.

Named concept: the provenance trust gap. This is the failure mode where trusted enterprise data is assumed to be safe for agent execution even when the embedded content is attacker-controlled. Once teams recognise that gap, they can design controls around source validation, workflow segmentation, and least privilege for agent actions.

For practitioners

• Inventory all production AI agents Map every AI agent, connector, and workflow that can read CRM, support, or sales data. Assign an owner, define the business purpose, and identify the exact credentials or service accounts each agent uses.
• Separate content trust from execution trust Apply explicit provenance checks to user-submitted text, imported records, and third-party content before an agent can interpret it. Do not let retrieval pipelines feed untrusted instructions into the same prompt context as user requests.
• Constrain outbound tool use and data egress Review allow lists, image fetches, and external request paths together so the agent cannot encode sensitive data into permitted outbound channels. Pair egress policy with content inspection and destination validation.
• Review agent permissions as if they were privileged service accounts Remove broad read access, narrow write actions, and eliminate unused integrations that could turn an AI workflow into an exfiltration path. Revalidate every permission after each workflow change.
• Add prompt injection detection to high-risk workflows Place runtime detection on records, tickets, and form inputs that will later be processed by AI. Focus on fields that can carry hidden instructions, especially where external users can submit content.

Key takeaways

• ForcedLeak shows that indirect prompt injection can convert ordinary business data into executable instructions for AI agents.
• The exposure is broader than data theft because the same workflow can also manipulate records and trigger external requests.
• The control response has to combine provenance checks, scoped agent permissions, and outbound egress controls, not any single fix on its own.

Key terms

• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Provenance Trust Gap: A provenance trust gap exists when a system trusts the source of stored data but fails to distinguish whether the content itself is safe to execute. In AI workflows, this gap appears when retrieved records or documents can influence agent actions without validation of origin, intent, or trust level.
• Agent Egress Control: Agent egress control is the governance of where an AI agent can send data, which tools it can call, and what external destinations it may reach. It is essential when agents can transform internal information into outbound requests that may leak sensitive content or trigger unintended actions.
• AI agent inventory: An AI agent inventory is a complete record of autonomous or semi-autonomous software entities, including their permissions, tools, and reachable resources. It is a governance baseline because teams cannot review, restrict, or remediate agent access until they know exactly what the agent estate contains.

What's in the full report

Noma Security's full blog covers the operational detail this post intentionally leaves for the source:

• The full attack path showing how a hidden instruction can survive in ordinary CRM intake fields until an employee activates it through a routine AI query.
• The Trusted URL allow list mitigation context, including what changed in Salesforce Agentforce and Einstein Generative AI agents.
• The practical review workflow for recent lead submissions, anomalous AI interactions, and suspicious access patterns in customer environments.
• The AI-specific control recommendations for prompt injection detection, input validation, and agent inventories that the source article outlines in more detail.

👉 The full Noma Security blog covers the attack chain, mitigation context, and AI-specific control steps in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to broader security programmes.