From Executable to Trustworthy: Identity and Attribution in the AI Recommendation Economy
A recommendation can be relevant. Its product link can work. Its checkout can accept the buyer’s details. And an important question can still remain unresolved: Who, exactly, is being recommended—and what evidence co
A recommendation can be relevant.
Its product link can work.
Its checkout can accept the buyer’s details.
And an important question can still remain unresolved:
Who, exactly, is being recommended—and what evidence connects that identity to the claims and destination presented?
The previous articles moved from measuring recommendations to examining their execution. They distinguished product selection from merchant selection, and a valid offer from a completed purchase.
This article examines the identity assumptions inside those transitions.
A name appearing on a page does not establish authorship.
A claimed affiliation does not establish authorization.
A source calling itself authoritative does not make it independent.
And an executable destination does not, by itself, prove continuity with the entity the user intended to trust.
The next step in the AI Recommendation Economy is therefore not another measure of visibility.
It is an audit of the relationships behind it.
1. The Question Left Open by Execution
A purchase-path audit asks whether a recommendation preserves the buyer’s requirements as it moves toward an actionable offer.
But requirements are not the only thing that must survive that journey.
Identity must survive it too.
Consider a hypothetical sequence:
- An assistant recommends a named product.
- A source claims that a recognized specialist endorses it.
- A merchant is presented as an authorized supplier.
- The purchase link reaches a functioning checkout.
Each step contains a different claim.
The product may exist.
The endorsement may be unsupported.
The merchant may be legitimate without being authorized in the way described.
The checkout may work while the explanation leading to it remains misleading.
This is not a reported incident. It illustrates why transaction readiness cannot resolve every trust question.
The system may execute correctly against the destination it received while the user’s understanding of that destination is wrong.
2. Identity Is a Relationship, Not a String Match
A name match answers a narrow question:
Does this material contain a representation of the entity we are monitoring?
It does not establish:
- That the page refers to the intended person or organization.
- That the entity created or approved it.
- That an affiliation is current.
- That an endorsement exists.
- That a linked destination is controlled by that entity.
For this framework, identity integrity means preserving the distinction between an entity and the representations made about it.
It does not mean that an entity controls every mention of its name.
Independent reporting, criticism, comparison, and historical discussion can all be legitimate.
The task is not to remove unfamiliar references.
It is to determine which relationship a reference asserts—and what supports that assertion.
3. Three Boundaries to Audit
The proposed framework separates identity, attribution, and destination.
| Boundary | Audit question | Example of an unsupported leap |
|---|---|---|
| Identity | Is this the entity the user means? | Matching a name and merging two different people |
| Attribution | Who made, approved, or supports the claim? | Treating a mention as an endorsement |
| Destination | Who operates the place where the user is directed to act? | Assuming a branded link leads to the official provider |
These boundaries can fail independently.
Correct identity does not establish correct attribution.
Correct attribution does not establish that a destination remains valid.
A legitimate destination does not validate every claim made about it elsewhere.
The audit should preserve these distinctions rather than reduce them to a single “trusted” label.
4. Why Product and Merchant Identity Must Remain Separate
OpenAI’s September 2025 Instant Checkout announcement distinguishes product results from the ranking of merchants selling the same product. It states that checkout-enabled products are not preferred in product results, while merchant ranking considers factors including availability, price, quality, primary-seller status, and checkout availability. openai
This is a provider’s description of its system, not an independent audit.
Nevertheless, it demonstrates why the entity boundary matters.
The manufacturer, the product, the seller, and the checkout provider are not interchangeable.
A recommendation of a product is not automatically an endorsement of every seller offering it.
Likewise, a merchant’s ability to transact does not establish that it is the manufacturer or an authorized representative.
A rigorous record should therefore distinguish:
[
\text{Recommended entity}
\rightarrow
\text{Claimed relationship}
\rightarrow
\text{Selected counterparty}
\rightarrow
\text{Action destination}
]
The purpose is not to assume deception.
It is to avoid assuming equivalence.
5. When a Name Becomes Search Content
The practical identity-monitor architecture I described in When Your Name Becomes SEO Spam begins with a deliberately limited observation:
A URL appeared for a particular query, at a particular time, with a particular title and snippet.
It does not begin by declaring that the website operator stole an identity. The article separates name matching from abuse assessment, search-result evidence from live-page evidence, and report submission from confirmed resolution. dev
That approach belongs inside the recommendation framework because it exposes a recurring evidence problem:
The appearance of a name can invite an interpretation that the underlying evidence does not support.
A suspicious result might reflect unauthorized content, stale indexing, an unrelated person, or another situation requiring investigation. The monitor’s role is to preserve the observation and support review—not to choose the most severe explanation automatically. dev
The architecture is a design proposal.
It is not evidence that any particular suspicious page entered an AI response or changed a recommendation.
That distinction remains essential as we move from identity monitoring to recommendation auditing.
6. External Content Can Try to Promote Itself into Authority
There is documented evidence of attempts to influence how AI assistants treat sources.
Microsoft’s February 2026 security report describes promotional prompts embedded in “Summarize with AI” links. Alongside the requested summary, these prompts attempted to make an assistant remember a company or website as a trusted source for future citations or recommendations. microsoft
Over a 60-day observation period, Microsoft identified approximately 50 distinct examples associated with 31 companies across more than a dozen industries. microsoft
The attempted transition is important:
[
\text{External promotional instruction}
\rightarrow
\text{Stored source preference}
\rightarrow
\text{Future recommendation influence}
]
But the arrows are not equally established in every case.
Microsoft states that effectiveness and persistence varied across assistants and over time. It also reports that some previously observed behaviors could no longer be reproduced after mitigations. microsoft
The observation count is therefore not a count of successful, persistent compromises.
The evidence supports the existence of a promotional tactic and observed attempts.
It does not support a claim that every attempt changed future recommendations.
7. Do Not Merge Different Mechanisms
Several problems can produce a misleading answer, but their mechanisms differ.
| Mechanism | What the auditor investigates |
|---|---|
| Entity confusion | Whether information about one entity was assigned to another |
| Unsupported attribution | Whether authorship, affiliation, or endorsement lacks support |
| False source claim | Whether the source asserts something contradicted by stronger evidence |
| Indirect prompt injection | Whether external material attempts to redirect the assistant’s behavior |
| Memory poisoning | Whether unauthorized instructions or claims persist in assistant context |
| Destination mismatch | Whether the action route points to a different entity than represented |
Microsoft’s observed link-based attempts and Google’s study of instructions embedded in web content concern related trust boundaries, but they are not identical delivery mechanisms. microsoft
An identity monitor may detect a suspicious claim without detecting an instruction attack.
A prompt-injection detector may find an instruction without establishing identity abuse.
Neither result should be substituted for the other.
The practical consequence is simple: classify the observed mechanism before choosing a response.
8. What Google’s Web Study Shows—and Why Human Review Matters
Google’s April 2026 investigation examined Common Crawl snapshots for indirect prompt-injection patterns.
Its workflow combined pattern matching, model-based contextual classification, and final human validation. blog
The need for context was not incidental.
Google found that naive searches produced many false positives because security research and educational material legitimately quote suspicious instructions. The study also identified website content attempting to make AI assistants promote particular businesses. blog
This supports a core design principle for recommendation audits:
Detection is a lead, not a verdict.
The same principle applies to identity claims.
A page mentioning a monitored name beside a suspicious term may be reporting on abuse, discussing research, or referring to another person.
The auditor must inspect the relationship expressed by the text.
Google also describes limitations: Common Crawl does not cover much login-protected social content, and signature-based discovery may miss unfamiliar patterns. Its findings characterize observed attempts, not a complete census of the web or a universal attack-success rate. blog
9. Resistance Is Part of the Evidence
A credible account must examine barriers as carefully as threats.
The WWW 2026 paper Unveiling the Resilience of LLM-Enhanced Search Engines against Black-Hat SEO Manipulation evaluates ten representative products using SEO-Bench, a collection of 1,000 real-world black-hat SEO websites.
The authors report that more than 99.78% of the traditional SEO attacks tested were mitigated, with retrieval serving as the principal filter. They also identify vulnerabilities to adapted strategies targeting LLM-enhanced search. dl.acm
The result should not be interpreted as a general safety guarantee.
Nor should it be ignored because the article discusses threats.
Its direct implication for this series is that the following inference is invalid:
A suspicious page exists, therefore an AI assistant has relied on it.
Between publication and recommendation are several possible barriers: discovery, retrieval, filtering, interpretation, and use.
A monitoring system observes only the stages for which it has evidence.
10. An Evidence Ladder for Recommendation Integrity
I propose the following ladder for classifying findings.
It is an audit framework, not a claim that all systems expose every stage.
| Level | What has been established | What remains unproven |
|---|---|---|
| 1. Content observed | A page, snippet, document, or link was collected | Exposure of an AI system |
| 2. Claim identified | A specific identity, affiliation, or authority claim was documented | Truth of that claim |
| 3. Exposure evidenced | The material was supplied to or observably retrieved by the system | Acceptance or influence |
| 4. Attribution observed | The answer reproduced or assigned a relevant claim | That this source caused it |
| 5. Output difference measured | Outputs differed under declared comparison conditions | General causal attribution |
| 6. Causal influence supported | A controlled design supports an effect of the tested intervention | Generalization beyond that design |
This is not an automatic checklist.
Some systems expose retrieval traces; others show only selected citations.
An absent citation does not prove that material was never encountered.
A present citation does not establish that the source caused a recommendation.
Likewise, a before-and-after difference may reflect a model update, changing search results, personalization, or ordinary output variation.
The ladder’s purpose is to stop a finding at the strongest level its evidence supports.
11. Build an Evidence Record Before a Trust Score
The first useful output is a structured record, not a confidence badge.
A proposed record should preserve:
Entity information
- Internal entity identifier.
- Known names and aliases.
- Relevant language or writing-system variants.
- Distinguishing attributes.
- Known official channels, with verification basis and date.
Claim information
- Exact quoted claim.
- Claim type: identity, authorship, affiliation, endorsement, or authority.
- Subject and claimed relationship.
- Source URL and page context.
- Collection timestamp.
- Supporting, contradicting, or missing evidence.
AI observation
- User query.
- Platform and accessible configuration.
- Session and personalization conditions where known.
- Raw answer.
- Citations or retrieval traces where available.
- The entity to which the answer assigned the claim.
Action destination
- Displayed destination.
- Observed redirects.
- Identified operator where supportable.
- Relationship to the recommended entity.
- Remaining uncertainty.
Name normalization can assist matching, but the original text must remain available. Overaggressive normalization can erase distinctions between different people—a limitation already recognized in the identity-monitor design. dev
No unexplained score can replace these records.
12. How to Test Influence Without Manufacturing a Public Incident
A controlled follow-up study could use fictional entities and a local document collection.
That avoids publishing deceptive claims about real people or businesses.
The proposed experiment would separate two questions:
- Does an unsupported relationship claim enter the answer?
- Does a behavioral instruction change the recommendation?
These should be distinct experimental factors.
A possible design would compare:
- A neutral source.
- A source containing an unsupported affiliation claim.
- A source containing a recommendation-directed instruction.
- A source containing both.
Buyer requirements, product attributes, source formatting, and candidate order would otherwise be controlled.
The study would record separately:
- Claim reproduction.
- Attribution accuracy.
- Qualified recommendation incidence.
- Final choice.
- Citation behavior.
This is a proposed design, not completed research.
Its results would apply first to the tested environment. They would not establish the behavior of a commercial search product unless that product itself was tested under an appropriate, permitted protocol.
Memory persistence would require a separate study because immediate response influence and cross-session persistence are different outcomes.
13. What This Changes About ARS
ARS remains a measure of qualified recommendation incidence.
It should not silently become a fraud score or a measure of verified truth.
If a system recommends a brand, that event remains an observed recommendation—even if a later audit raises questions about its supporting attribution.
Deleting it from the dataset would obscure the behavior the study is meant to examine.
Instead, preserve the recommendation and add evidence-linked annotations.
For example:
| Observation | Recorded interpretation |
|---|---|
| Qualified recommendation present | The recommendation event occurred |
| Cited endorsement unresolved | The relationship could not be verified |
| Merchant relationship contradicted | Observed evidence conflicts with the claimed relationship |
| External instruction detected | The source contained a behavioral directive |
| Influence not established | No causal conclusion is supported |
An increase in ARS establishes a change in observed recommendation frequency under the declared protocol.
It does not, by itself, explain why the change occurred.
Nor does it establish that the increase was earned, manipulated, beneficial, or commercially effective.
Those are additional questions requiring additional evidence.
14. Human Review Belongs at the Action Boundary
The identity-monitor architecture separates analysis from external action.
A model can summarize a page, extract a claim, assemble a timeline, or draft a factual report. It should not turn an uncertain classification into an accusation, complaint, or legal submission without review and approval. dev
The same boundary belongs in recommendation auditing.
A useful workflow is:
[
\text{Observation}
\rightarrow
\text{Evidence review}
\rightarrow
\text{Finding}
\rightarrow
\text{Proposed response}
\rightarrow
\text{Authorized action}
]
Human review is not a guarantee of correctness.
It creates a point at which the proposed interpretation, affected entity, recipient, and action can be examined.
The intervention should match the evidence.
A stale search result, a mistaken affiliation, a deceptive instruction, and a compromised page are not the same incident.
They should not automatically trigger the same remedy.
15. Measure Review Quality, Not Suspicion Volume
An integrity system can generate many alerts while contributing little understanding.
Its evaluation should include:
- The proportion of reviewed alerts supported by evidence.
- Errors in matching distinct entities.
- Unsupported attribution findings.
- Unresolved cases.
- Reviewer agreement.
- Review effort.
- Time to a justified determination.
- Outcome evidence after an approved response.
Recall should be claimed only against a sufficiently defined evaluation set.
Search observations alone do not establish comprehensive coverage.
The original monitoring design also distinguishes source cleanup from search-result updates, and a submitted report from confirmed resolution. These distinctions should carry into recommendation monitoring. dev
A cleaned page does not prove that every downstream representation has changed.
A changed answer does not, without further evidence, prove that remediation caused the change.
Conclusion: Trust Requires Preserving the Relationship
The AI Recommendation Economy cannot be understood through exposure alone.
The earlier articles asked:
Who is recommended?
Can the recommendation become an actionable offer?
Does the purchase path preserve the buyer’s requirements?
Part 9 adds another question:
Does the evidence preserve the identity and relationships on which that recommendation depends?
Security reporting documents attempts to promote external content into persistent source authority. Web monitoring finds promotional instructions in public pages. Research also shows that retrieval can block substantial amounts of traditional SEO manipulation. Together, these findings support investigation—not automatic suspicion and not automatic trust. microsoft
The task is to preserve the boundaries:
A name is not a verified identity.
A mention is not an endorsement.
A citation is not proof of authority.
A detected instruction is not a successful attack.
An executable destination is not proof that the user was correctly informed about it.
The contribution of an integrity audit is not a universal declaration that an entity is trustworthy.
It is a reviewable account of what was claimed, which entity it concerned, what evidence supports the relationship, and where uncertainty remains.
That is the next step from executable to trustworthy.
Author:Seyed Alireza Alhosseini Almodarreseih
my site :https://almodarresieh.github.io/
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.