posit-dev / posit-dev/positron

Epic: 2026.10 Providers and Auth

Open
#15,741 0 comments 0 reactions 1 assignee View on GitHub

@sharon-wang is already working on this.

Since Sep 3, 2026.

area: assistant epic
Dominant language
TypeScript
Stars
4.3k
Forks
184
Avg merge
1d 9h
Merged PRs (30d)
195

Description

High-level goals

  • less duplicative efforts when supporting a new provider, or when adding enhancements/fixes for an existing provider, across:
    • auth layer
    • LLM comms layer
    • UI layer
  • provider availability and authentication support consistency and alignment across Posit Assistant clients
  • shift auth ownership from Positron to Posit Assistant, so that it's owned by the agent harness

Full doc: https://docs.google.com/document/d/1fUz8cUdGL4c8ifH1hvhlQWEQTKayykxTF8AHNmHR_Y4/edit?tab=t.q8ufmliv760w

Spike 1: shared credential & auth architecture

Where the "one owner" of auth logic lives, and the reusable auth-method abstraction it needs to support, so headless features (notebooks, Posit AI NES, git commit messages) don't need full Posit Assistant dependency the way chat does today, and we can consolidate the bulk of the auth handling in a single place.

What we hope will be alleviated by the architectural direction from this spike

Spike 2: non-AI providers & shared credentials

Related to Spike 1, but to review the credential situation for Connections and how the shared credentials direction of Spike 1 for AI providers affects credential sharing for Connections. Pertains only to Connections-relevant providers like Snowflake, Databricks, etc.

For 2026.10, our goal is: for creds to automatically take for both Connections and AI Providers, then Workbench Managed Credentials is the solution (for Snowflake, Databricks, Foundry, AWS), and equivalent support for Desktop is available if you set creds via environment variables.

The Connections workstream will also be exploring support for Workbench Managed Credentials in 2026.10.

What we hope will be alleviated by the architectural direction from this spike

Spike 3: provider configuration UI

This spike is focused on the UI aspect of authentication. Currently, Positron has its own providers modal, and Posit Assistant also has its own for standalone/RStudio.

What we hope will be alleviated by the architectural direction from this spike

Spike 4: AWS Kiro support

There was a customer request to support AWS Kiro as a model provider rather than directly interfacing with AWS Bedrock. Primarily of interest because of easier/different authentication model rather than AWS Bedrock. Let's do a limited (less than 1 hr) investigation on how we might support this (in Posit Assistant ideally, given Spike 1).

Other

Not directly nested under any spike.

Issues to defer until after re-architecting/spikes

At present, these generally involve making changes in ai-lib/Assistant that we would currently need to duplicate efforts for in Positron.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.