Influencer vetting agent

This page explains how an influencer vetting agent uses public web search to vet candidate creators' public profiles, past content, and brand safety risks, and produces a due-diligence report for human decision-making. After reading it, you will understand which modules this scenario needs, when interactive consent is actually needed, and why risk rules and due-diligence conclusions belong in a versioned review system rather than Memory.

Use case

Marketing teams need to evaluate creator audience fit, past content, brand safety risks, and campaign fit. Candidate lists often run to dozens of creators; manually digging through each platform's content history is slow and leaves no evidence — and a brand safety verdict without sources cannot be re-verified.

Typical triggers:

• A new campaign's candidate list is drafted, and batch due diligence must finish before outreach.
• A contracted creator is rumored to have posted controversial content, and their recent public content must be re-checked.
• Brand safety rules change, and the existing candidate pool must be re-screened.

Engineering challenges

• Public information is scattered and time-sensitive: controversy leads spread across social, news, and video platforms. Missed searches miss real risks, while citing stale coverage produces false verdicts — both coverage and recency must be traceable to be reviewable.
• Risk verdicts must be re-verifiable: an unsourced "this candidate is a brand safety risk" cannot support a partnership decision, and cannot defend itself when the verdict is challenged or the candidate disputes it; every risk must land on a concrete public source.
• The boundary around personal data is sensitive: due diligence handles a natural person's public information, and conclusions may only serve this evaluation — accumulating long-term person risk profiles as general-purpose data is itself a new compliance risk.

Module composition

Module	Role	Notes
GenAuth	Core	Silent delegation issues the short-lived runtime credential every product call requires; interactive consent is only needed when login state or write actions enter the picture. Credentials are short-lived and revocable.
Web Agent	Core	Searches candidates' public social profiles, personal sites, and press coverage through WebSearch, keeping a source link per lead.
GUMem	Not used	Brand safety rules and forbidden categories are versioned policy — keep them in your policy store and inject them per version; due-diligence conclusions are archived by version in your review system. Person risk profiles never accumulate in general-purpose Memory.

When interactive consent is needed

Every product call requires a GenAuth delegate token; public read-only scenarios are covered by silent delegation. This scenario only reads candidates' public data, so silent delegation with products: ['webSearch'] covers it — no site sign-in involved; credentials are short-lived and revocable at any time. Only the following cases require escalating to interactive consent, confirmed by the user in Qoni Console:

• Signed-in marketplace or CRM data such as rates and partnership history is needed.
• A controlled browser session must open signed-in platform pages for extra evidence.

Note: the SDK example requests a product-level delegation (webSearch). Fine-grained constraints — candidate list ranges, search boundaries — are enforced by the GenAuth Agent Profile or your policy layer, not by the task prompt; that configuration is not shown on this page. See Delegate token and attenuation for the full semantics.

Workflow

1. The user selects the campaign and candidate creator list.

2. GenAuth issues a silent delegation credential for this task, covering only the webSearch product.

3. Your app loads the current version of brand safety rules, target audiences, and forbidden categories from the versioned review system and injects them into the search task.

4. Web Agent searches each candidate's public social profiles, personal sites, and press coverage through WebSearch, keeping a source link per lead.

   Checkpoint: Leads without a source link are dropped; WebSearch only reads public pages — no sign-in, no outreach.

5. Your app organizes each candidate's risks and audience fit against the rules, each conclusion with a public source.

6. The Agent returns the due-diligence report — fit summaries, risks, a source list, and open questions for humans — with the policy version and an audit id; conclusions are archived by version to the review system, never written to general-purpose Memory.

   Checkpoint: Every risk conclusion should trace back to a concrete public source; judgments without evidence should not enter the deliverable.

Example code

The example below wires this scenario into your backend with the official Qoni SDK (@qoniai/qoni): silent delegation (the webSearch product only) → load brand safety rules from your review system → webSearch.run() to research each candidate's public data → parse and validate the leads → archive conclusions by version.

import { Qoni } from '@qoniai/qoni'

const qoni = new Qoni({
  accessKey: process.env.QONI_ACCESS_KEY!,
  secretKey: process.env.QONI_SECRET_KEY!,
})

export async function vetCandidates(userId: string, candidates: string[]) {
  // 1. Silent delegation: public data only — request just the webSearch
  //    product, no site sign-in involved
  const { data: grant } = await qoni.delegateToken({
    user: { id: userId },
    agent: 'influencer-vetting',
    products: ['webSearch'],
  })

  // 2. Before the run: load brand safety rules and forbidden categories
  //    from YOUR versioned review system (not Memory)
  const policy = await loadVettingPolicy() // e.g. { version: '2026-08', riskRules: [...], forbiddenCategories: [...] }

  // 3. WebSearch researches each candidate's public data and controversy
  //    leads, one source link per finding
  const search = await qoni.webSearch.run({
    token: grant.token,
    prompt: `
      For each creator candidate (${candidates.join(', ')}), find public social
      profiles, personal sites and press coverage. Summarize risk-relevant
      signals against the vetting policy below, and return findings as a JSON
      array of { candidate, signal, ruleId, sourceUrl } objects — one source
      link per finding. Public information only; never infer sensitive
      attributes or make rejection decisions.

      Vetting policy (version ${policy.version}):
      ${JSON.stringify(policy)}
    `,
    maxResultsPerQuery: 5,
  })

  const result = await search.wait()

  // 4. Validate the output contract on the app side: leads without
  //    a source link are dropped
  const findings = parseFindings(result.output).filter(
    (f) => f.sourceUrl && f.ruleId,
  )

  // 5. Archive conclusions by policy version to YOUR review system —
  //    never into general-purpose Memory
  await archiveVettingReport(candidates, findings, policy.version)

  return {
    findings, // for human decision: the final partnership call stays human
    policyVersion: policy.version,
    audit: { auditId: grant.auditId, permissionBoundary: grant.grantedScopes },
  }
}

The output structure is a contract set by the task prompt: here it is an array of { candidate, signal, ruleId, sourceUrl }, parsed and validated by parseFindings on the app side, and any entry missing sourceUrl or ruleId is dropped. The SDK itself returns the generic RunResult (runId, status, output, and so on).

Data and memory boundaries

This scenario touches four kinds of data; none of them needs GUMem:

• Versioned rules: brand safety rules, target audience definitions, forbidden categories — managed by version in your policy store, with every risk conclusion citing a rule version.
• Business state: due-diligence reports, risk leads, and source lists — archived by rule version to your review system for review and dispute handling.
• Audit records: the delegation and behavior chain formed by grantId and auditId — maintained by GenAuth.
• User Memory (optional): this scenario neither recalls nor writes back by default; person risk profiles explicitly never accumulate in general-purpose Memory — candidates' public information serves this due-diligence run only and is handled by your data retention policy afterwards.

Failure handling

Situation	Recommended handling
A finding lacks a source link	App-side validation drops the lead; better no verdict than an unsourced one.
A public source page is deleted or unreachable	Keep the failure record and mark related risk items as having incomplete basis; never substitute cached content.
WebSearch cannot cover a candidate	Mark them as having insufficient data and hand them to a human for follow-up; never fill in conclusions by speculation.
Search results point to a namesake	Mark the identity as unconfirmed and have a human verify before the finding enters the report.

Production notes

Do not infer sensitive attributes or make automatic rejection decisions. Final partnership decisions should stay with humans. The Agent only reads public web pages — it never messages, comments, or initiates outreach to creators; candidate personal data is limited to publicly visible information, used only for this due-diligence run, and never accumulated into general-purpose profiles. Searches should respect the source sites' terms of service.

Next steps

• Read the Quickstart to run the shortest path for Agent identity and delegation.
• Read Authorization and browser sandbox for the security boundaries of controlled sessions.
• Continue with the Review mining agent for an adjacent scenario.