The Reviewer Cannot See It

Most security risks in a finance function arrive through channels the function can restrict. Prompt injection arrives through supplier invoices, client correspondence and bank statements, which is to say through the material the function exists to process and cannot decline to read.

An Architecture, Not A Bug

The framing that determines whether this is a problem to be fixed or a property to be designed around.

A peer-reviewed review states that OWASP identifies prompt injection as the top security vulnerability for large language model applications, reflecting the consensus that this represents a fundamental architectural vulnerability rather than an implementation flaw. It explains that the vulnerability exists because models cannot reliably separate instructions from data, with inputs affecting models even if imperceptible to humans, and notes that OWASP guidance acknowledges fundamental limitations arising from the stochastic nature of these systems[1].

Another source records the persistence: prompt injection has held the top position across every published edition of the list, from the original through the 2025 update, and no other vulnerability in that list has done so[2].

For a finance audience the distinction between architectural vulnerability and implementation flaw is the whole governance question.

An implementation flaw is remediated. You patch it, confirm the patch, and record the control as effective. That is how most technology risk is handled, and it is what a risk register is built to express.

An architectural property cannot be remediated, only accommodated. A firm recording prompt injection as a risk with a remediation plan and a target closure date has mis-classified it, and will report as closed something that remains open by construction.

The Separation That Does Not Exist

The mechanism, expressed through a comparison that makes it concrete.

One source explains that every input, whether it comes from a user, a document, a web page or a database record, is processed through the same attention mechanism, and that there is no hardware-level separation between a system instruction and user content in the way an operating system separates kernel mode from user mode, concluding that this is not a bug that a patch will fix[2].

The comparison is worth dwelling on because it identifies precisely what is absent.

Every mature information system a Canadian finance function relies on maintains a boundary between the instructions it executes and the data it operates on. A spreadsheet distinguishes a formula from a value. A database distinguishes a query from a record. An operating system distinguishes privileged code from application data. These boundaries are enforced structurally, not by the system deciding what looks like an instruction.

A language model has no such boundary. The system prompt, the user's question and the contents of a supplier's invoice arrive as one undifferentiated sequence, and any apparent separation is a convention the model has learned to respect most of the time rather than a rule it cannot violate.

That is why the mitigation advice below focuses on constraining consequences rather than on preventing the confusion. The confusion is the design.

Why The SQL Analogy Misleads

A comparison that circulates widely and produces false comfort. This section is our own analysis, prompted by a national cyber authority having published under a title making the same point[3].

Prompt injection is routinely explained by analogy to SQL injection, and one vendor source draws the comparison directly, noting that SQL injection targets databases by inserting malicious code into query fields while prompt injection targets language models by inserting instructions into inputs[4].

The analogy is useful for conveying the shape of the attack and dangerous for what it implies about the remedy.

SQL injection is a solved problem. The solution is parameterisation: the query structure is sent separately from the values, so the database knows which is which regardless of what the values contain. A developer who parameterises has eliminated the class of attack, not reduced it.

There is no parameterisation for a language model, because there is no channel through which structure can be sent separately from content. The technique that solved the analogous problem elsewhere has no counterpart here.

A Canadian finance leader who has been told this is like SQL injection has probably concluded that a competent implementation eliminates it. The correct conclusion is the opposite: it resembles SQL injection in shape and differs in the one respect that mattered, which is that the fix does not exist.

Direct And Indirect

The two forms, of which only one is relevant to most finance workflows.

One paper summarises the lineage: direct attacks, in which users themselves craft prompts to override system constraints, were systematised first, and the threat model was subsequently extended to indirect injection, in which adversarial content is embedded in third-party documents the model retrieves rather than in the user's own input. It notes that indirect attacks involve third-party content that victims encounter during normal model-assisted tasks[5].

OWASP describes indirect injections as occurring when a model accepts input from external sources such as websites or files, where content in that external material, when interpreted by the model, alters its behaviour in unintended ways, and notes that such injections can be either intentional or unintentional[6].

Another source describes them as malicious instructions embedded into external content the model is expected to retrieve and process as part of its normal workflow, characterising the attack as subtle and disguised as contextual guidance, turning routine business content into a latent attack vector[7].

The phrase turning routine business content into a latent attack vector is the one a Canadian controller should sit with.

Note also the observation that injections can be unintentional[6]. A document need not be authored by an attacker to contain text a model reads as instruction. A contract clause phrased in the imperative, a template with instructions to the recipient, or a covering note can all alter behaviour without anyone intending it.

What The Benchmarks Found

The empirical position, reported at the level of confidence the source supports.

One paper's related work records that a benchmark of indirect injections against tool-using agents found that even strong models follow injected instructions a substantial fraction of the time[8]. It also records that the attack surface was formalised and defences benchmarked in earlier work[8].

We have the characterisation and not the figures, and we did not access the benchmark paper, so we report it as stated without attaching a rate.

Another paper notes that even mature, deployed systems from major vendors remain vulnerable to carefully crafted injections that exploit their integration with external data sources[5].

The reason the qualifier even strong models matters is that it forecloses the most common organisational response, which is to assume the problem belongs to inferior systems and that procurement from a reputable vendor resolves it. The literature does not support that.

The reason substantial fraction matters, rather than a small percentage, is that it places this outside the category of rare events managed by exception. A control designed on the assumption that injection rarely succeeds is designed against a rate the research does not report.

Why Finance Is Maximally Exposed

The argument that makes this a finance article rather than a security one, and it is our own.

Indirect injection requires that a model process content authored by someone outside the organisation. That condition is occasional for many business functions and universal for finance.

Consider what a Canadian finance function reads: supplier invoices, purchase orders, remittance advices, bank statements, contracts, client correspondence, statements of account, insurance documents, tax notices. Nearly every input is authored externally, arrives unsolicited, and must be processed.

Three consequences follow.

The function cannot reduce exposure by restricting inputs. A web browsing agent can be told which sites to visit. An accounts payable process cannot be told to stop receiving invoices, because receiving invoices is what it does.

The attacker does not need access to anything. Where other attacks require a foothold, this one requires only the ability to send a document to an address that is published on the firm's website.

And the volume works against detection. A function processing thousands of documents monthly, from hundreds of counterparties, has no baseline against which one unusual document stands out, which is the same base rate problem this publication has described in relation to alerts.

We would put the position plainly: of all the business functions adopting AI, finance has the input profile that indirect prompt injection was described for.

The Payload The Reviewer Cannot See

The property that defeats the control most firms are relying on.

The peer-reviewed source states that inputs affect models even if imperceptible to humans[1]. OWASP notes that the rise of multimodal systems introduces additional risk, since malicious actors could exploit interactions between modalities, such as hiding instructions in images that accompany benign text[6].

Imperceptible is doing critical work in that sentence, and the practical forms are well known in document handling: text rendered in white on white, text at negligible font size, content in document metadata, text in a layer beneath an image, and characters that do not display.

Now recall the control architecture almost every Canadian firm has adopted for AI-assisted document work. The model extracts or drafts, and a person reviews. That review is the control the framework relies on, and this publication has already examined how it degrades through automation bias.

This is a different and more absolute failure. The reviewer is not being inattentive. The reviewer is looking at a document that does not contain the payload, because the payload is not rendered.

A control cannot detect what is not presented to it, and no amount of diligence, training or checklist discipline changes that. The review control is blind to this attack by construction rather than by degradation.

Two Different Objects

Generalising the previous section into a principle, offered as our own analysis.

The human reviewer examines a rendered document: the visual output of a viewer applying layout, fonts, colours and image compositing to a file.

The model reads an extracted text stream: whatever a parser produced from that file, including metadata, hidden layers, and content the renderer chose not to display.

These are two different objects derived from one file, and they are not guaranteed to agree. The entire class of invisible payload attacks lives precisely in the region where they diverge.

The design instruction that follows is unusual and, we think, correct: the reviewer should be shown what the model read, not what the document looks like.

Concretely, an interface presenting the extracted text alongside the rendered page allows a reviewer to notice content that appears in one and not the other. That is a modest engineering change and it converts an undetectable attack into a visible anomaly.

A cheaper approximation available to any firm today is to run a periodic comparison, on a sample, between the character count or content of the extracted stream and what a person can see on the page. Large divergences merit examination.

The Attack That Already Exists

Why this is not speculative for Canadian businesses, offered as our own analysis connected to a known fraud pattern.

The dominant payment fraud against businesses does not require any of this. It consists of persuading someone to change the bank details on a supplier payment, usually through a convincing email, and this publication has addressed it in the context of payment controls.

Indirect injection is that same fraud with a new delivery mechanism. Instead of persuading a person, the payload attempts to influence the system that extracts payment details from the document, in an environment where a human may no longer be reading the document closely because a system now does.

The economic logic is unattractive for the defender. The attack requires no relationship, no compromised mailbox and no social engineering. It requires sending an invoice.

And the target is a control that was weakened by the automation itself. The traditional defence against payee fraud was that someone familiar with the supplier noticed the details had changed, which is precisely the familiarity the deskilling and offloading articles in this series argue is eroding.

We are not aware of published Canadian incident data on this specific vector, and we would not assert a prevalence. The point is that the attack composes with an existing, well-evidenced fraud pattern rather than requiring a new motivation.

Stored Injection Through Your Own Ledger

A vector worth naming because it inverts the usual assumption about which data is trusted.

One source records that disclosed vulnerabilities in a major vendor's suite included log-to-prompt injection alongside search injection and indirect injection[4]. OWASP's description of indirect injection includes database records among the sources whose content is processed through the same mechanism as instructions[2].

The finance translation is that free-text fields in a firm's own systems are an injection channel, and this is our own analysis.

Ledgers are full of externally supplied text: invoice descriptions, payment references, remittance memo fields, customer names, purchase order notes. That text is entered by counterparties, stored by the firm, and later read by an AI system performing reconciliation, analysis or reporting.

At the point of reading, the data appears internal and therefore trusted. It is not. It is third-party content that the firm persisted.

The consequence is that a payload can be delivered once and act repeatedly, whenever the record is processed, and that the usual mental model of an untrusted perimeter does not apply, because the content crossed the perimeter as data long before it was read as instruction.

Severity Depends On Agency

The governance lever, stated by OWASP and connecting directly to the design articles in this series.

OWASP states that the severity and nature of the impact of a successful attack vary greatly and are largely dependent on both the business context the model operates in and the agency with which the model is architected[6].

That sentence relocates the problem from security to design, and it is the most useful thing in the guidance.

If the attack cannot be prevented, then the variable a firm controls is what a compromised system is capable of doing. A model that can only produce a draft for a person to act on has limited severity regardless of what it was persuaded to write. A model that can initiate a payment has severity bounded only by the payment limit.

This is the same lever the function allocation article identified as automation level per stage, and the same lever the segregation of duties article identified as scoping autonomy by reversibility. Three separate literatures arrive at one instruction: constrain what the system may cause to happen.

For a Canadian firm the practical formulation is to ask, for each AI workflow, what the worst outcome would be if the model did the most damaging thing it is technically permitted to do. If that answer is unacceptable, the permissions are wrong, and no amount of input filtering changes the analysis.

Where The Defences Converged

The most important finding in the recent literature, and it confirms the architectural argument.

One paper summarises the position: recent work from 2024 to 2026 has converged on a strategy for defending tool-using agents against indirect prompt injection, which is that rather than training the model to refuse malicious instructions, security is enforced outside the model with a deterministic policy that mediates the agent's actions. It names several systems realising this with capabilities, information-flow labels and reference monitors, and notes that several report near-elimination of attacks on a published agent benchmark[9].

Read what the field abandoned. The intuitive approach, training the model to recognise and refuse malicious instructions, is not where the research converged. The convergence is on external, deterministic mediation.

This is the identical conclusion the segregation of duties article reached from identity governance: prompt-level promises are probabilistic and a control framework requires determinism, so the enforcement point must sit where the model cannot reach it.

The mechanisms named are worth understanding at a conceptual level even for a firm that will never implement them. Capabilities constrain what an action may touch. Information-flow labels track where data came from and restrict where it may go. A reference monitor is a component that every action must pass through and that decides independently whether to permit it.

All three share a property: they make the security decision without asking the model. For a mid-sized Canadian firm the accessible version is an approval gate on consequential actions, implemented in the system that performs the action rather than in the prompt that requests it.

A Caveat On Near-Elimination

An honesty note about the previous section, because the source that reports those results is also examining them.

The paper reporting the near-elimination claims is itself titled as an adaptive evaluation of out-of-band defences, and states that it makes two contributions[9].

We accessed its abstract framing and not its findings. We therefore do not know what its evaluation concluded, and we will not speculate.

What a reader should take from this is a general caution about defensive efficacy figures in adversarial settings. A defence evaluated against a fixed set of attacks reports one number; the same defence evaluated against an attacker who adapts to it typically reports a different one. That pattern is well established across security research generally, and it is the reason papers of this kind get written.

So the convergence on external enforcement is the durable finding here, and the near-elimination figures should be held loosely pending the evaluation that source is conducting.

A Canadian firm should read this as: the architectural direction is right, and any specific claim about a defence eliminating the attack deserves the same scepticism this publication has recommended toward vendor efficacy claims generally.

Filtering Is Not A Control

The approach most organisations try first, and why the practitioner advice cautions against relying on it.

One practitioner checklist advises constraining and sanitising inputs and using allowlists for expected formats, then stripping or neutralising known injection patterns, with the immediate qualification not to lean on this alone because the attacker will find patterns you did not anticipate. It also advises separating system prompts from user data using whatever delimiter or framing the model supports[2].

We note this source is a personal developer blog rather than research, and the advice is consistent with the guidance elsewhere.

The reason pattern filtering cannot be the control is the same reason it fails in other security domains: it enumerates the bad rather than constraining the permitted, and the space of bad inputs is not enumerable. The peer-reviewed framing that models cannot reliably separate instructions from data[1] means there is no signature that reliably identifies an instruction, because instruction is not a property of the text.

The delimiter advice deserves particular care. Framing user content between markers is worth doing and it is a convention the model usually respects, not a boundary it cannot cross. Treating a delimiter as a security boundary is the same category error as treating a prompt instruction as a control.

Filtering has a place as one layer that raises cost for unsophisticated attempts. It does not support any assertion that the attack cannot succeed.

The Agentic Position

Where this sits in the newer taxonomies, and the significance of that placement.

One paper records that in OWASP's Top 10 for Agentic Applications 2026, agent goal hijack and tool misuse and exploitation are broader risk categories, but both identify indirect prompt injection as a recurring attack path, for example through malicious content embedded in webpages, documents, external communications or other agent-consumed data. It concludes that mitigating this is not a peripheral hardening step but a prerequisite for the safe deployment of tool-using agents[10].

The word prerequisite is the operative one, and it sets a sequencing rule a Canadian firm can apply directly.

If mitigation is a prerequisite rather than a hardening measure, then it belongs before deployment of any agent that both reads external content and can take consequential action, rather than in a subsequent security review.

The same review that produced the agentic taxonomies noted, in the language model list, that vector and embedding weaknesses were added as a category acknowledging the dominance of retrieval architectures, with a reported figure that 53% of companies use retrieval pipelines rather than fine-tuning, and that system prompt leakage was added reflecting numerous cases where confidential instructions and embedded secrets were extracted[1].

The retrieval figure matters here because retrieval is the mechanism by which external documents enter the model's context. A firm using retrieval over its own document store, which is the standard architecture in professional services, has built the delivery path for indirect injection as a core feature.

What Actually Helps

Consolidating the position into measures a mid-sized Canadian firm can implement, drawing on the convergence and on our own analysis.

Constrain permitted actions. Severity depends on the agency with which the system is architected, so the primary control is what a compromised system is allowed to do.

Gate consequential actions outside the model. The research converged on deterministic external mediation rather than on model refusal.

Show the reviewer what the model read. The rendered document and the extracted stream are different objects, and the attack lives between them.

Treat your own free-text fields as untrusted. Externally supplied text stored in your ledger is third-party content that crossed the perimeter as data.

Apply payee change controls independently of the document. Bank detail changes should be verified through a separate channel regardless of what any document or extraction says, which is standard payment fraud practice and happens to defeat this vector.

Do not rely on filtering. It raises cost and supports no assertion of prevention.

Classify the risk correctly. An architectural property recorded as a remediable finding will be closed on a register while remaining open in fact.

A Worked Case: The Remittance Instruction

A Canadian firm running AI-assisted invoice processing. The reconstruction illustrates the mechanism rather than reporting a specific engagement or a known incident.

An invoice arrives by email from an address resembling a supplier's. It renders normally: correct layout, plausible amounts, familiar line items. A person glancing at it sees nothing unusual, because there is nothing unusual to see.

The file also contains text the renderer does not display, phrased as guidance about how remittance details should be handled. Whether the extraction system is influenced depends on the system, and the literature indicates that even strong models follow injected instructions a substantial fraction of the time[8].

The firm's control is that a person reviews the extracted output against the document. That control is blind here, not because the reviewer is careless but because the payload is not rendered[1], so the reviewer and the model are examining different objects.

Whether anything bad happens next depends entirely on agency[6]. If the workflow drafts a payment for authorisation by a person who verifies bank details through an independent channel, the attack fails at a control that never touched the document. If the workflow can submit a payment file, it does not.

Note what did not help: procurement from a reputable vendor, since mature deployed systems remain vulnerable[5]; reviewer diligence, since the payload is invisible; and pattern filtering, since the attacker selects patterns the filter does not anticipate[2].

What To Do

Ask what the worst permitted action is. For each AI workflow, assume the model does the most damaging thing it is technically able to do. If the answer is unacceptable, change the permissions.

Put consequential gates outside the model. The field converged on deterministic external mediation, not on teaching models to refuse.

Present the extracted text to reviewers alongside the page. It converts an undetectable attack into a visible discrepancy, at modest engineering cost.

Verify payee and bank detail changes out of band. Independent of any document, extraction or message, which is already good payment practice.

Treat ledger free-text as external input. Memo fields, references and descriptions supplied by counterparties are stored third-party content.

Sequence mitigation before agent deployment. The agentic guidance describes it as a prerequisite rather than a hardening step.

Record the risk as accepted and constrained, not remediated. It is an architectural property, and a closure date on the register would be a fiction.

Do not accept a vendor assurance that it is solved. Mature systems from major vendors remain vulnerable, and defensive efficacy claims in adversarial settings warrant scepticism.

The Limits Of This Analysis

Several caveats matter. Sources here are mixed: one peer-reviewed review, several preprints not peer reviewed at the versions accessed, OWASP project documentation, one personal developer blog and two vendor publications, one of which markets a product addressing this risk. The benchmark finding that strong models follow injected instructions a substantial fraction of the time reaches us through a related-work summary; we did not access the benchmark and report no rate. We accessed the framing of the adaptive evaluation paper and not its findings, and we have flagged that its near-elimination figures should be held loosely pending that evaluation. Named incidents involving specific vendors' products are reported at second hand from a vendor publication and were not independently verified. The 53% retrieval adoption figure is reported at second hand. The SQL parameterisation contrast, the finance exposure argument, the two-different-objects analysis and the interface recommendation, the stored-injection-through-ledger vector, the payee fraud composition and the worked case are our own analysis rather than findings in the cited material; the worked case describes a mechanism and is not a report of a known incident. We are not aware of published Canadian incident data on this vector and assert no prevalence. This article does not address red teaming methodology, specific defensive architectures in technical detail, model provider security controls, or Canadian breach notification obligations where an incident involves personal information. Nothing here is a substitute for professional security advice on a specific environment.

Related Reading

AI & Automation In Finance The Spec Defines What Is Possible, Not What Is Safe A protocol that solved integration by making the interface natural language has inherited every property of natural language, including that anyone who... AI & Automation In Finance Better Explanations, Worse Oversight In one study, reviewers given clear AI explanations deferred 19 points more than the control, and narrative rationales added another five. The... AI & Automation In Finance The Deepfake CFO And The Collapse Of Verification The out-of-band verification that defeats this vector without ever examining the artefact.

Frequently Asked Questions

Can prompt injection be fixed?

The peer-reviewed literature describes it as a fundamental architectural vulnerability rather than an implementation flaw, arising because models cannot reliably separate instructions from data. There is no hardware-level boundary between system instruction and content the way an operating system separates kernel from user mode. A firm recording it as remediable with a closure date has mis-classified it.

Is it like SQL injection?

In shape, yes. In the respect that matters, no. SQL injection is solved by parameterisation, which sends query structure separately from values. No equivalent channel exists for a language model, so the technique that eliminated the analogous problem has no counterpart. The analogy tends to produce false confidence that competent implementation removes the risk.

Why is finance particularly exposed?

Because indirect injection requires processing externally authored content, and nearly every finance input is externally authored: invoices, statements, contracts, correspondence. The function cannot restrict its inputs the way a browsing agent can, the attacker needs no access beyond the ability to send a document, and high volume from many counterparties removes any baseline against which one document stands out.

Won't our reviewer catch it?

Not if the payload is imperceptible, which the research notes it can be. The reviewer examines a rendered document while the model reads an extracted text stream, and these are different objects derived from one file. The control is blind by construction rather than through inattention. Showing reviewers what the model read, alongside the page, converts the attack into a visible discrepancy.

What actually reduces the risk?

Constraining what a compromised system is permitted to do. OWASP notes severity depends on the agency with which the model is architected, and research from 2024 to 2026 converged on enforcing security outside the model with deterministic policy mediating actions, rather than training models to refuse. Input filtering raises cost and supports no assertion of prevention.

Is data in our own systems safe to process?

Not automatically. Free-text fields in your ledger, being invoice descriptions, payment references and memo fields, are frequently supplied by counterparties. That content crossed your perimeter as data and is read later as though internal, so a payload delivered once can act each time the record is processed.

References

1. Prompt Injection Attacks in Large Language Models and AI Agent Systems: A Comprehensive Review of Vulnerabilities, Attack Vectors, and Defense Mechanisms. Information, 2026, 17(1), 54, on prompt injection as a fundamental architectural vulnerability rather than an implementation flaw, models being unable to reliably separate instructions from data, inputs affecting models even when imperceptible to humans, OWASP's acknowledgement of fundamental limitations, and the additions of system prompt leakage and vector and embedding weaknesses with the reported 53% retrieval adoption figure. mdpi.com/2078-2489/17/1/54
2. Prompt Injection in 2026: Still OWASP's Number One LLM Vulnerability, developer community post, on the vulnerability holding the top position across every published edition, the absence of hardware-level separation analogous to kernel and user mode, all inputs passing through the same attention mechanism, and the mitigation checklist including input constraint, pattern stripping with the caution not to rely on it alone, and system prompt separation by delimiter. Note: a personal developer blog rather than research. dev.to/kunal_d6a8fea2309e1571ee7
3. UK National Cyber Security Centre. (2025). Prompt Injection Is Not SQL Injection, blog post, cited here for its title and position as recorded in a preprint bibliography. Note: referenced at second hand through another paper's reference list; we did not access the post itself. ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection
4. Indusface. LLM01:2025 Prompt Injection: Risks and Mitigation, on the reported 2025 disclosures of a vendor trifecta comprising search injection, log-to-prompt injection and indirect injection, the reported browser vulnerability enabling data theft through seemingly safe web pages, and the contrast drawn between prompt injection and SQL injection. Note: published by a vendor marketing a product addressing this risk; incidents reported at second hand and not independently verified. indusface.com/learning/owasp-llm-prompt-injection
5. Skill-Inject: Measuring Agent Vulnerability to Skill File Attacks. arXiv preprint 2602.20156, on the distinction between direct injection where users craft prompts and indirect injection through third-party content encountered during normal tasks, the attribution of the indirect threat model to Greshake and colleagues (2023), and the observation that mature deployed systems from major vendors remain vulnerable to crafted injections exploiting external data integration. Note: preprint. arxiv.org/pdf/2602.20156
6. OWASP Gen AI Security Project. LLM01:2025 Prompt Injection, on indirect injections occurring when a model accepts input from external sources such as websites or files, injections being either intentional or unintentional, severity depending on the business context and the agency with which the model is architected, and multimodal risks including instructions hidden in images accompanying benign text. genai.owasp.org/llmrisk/llm01-prompt-injection
7. Securiti. (2026, February 6). LLM01 OWASP Prompt Injection, on indirect injections as malicious instructions embedded into external content the model is expected to retrieve as part of its normal workflow, and the characterisation of the attack as subtle and disguised as contextual guidance, turning routine business content into a latent attack vector. Note: published by a data security vendor. securiti.ai/llm01-owasp-prompt-injection
8. Adversarial Feeds Steer LLM Agent Decisions Against Their Defaults. arXiv preprint 2606.00914, related work section, on the systematisation of direct injection, the extension to indirect injection through third-party documents, the formalisation of the attack surface and benchmarking of defences, and the finding from a benchmark of indirect injections against tool-using agents that even strong models follow injected instructions a substantial fraction of the time. Note: preprint; the benchmark itself was not accessed and no rate is reported here. arxiv.org/pdf/2606.00914
9. Adaptive Evaluation of Out-of-Band Defenses Against Prompt Injection in LLM Agents. arXiv preprint 2606.26479, on the convergence of work from 2024 to 2026 toward enforcing security outside the model with a deterministic policy mediating agent actions rather than training models to refuse, the named systems realising this through capabilities, information-flow labels and reference monitors, and the report that several claim near-elimination on a published benchmark. Note: preprint; we accessed the abstract framing and not the paper's own findings, and the paper is itself an adaptive evaluation of those defences. arxiv.org/pdf/2606.26479
10. IPI-proxy: An Intercepting Proxy for Red-Teaming Web-Browsing AI Agents Against Indirect Prompt Injection. arXiv preprint 2605.11868, on OWASP's Top 10 for Agentic Applications 2026 identifying agent goal hijack and tool misuse as broader categories that both name indirect injection as a recurring attack path through webpages, documents and external communications, and on mitigation being a prerequisite for safe deployment rather than a peripheral hardening step. Note: preprint. arxiv.org/pdf/2605.11868

This article discusses AI security research and is provided for general informational purposes. Sources include one peer-reviewed review, several preprints not peer reviewed at the versions accessed, project documentation, a personal blog and vendor publications. Named incidents are reported at second hand and unverified, no Canadian prevalence is asserted, and the worked case describes a mechanism rather than a known incident. Nothing here is a substitute for professional security advice.