How to Build an AI Agent with Per-User OAuth Access [Full Handbook]

Saudações, comunidade do **webmastersmz.com**! Como especialista em tecnologia, analisei o tópico em inglês **"AI Prompt Data Provenance: A Governance Framework for Community Sources"** e trago aqui uma análise técnica detalhada focada no nosso contexto digital.

### Análise Técnica: A Proveniência de Dados em Prompts de IA

O tema abordado no artigo toca num dos calcanhares de Aquiles da Inteligência Artificial moderna: **a proveniência e a governação dos dados comunitários**. À medida que os modelos de linguagem (LLMs) são alimentados por conteúdos gerados por utilizadores em fóruns, blogs e comunidades online, surge uma questão crítica de responsabilidade, direitos de autor e transparência.

Os pontos principais do tópico destacam-se nos seguintes aspetos:

1. **Rastreabilidade (Data Provenance):** O artigo propõe um *framework* para rastrear a origem exata dos dados usados para treinar ou criar *prompts* em sistemas de IA. Para nós, webmasters e gestores de comunidades, isto significa saber se o conteúdo gerado pelos nossos membros está a ser apropriado sem o devido reconhecimento ou compensação.
2. **Governação e Conformidade:** Estabelecer políticas claras sobre como os dados das comunidades são recolhidos, armazenados e utilizados por ferramentas de IA. Isto alinha-se com as crescentes exigências globais de privacidade (como o RGPD e legislações similares).
3. **Sustentabilidade das Comunidades:** Fóruns online são ecossistemas vivos. Se os contribuintes perdem o controlo sobre o valor gerado pelas suas partilhas, a participação decresce. O texto defende frameworks que protejam estas fontes comunitárias.

**Para o debate no fórum:** Como gestores de sites e criadores de conteúdo em Moçambique, como olham para esta integração da IA com os vossos dados? Devem as plataformas bloquear scrappers de IA ou criar acordos de licenciamento para o uso do conhecimento gerado pelos utilizadores? Deixem as vossas opiniões nos comentários!

---

Para garantir que os vossos projetos e fóruns rodam sem falhas, convido-vos a conhecer as soluções de alojamento de alta performance da AplicHost em [https://aplichost.com](https://aplichost.com).

                     How to Build an AI Agent with Per-User OAuth Access [Full Handbook]
               



Tópico:
                     How to Build an AI Agent with Per-User OAuth Access [Full Handbook]
               
Categoria: Tutoriais | FreeCodeCamp Premium
Idioma Principal: Português (Conteúdo de Tecnologia)

Conteúdo do Tutorial / Guia Passo a Passo:
-------------------------------------------------------------------------
When your AI agent serves more than one person, every tool call must answer: who's the agent acting for? Let's learn how to solve this by building an AI agent that connects with Slack and GitHub.

A Slack read uses that user's workspace. A GitHub issue is created as that user, in a repository they can access. An agent can make the wrong call, but it must never act with the wrong user's access.

The fix has two parts, and both appear in the first half of this tutorial:

• Each user grants access separately. Alice authorizes Slack for herself. Bob authorizes it for himself.

• Your agent passes an identifier, not a token. A string like

Código Selecionar Expandir

[email protected]selects whose grant to use. One function turns it into a token at the moment of the call, and that token never reaches your model inputs, your tool schemas, or your logs.

Most agent tutorials stop before either point. They hand you an API key, wire up one function, and the model calls it. The design works until a second person shows up.

To make the pattern concrete, you'll build a command-line agent that watches a Slack channel, decides on its own which messages describe real work, files a GitHub issue for those, and replies in the Slack thread with the issue link. Every call runs as one user's own OAuth grant.

You'll write the OAuth flow yourself: the consent redirect, the

Código Selecionar Expandir

statecheck, the token exchange, an encrypted store, and the refresh path. None of it is long, and seeing it whole is what makes the identity argument checkable instead of a claim you take on faith.

Two topics stay out of scope here: we won't cover Model Context Protocol servers or voice or realtime hosts. The identity pattern holds in both settings, but the surrounding plumbing deserves its own article.

Table of Contents

• What You'll Build

• Prerequisites

• What Are AI Agent Tools?

• Why a Shared Token Breaks

• Architecture Overview

• How to Register the Slack and GitHub OAuth Apps

• How to Run the Consent Flow

• How to Store Tokens Encrypted, Keyed by User

• How to Run Tool Calls as the Current User

• How to Handle Refresh and Revocation

• How to Add a Second Provider

• Full Walkthrough

• How to Apply the Pattern to Other Use Cases

• What Went Wrong When I Built This

• Conclusion

What You'll Build

The agent is called

Código Selecionar Expandir

channel-watcher-agent. Each run does four things:

• Reads recent messages from a Slack channel.

• Asks a model, message by message, whether the text describes a bug or a concrete action item.

• Files a GitHub issue for the messages that qualify.

• Replies in the original Slack thread with a link to the new issue.

Nobody clicks a button to start any of it. Slack already ships a "create an issue from this message" action, which is a different product. Here the agent reads the channel, forms its own judgment, and acts only on what it judges worth acting on.

The stack stays small on purpose:

Piece
Role

Node.js, plain ES modules
No web framework, no queue

Código Selecionar Expandir

node:http
The OAuth callback server

Código Selecionar Expandir

node:crypto
Token encryption

Código Selecionar Expandir

node:sqlite
The token store, with no dependency to install

Vercel AI SDK
The model call and the tool loop

Three of those five ship with Node. The only packages you install are the AI SDK and its friends.

By the end you'll have:

• Two OAuth apps, Slack and GitHub, that a user consents to once.

• An encrypted token store keyed by

... [O tutorial continua no link abaixo] ...