Hi,
we are looking into integrating models that we serve on our own infrastructure as a coding assistant in positron.
As a tightly regulated business we have several enterprise requirements any solution must fulfill:
- We use models from our own infrastructure and providers. Publicly served models from the ususal suspects are out of the question, we need to connect our own.
- Ideally we would have enterprise SSO authentication (kerberos) for each user but lack thereoff is not an absolute showstopper right now.
- We need a R/python context aware coding assistant. An AI agent is unthinkable due to the security risk it poses. An LLM with rights to install packages and execute shell commands "restricted" only by a text file is an IT-sec nightmare and the yolo approach of these agents is not something we can do.
The main issue
- The biggest issue is the confusion arround positron assistant vs posit assistant: Agent vs. context-aware chat / coding assistant.
- As far as we understand the coding assitant, positron assistent, will be EOL and only the agent option will be available. This would make this implementiation unusable for us. So what we need is an option that offers coding assistant without the agentic part. No access for code execution or the shell.
Will this option be available?
Hi -- happy to cover a little bit of the roadmap of Posit Assistant as well as Workbench-level AI Governance, with you if you'd like to reach out I am thomas at posit.co.
I have worked with higher security customers on setting up their own internal gateway or even self-hosted models to avoid sending any data external to their servers. Providers – Positron
Alternatively, many other customers have approved the same data provider for their AI tooling, ie AWS S3/Redshift + AWS Bedrock or equivalent for Azure, Google, Snowflake, etc.
On the pure Posit Assistant side, I think it's worth understanding more of your team's specific requirements before I assume we have the exact answer you need.
That being said, directionally, we do have some existing guardrails and fine-grained permissions.
Sandbox mode: Permissions & Trust — Posit Assistant
Per-project permissions for allowing or disallowing specific capabilities: Config File — Posit Assistant
We do want to expand some of the capabilities/control for constraining controls and either giving users privileges for turning on certain things or doing more admin-enforced guardrails for AI.
Hi Tom,
for us agents are out of the question. Sandboxing would need to be extremely strict, im thinking in the realm of rootless podman style of restrictions. Any kind of permissions restriction would need to be mechanically enforced (i.e. on the kernel level like with linux namespaces / capabilties). Bubblewrap seems to utilise this but when it comes to something as potentially destructive as an agent the sandbox used would need to be well developed, proven and supported. Something on the maturity level of rootless podman. On a first glance bubblewrap is not at that level and we would need to investigate the parameters with which bubblewrap is called.
-
Due to obvious geopolitical reasons any US hyperscaler is out of the question, we use a domestic supplier.
-
We just need the behaviour of the positron assistant. No agent capabilities.
Understood on the regional constraints, while not identical, this is similar to some customers who choose to self-host open-weight LLMs to avoid leaving either physical or virtual private environments via our Custom Provider support.
We just need the behaviour of the positron assistant. No agent capabilities.
I am sorry for not fully understanding this ask.
Positron Assistant still had agentic capabilities such as:
- File Read and Write/Edit
- R/Python Session awareness and inspection
- Ability to suggest and/or run code in the console/notebooks
- Ability to suggest and/or run code in the shell/terminal
A few examples in Positron 2026.04.0 via Positron Assistant:
Given Positron Assistant included Agentic capabilities, could you provide a bit more context on what behaviors/capabilities are in-scope vs out-of-scope? Were there specific tools your team was disabling? Specific agent modes you were defining or filtering? Is the goal to provide a Chat-only experience where the harness only has read permissions?
It would be really helpful to understand the workflow you are hoping for your user community.
Thanks for the time!
