Transcript#
This transcript was generated automatically and may contain errors.
Hello everyone. Thank you for joining me this month for our monthly workflow. My name is Sam Edwards, and I'm a Product Manager here at Posit. This month, I'm excited to talk to you about AI Governance in Workbench. We're going to look at an AI policy and talk about how we can implement it for data scientists using Posit Workbench, Posit Connect, and Posit Package Manager.
Let's start with a common question that we at Posit are hearing from our customers. They want to know, can we let the data science team use AI? You can't say no. AI is so helpful for data scientists to get their work done, and even if you did say no, they'd probably find a way to use it anyways, whether on their phones, their personal accounts, etc.
On the other hand, you can't say yes. There's risks using AI. What if they use it in a way that's against your company's policy, or if data that is not supposed to be exposed is? That is, you can't say yes unless you have a way to enforce your organization's AI policy. Throughout this workflow, that's what we're going to look at today.
On the screen, I have an example AI policy, and we're going to look at how we can apply this policy using Workbench, Connect, and Package Manager.
Posit's approach to responsible AI
Before we get into the specifics, let's take a moment and step back and talk about why Posit and why we care so much about responsible AI. At Posit, we've always cared about something called the Prime Directive. The Prime Directive comes from John Chambers, who created the S-language at Bell Labs. The S-language eventually became R. In 2008, he wrote down a rule called the Prime Directive. Software for data analysis must be trustworthy, and it must be shown to be trustworthy.
Software for data analysis must be trustworthy, and it must be shown to be trustworthy.
We believe that code is the only way to satisfy the Prime Directive. A person can read code, a person can review it, they can test it, and run it again. You can't do that with a point-and-click tool, and you can also not do that with a conversation with a chatbot. We hold this Prime Directive lens to everything we're building with AI as well. We ask whether it can be trusted, and whether that trust can be shown.
In terms of doing responsible AI, there's four principles that we have developed at Posit. Keep in mind, this is our current best thinking. The AI environment is changing so quickly, these principles might change as well.
But the first principle is code first. We believe this is the only way to satisfy the Prime Directive, and nothing changes with the use of AI here. Code is inspectable and reviewable, and is the only way to show the analysis is trustworthy. Second, we believe that a human should be in the loop. The human is the expert, and ultimately the accountable person. The AI is the co-pilot, helping the pilot work more efficiently.
Next, we believe that the AI should be session-aware, yet data-private. And these two things are often in tension with one another. Session-aware means the AI has access to all the context it needs to do correct analysis. However, you don't want to expose sensitive data to an LLM or some model provider where that data is not allowed to go.
And then fourth, governed environments. A governed environment means the system enforces compliance, not the individual. At Posit, we often talk about the pit of success. The pit of success is where someone does the right thing without even trying. The system is set up in such a way that they have no choice but to fall into the pit of success. Throughout this workflow, we're going to look at how we can use Posit Workbench, Posit Connect, and Posit Package Manager to force users into the pit of success.
What we are governing
Okay, let's start by talking about what we are actually governing. There's a few different tools here. The first is Posit Assistant. Posit Assistant is a coding harness built for data science. You can use it with many different models and many different model providers, and it's built into RStudio and Positron.
Next is Posit Workbench. This is where your team writes their code in Positron, RStudio, Jupyter, and VS Code, and where they actually use the Posit Assistant. Next is Posit Connect. This is where your data science team deploys their finished work. It could be interactive apps like a Shiny app. It could be a chatbot using Elmer or Chatless. And you can also deploy MCP servers to Posit Connect.
Next is Posit Package Manager. This is where your team installs R and Python packages from, Node.js packages, VS Code extensions, and most recently, and relevant to this workshop, is agent plugins. We'll look at this more later. And lastly, this diagram depicts how all these tools come together. We have our AI policy, which is enforced from the top. We use Posit Workbench to enforce that policy. Posit Connect and Posit Package Manager play a role as well. And then users are doing their work in Workbench, in Positron, or RStudio, with the Posit Assistant.
Applying the policy: who gets AI access
Okay, let's start to apply the policy. The first two items on the policy say AI coding assistance is off by default, and only approved groups can turn it on. And then second, contractors and the regulated analytics team get no access to AI. So two very specific things.
To apply these two policies, there is a single configuration file. Workbench has a notion of profiles where you can apply different settings to different users and groups based on who they are. In this example here, we have the Posit Assistant turned off by default. This applies to everyone based on the star syntax. So if a user logs in, they will not be able to use the Posit Assistant unless they're in the data science group. So the next key, we say assistance enabled equals one. This means anyone in the data science group can use the Posit Assistant. And then lastly, we are explicitly excluding a known contractor. We're saying they do not get access.
These names and groups come directly from your identity provider, whether that be Okta or Entra. So you're not requiring the Workbench admin to create these groups and keep them up to date. They're coming from your centralized source of truth. So with a few lines of configuration, we now have complete control over who can use the AI features in Workbench.
Controlling model providers and models
So we've covered the first two items. Let's take a look at the next one. The next two policies say that only approved models can be used and all model traffic must terminate in our own tenancy. Let's look at how we will achieve this.
There's a few different controls that are called out in this model. So the first is we need to say which vendors you can use or which model providers, for example, Bedrock, OpenAI, Anthropic. We then need to specify which models from those vendors are allowed for use. And then lastly, there's some concerns around networking and where the traffic terminates.
Let's look at the first item, which is providers. Workbench has a new configuration file called providers.json, where you can control which model providers your users have access to. This is an enforced setting. There's no way for users to override this. So in our case, the only approved model provider is Bedrock. So by default, we turn everything off and then we have a key that says Bedrock and we've enabled it to true. We also have a AWS key and here we apply some specific settings. This is enforced. There's no way now for a user to use a model provider other than Bedrock.
To actually apply this file, we're going to use the RStudio profiles again. So under the data science key, you can see we have a new setting, AI providers enforced, and we pointed it at that configuration file that we just created. So now anyone in this group will have those settings enforced. This is a pretty simple example, but you can imagine more complex examples where there's many users, many groups. And if we want to apply different rules, we can do so with many different providers.json files.
Next, we're going to talk about model access. So under the Bedrock key, we've added a new field, models allow, and in here we've listed Sonnet 4.5. In our imaginary company, we're enforcing the AI policy for the only approved model is Sonnet 4.5. So we've listed it here. When a user opens Positron or RStudio and they open the Posit Assistant, the only model in the dropdown they will see is Sonnet 4.5. The only model provider they will see is Bedrock. It's not possible for them to use anything else. It's enforced.
I've started a Positron session here in Workbench and I want to show you that I only have access to Bedrock and I only have access to Sonnet 4.5. I have the Posit Assistant here open and if I click on settings and then configure LLM providers, the only provider is Bedrock. It's not possible for me to add any other providers. And I also wanted to show the only model I have access to is Sonnet 4.5. Again, it's the only one in the dropdown. It's not possible for me to change. And I can ask the Posit Assistant a question and start working.
Networking and AI gateways
And lastly, let's talk about networking. So first we want to clarify what Posit the company sees. Posit the company does not see anything. We don't see any of your AI activity or any of your conversations. Posit Assistant is a harness built into Positron and RStudio. And that harness can see everything that it needs to do effective work.
So the Posit Assistant can read your active session. It can see the data frames you have, the variables you have. It can see the columns of those data frames, the types. And this allows it to do effective and correct data analysis. It can also write code and read code in the console, which makes it really effective at iterating through.
And so to clarify, Posit the company doesn't see anything, but the Posit Assistant, the harness running on your infrastructure, has access to everything it needs to do effective analysis.
And there's one more layer on networking as well. We have support for AI gateways. So if your organization is using an LLM or AI gateway, you can enforce all traffic through it. There's two places where you configure that. You can see here in Positron settings, we've configured an endpoint that traffic has to go through. And also in our providers.json, we've modified the base URL so that it's going through your AI gateway. These are all configurable, and they're also enforced, so users cannot override it.
API key management
Okay, so we've now finished number three and four. We've configured it so that only Bedrock can be used, and we've also allowed only Sonnet 4.5, and we've also set up a LLM gateway that we're forcing all traffic through.
Next, we'll look at policy number five, which says no individual can hold a model provider API key. You can imagine in the context of Bedrock, a user would log into AWS. They would generate the temporary keys they need, paste them into their environment, and start working. This is not a great experience for users because it involves copying and pasting, and it's also not secure because those keys could potentially be leaked.
So Workbench has several integrations for different model providers, where an admin sets up the integration, and then when a user logs into Workbench, it just works. Today, we have this for Bedrock, Snowflake Cortex, and Microsoft Foundry. And for other model providers not listed here, users can log in through OAuth or API key, and we look to provide better support for those in the future as well.
So in our case, we're using Bedrock. The admin sets it up. A user logs into Workbench. They never need to see or touch an API key. It's secure by default.
Reporting and auditing AI usage
Our next policy is around AI usage. Policy number six says we must report who used AI, how much, and for any period. So I'm going to break this into two sections. There's some stuff that we can't answer today, and then there's some other things that are more exploratory that we're working on building into the products.
So the first is Workbench auditing and Posit Chronicle. There's all sorts of activity that gets logged about how users are using Posit's products. Again, this logging doesn't go to Posit. It stays on-premise in your environment and is available to you. You can see things like what kind of sessions, are people starting, or how long, and all this data gets aggregated and centralized in Posit Chronicle where you can query and report on it.
Number two is console auditing. In RStudio and in Positron, there's a console where users can execute R and Python code. It's possible to audit all of the activity in here by turning on the audit R console setting. For Positron, right now, we only have support for monitoring the input and in RStudio, we can monitor the input and the output.
And then lastly, item number three, within the Posit Assistant, we give you some token level or session level metrics about your token usage. You can see how much you're spending and we give you insights about the context and how it's being used. This is helpful for using AI in a responsible way, making sure you don't have any runaway sessions that get out of control.
There's also lots of more experimental things that we're thinking about implementing into our products as well. The first is centralized utilization metrics. We're experimenting with ways to collect AI usage across Workbench, across Connect, and let admins query from a centralized location. This is still experimental, but hopefully we'll have more to show here soon.
We're also looking at integrating AgentsView into Workbench. AgentsView lets users look at historical sessions they've had, identify trends in it, and understand how they're using AI. It's a very powerful feature and can be used to improve your AI patterns.
We're also looking at implementing cost controls. This is really important for model providers like Bedrock that don't provide granular user level cost controls out of the box. And then lastly, we're looking at agent versus human attribution in our console logging. So right now it's possible for the Posit Assistant to execute our Python code in the console, which is very important for the Assistant to be able to effectively loop and do correct analysis. What we're looking at adding is a record that indicates whether the code was executed by a human or by an agent. Stay tuned for this. Should be available soon.
Governing packages and agent plugins
Okay, so we looked at number six on reporting. There's some stuff that's already built and some stuff that will be coming soon and will improve the monitoring story.
Okay, now policy number seven around controlling the packages and agents can use. So agents can install packages only from improved internal repositories. When we say packages, there's two different angles that we're going to take on this. The first is R and Python packages. A package manager already does this. With package manager, you can have curated repositories where users are only allowed to install a approved list of R or Python packages.
These same settings will apply to agents as well because it's configured globally at the Workbench and Connect level. It won't be possible for an agent to install a package that's not been explicitly approved in the case of a curated repository. And then we can also be a little less verbose. We can have block list rules so we can block all packages based on certain characteristics. For example, packages that have no vulnerabilities or packages with a specific license type. And more recently as well, we added support for a cooldown age. So you can specify the packages must be older than a certain threshold, for example, 24 hours. And again, you don't need to do anything separate for your agent usage here. Package manager has already been configured and the agent will use that just like users.
What's more new and novel is package manager now has support for agent plugins. You can think of agent plugins as a way to extend the capability of your models. They can include skills, commands, hooks, MCP server definitions. So as an admin, you can define the plugins that are allowed to be used and then make them easily available to users.
So let's take a look at an example. In this configuration file that we're looking at, we have a strict known marketplaces key. And in here we define a single plugin that users are allowed to use. And you can see it's pointing to a Posit package manager instance. And then we also make this enabled by default using the extra known marketplaces key. So when a user starts Positron for the very first time, this plugin is going to automatically be there.
We're now looking at Posit package manager. You can see I have several different repositories set up here. I have CRAN, VS Code extensions with OpenVSX, agent plugins, and PyPI. Let's focus on agent plugins. If I click on here and explore the packages, I can see I have one plugin. It's the simple English plugin. And if I click on it, it will give me instructions on how to do configuration based on the tool I'm using.
Now let's jump back to my Positron session. If I click on settings, plugins, this opens the plugin view. And if I go to marketplaces, you can see the simple English plugin. It's already here. There's a lock. So it's not possible for me to remove this extension as a user. And it's also not possible for me to add more extensions. It's grayed out here. I can't click on it because the admin has to find the ones that are allowed. And again, this shows up without the user having to do anything.
So number seven, we've controlled which R and Python packages agents can install. And we've also extended the capabilities of them using agent plugins with Posit Package Manager.
Governing AI content on Connect
Next, we're going to look at governing AI content. Policy number eight says AI-powered content needs a named owner, an access list, and a deployment record. So there's a few ways we're going to do this on Posit Connect.
First is Posit Connect has support for MCP servers. You can deploy MCP servers that extend the capability of your agents. And then you can enforce the use of those MCP servers using plugins like we saw in the last section. And then with Posit Connect, you can also deploy AI-powered content. By AI-powered content, I mean a few different things. You can deploy chatbots to Connect using packages like Elmer and ChatList. And then you can also deploy content that uses AI in its generation. For example, a Quarto document that used RAG as part of its analysis.
We're now looking at Posit Connect. And what I want to show is a Shiny for Python application that integrates the chatbot. And then I'll show how you have control over who has access to this content.
Posit Connect gives you a few things that are going to help with this policy. So every single piece of content on Connect has a named owner. So that is a person who is accountable for that piece of content. There's an access control list. So you can control which users or which groups have access to that content. And there's also a deployment record. You can see when content was deployed, when it was updated, and when important settings were changed.
This is the chat interface. We can ask it a question. And then if we go over to settings here, we have complete control over who has access to this chatbot. In this case, you can see it's only myself and Abby. No one else other than the people defined in here can use this.
I'm also going to show the audit trail and how it includes a bunch of information about how Connect is being used. If I go back to content, and then system, and then audit logs, because I'm an admin on this instance, I can see information like audit logs. And here you can see a detailed log of every action that's been taken. So just before I use that Shiny app, I associate it with an OAuth integration. And you can see a bunch of other records like appointments, change in ownerships, and other things. So there's a complete audit trail of everything that's happening on Posit Connect.
So with that, policy number eight is complete. We're using Posit Connect to have a audit trail and accountability for all the AI content that's running in your environment.
Summary
Okay, we've looked at a lot of different configuration files and settings, so I want to take a moment to step back and review some of what we've done. So there's three configuration files we mostly used. The Workbench profiles file, we looked at enforced provider settings, and we also looked at some enforced Positron settings as well.
First, we turned on the Posit Assistant for the data science team. You can see here, we have Assistant enabled one. For all other users, it's disabled. You can see this take effect. This is a screenshot of Positron when the Posit Assistant has been enabled. You can see you have access to it here, and this is a screenshot of a user, in this case, Charles, who does not have access to the Posit Assistant. It's been disabled, and you can see there's no way for them to access it here.
We also created a providers.json file, and in this example, we said only Bedrock is allowed, and then we've said the only model allowed is Sonnet 4.5. So in this first screenshot, you can see Bedrock is the only model provider, and then in the next screenshot, we can see Sonnet 4.5 is the only model from Bedrock that users are allowed to use. And again, with all these settings, we pushed users into the pit of success. It's not possible for them to override these settings.
And then lastly, we set up some approved plugins. So here, we've said the only plugin you're allowed to use is the simple English one that's hosted on Package Manager, and we've made it available by default. And here's a screenshot of Positron, and it's showing the simple English plugin is there. It's locked. Users can't remove it, and the Add button is also grayed out. It's not possible for users to add additional plugins.
Okay. Let's take another step back and talk about what we've done at a big picture. So we have an AI policy that is defined in a set of configuration files. You can look at your AI policy and then look at the configuration and see how it's applied. You have control over the providers, so we've only allowed Bedrock. You have control of the models. We've only allowed Sonnet 4.5, and you have control over the networking through things like using AI gateways, or you can set up firewall rules as well within your infrastructure provider.
Nobody holds an API key. In the case of Bedrock, a user logs into Workbench, and they have access to Bedrock. They don't need to refresh API keys, which is annoying for them, and there's no risk of them potentially exposing them. We're using Posit Package Manager to govern the agent's capabilities, so we control the R and Python packages the agent can use, as well as the plugins that it has access to. And then lastly, we're using Posit Connect as a secure way to deploy MCP servers and also as a secure way to deploy AI-powered applications like chatbots.
And again, with all these settings, we pushed users into the pit of success. It's not possible for them to override these settings.
Thank you for joining us on this month's workflow session. We hope that you are excited about what we're building, and we'd be happy to take any questions you have.