Knowledge Base Academy Community My Tickets
Fabric 8.5
Fabric 8.5 Fabric 8.4

Security and Privacy

Studio AI is an in-Studio assistant for K2View project implementation and coding productivity. This article describes how it handles data - what reaches the LLM, where the request goes, and the controls available to security and compliance teams evaluating Studio AI before enabling it for their organization.

Intended Use

Studio AI assists developers with implementation tasks inside a Fabric project. In normal use, the content sent to the LLM provider is project implementation material - schemas and table definitions, Broadway flow YAML, Java enrichment code, Logical Unit configuration, Graphit services, and similar - not customer end-user data or production business records.

The project artifacts that may reach the LLM provider are relevant project files the AI needs in order to examine the project and suggest changes or fixes - either attached by the user via #file, #_f, #selectedText, drag-and-drop, or the paperclip button (see Using the AI Chat), or read by the agent on demand through its tools.

If a project's working tree happens to contain business data - sample data files, fixtures, or test datasets checked into the project - that data can be sent to the provider if the user or an agent reads it. There is no built-in scrubbing of file content; see Controls below for ways to restrict this, including running fully on-premises with a local model provider.

Where Requests Go

Studio AI runs inside the K2View Web Studio, served from a Fabric Dev environment deployed in K2View cloud or in your infrastructure. The user accesses the Studio in a web browser, but the AI logic runs in the Studio backend on this Fabric Dev server.

The request path is:

  1. The user types a message in the AI Chat panel in the browser.
  2. The browser forwards the message and any attached context references to the server running inside your Fabric Dev environment.
  3. The server assembles the full prompt (system prompt, conversation history, attached files, tool-call results, and auto-injected content from the agent's prompt template; it may also contain K2View-provided skills and reference content, when relevant).
  4. The server makes an outbound HTTPS call to the configured LLM provider (for example, Anthropic, OpenAI, Google) using the API key provisioned in Studio settings. When Fabric is configured as the LLM provider, the call goes to Fabric instead, and Fabric calls the upstream provider using the credentials held in the project's AI LLM interface.
  5. The provider's response streams back to the server, which forwards it to the browser to display in the chat.

K2View does not host or proxy LLM traffic. The API key is held by your Fabric Dev environment - either in the Studio settings, or, when Fabric is the provider, in the project's AI LLM interface - and is used to authenticate against the chosen provider. Network egress to the provider must be permitted by your network policy.

For fully on-premises operation, Studio AI supports local model providers such as Ollama. When configured like that, no data leaves your environment - the model runs on the Fabric Dev server (or a network-reachable host) and there is no outbound call to a third-party provider. See Choose and Provision LLM for the full list of supported providers. The same applies if you choose a self-hosted LLM at your organization's private premises or cloud, using the Custom Models settings.

API Keys

API keys are entered in Studio AI settings (see Getting Started with Studio AI) and are stored as part of the Studio setup on the Fabric Dev server. They are not sent to K2View and are not transmitted to the browser after being saved.

Alternatively, configure Fabric as the LLM provider. Users then enter no API key at all: the provider credentials are defined once on the Fabric AI LLM interface, and access to the endpoint is controlled by the LLM_INVOKE permission granted to Fabric roles.

What Each Request Contains

Every request that Studio AI sends to the LLM contains, at minimum:

  • The system prompt of the addressed agent - a static text describing the agent's role, capabilities, and behavior rules. You can view and edit any agent's system prompt; see Agents Prompt Customization.
  • The conversation history of the current chat session (all prior user messages and agent responses). Sessions are local to a Studio user.
  • The current user message and any context the user attached to it.
  • The tool definitions the agent is allowed to call (their names, descriptions, and parameter schemas - not their implementations or results).

The following are not sent automatically:

  • Files outside the current workspace, unless an agent's prompt template explicitly references them.
  • Files inside the workspace that are not attached by the user, not read by an agent tool call, and not referenced by the agent's prompt template.
  • Files matched by standard ignore patterns the agent respects (for example, .git/, node_modules/).
  • Credentials, API keys, or environment variables of the Fabric Dev server.

Additional data is included in a request only when one of the following happens:

1. The user attaches context explicitly

Anything the user attaches via #file:, #_f, #selectedText, #imageContext, drag-and-drop, or the paperclip button is included verbatim in the prompt. This is the most common way project data reaches the LLM, and it is fully under the user's control.

2. The agent calls a tool

Most agents have access to tools that can read files, list directories, query workspace metadata, or run commands. When an agent calls a tool, the tool's output is appended to the conversation and becomes part of subsequent requests. For example, if @Coder calls a readFile tool to inspect a Java file, the file content becomes part of the request to the next model turn.

Tool availability per agent is visible in the Tools tab of AI Configuration. See AI Configuration: Managing Agents and Settings.

3. The agent's prompt template auto-injects content

Prompt templates support ~{readFile('...')}, ~{fragment('...')}, and other function references that pull content into the prompt every time the agent runs. See Agents Prompt Customization. This is how some K2View agents (for example, @Data-Product-Explorer or @Interfaces) include project metadata by default.

4. A capability is enabled

Agent Capabilities such as AppTester or shell-command execution can introduce additional tools - and therefore additional data sources - for the duration of a session. Capabilities are off by default and explicitly enabled by the user.

5. An MCP server is connected

MCP Servers expose external tools to agents. When a connected MCP tool is called, its inputs and outputs flow through the prompt. Each MCP server has its own data-handling characteristics; see the security notes in the MCP article.

Per-Agent Data Profile

The table below summarizes, for each commonly used agent, the kinds of project information that may be sent to the LLM as part of doing its job. The list reflects each agent's tools and prompt template - to see them yourself, open the Agents tab in AI Configuration and click the edit (pencil) icon next to a prompt template in the agent's Prompt Templates table. See Customizing Agent Prompts.

Agent Project information that may be sent to the LLM
@k2-assistant Project structure and the content of files it reads directly to answer or make a small edit; for larger requests it delegates to @k2-worker, which then applies to the same request.
@k2-worker Content of workspace files it reads or edits, plus terminal output, test results, and build logs when it runs commands as part of a delegated task. See [Studio AI Agents](02_studio_ai_agents_reference.html#k2-worker).
@Interfaces The list of interfaces in the project; the list of schemas for an interface; the table and column metadata of a schema. Does not read or send any row data from the source databases.
@Data-Product-Explorer Data Product / Logical Unit metadata: the list of LUs or Data Products and, for a selected one, its tables and schema. Supersedes the earlier @LU agent, which no longer exists.
@KB Nothing from the workspace. Sends the user question and retrieves content from K2View product documentation.
@Architect Project structure and the content of files relevant to answering a question about the project. Earlier documentation described @Architect as also generating implementation plans; that capability is unconfirmed in the current version. See [Other Studio AI Agents](14_other_studio_ai_agents.html#architect).
@Coder Content of workspace files; in Agent Mode also terminal output, test results, and build logs. See [Other Studio AI Agents](14_other_studio_ai_agents.html#coder-superseded-by-k2-worker).
@Code Reviewer The current Git diff, the content of files referenced by the diff, and any available build/lint/test output.
@Universal Only what the user attaches in the message - no automatic workspace access.
@GitHub Current branch and Git diff; issues, pull requests, and other repository data fetched from the configured Git remote; commit messages.
@Studio-Commands The list of registered Studio commands and the output of any command the agent invokes on the user's behalf.
@Broadway-Explain The list of Broadway core actors (Fabric framework reference); content of the active Broadway flow or any flow/actor file the agent reads; flow validation errors and warnings.
@Broadway-Edit The list of Broadway core actors (Fabric framework reference); the live in-memory state of the active Broadway flow - stages, actors, links, and port values.
@Graphit The JSON of the active Graphit file.
@ClaudeCode Content of workspace files; in long autonomous sessions also terminal output and test results.

Custom agents created by your team (see Creating Custom Agents) follow the same rules but may send different content depending on how they are configured.

Agents and Skills from the Studio AI Core Artifacts Extension

K2View publishes a Studio extension, the Studio AI Core Artifacts extension (available on K2Exchange), that supplies all of the built-in K2View-specific agents and skills described throughout this article set, including @k2-assistant, @k2-worker, @Interfaces, @Data-Product-Explorer, @KB, @Architect, and @Agent-Builder. See Getting Started with Studio AI. After installation, its artifacts are located under .agents/agents/ (agents) and .agents/skills/ (skills) in the project, with some reference content under .fabric-wiki/.

In addition to its agents, the extension imports a set of skills that any agent can call via slash command (see Skills and Slash Commands). At the time of writing, the installed skill catalog was: broadway-actor-builder, broadway-flow-builder, data-product-builder, data-product-cowork, debug-broadway-flow, fabric-commands, fabric-java-docs, fabric-overview, fabric-project-helper, fabric-troubleshooting, interface-builder, report-builder, and web-service-builder. Each skill is a SKILL.html file that the agent reads when activated; when the agent calls a skill, the skill's content is appended to the prompt and the agent then reads any further reference files the skill points to.

Two important properties of the imported plugin content for security review:

  • The bundled .fabric-wiki/ content is K2View Fabric reference material - actor schemas, Java API documentation, example flow patterns. It does not contain customer project content.
  • None of the skills or agents auto-inject customer data. They auto-inject only metadata about themselves (skill list, product info) and read reference or workspace files on demand through the same tool mechanism described in What Each Request Contains.

Audit and Visibility

Studio AI provides full visibility into every request and response. For any chat message, you can view the complete prompt that was sent to the LLM, including the system prompt, all auto-injected content, the conversation history, the user message, and tool-call results.

Open the AI Agent History panel via More Actions… ("…") in the AI Chat panel toolbar, then Open AI Agent History, and select the agent and request you want to inspect. The panel shows the full request body and the full response, with a unique request ID for support correlation. See Viewing Token Consumption and AI History.

This is the authoritative source of truth for what left your environment on any given request, and it is the recommended tool for security teams who want to audit Studio AI activity in a specific Fabric Dev environment.

Controls

Studio AI provides several layered controls. Use them in combination to match your organization's data-handling policy.

Enable or disable AI globally

AI features are off until an administrator explicitly enables them and provisions an LLM provider. With AI disabled, no data is sent to any provider. See Enabling Studio AI.

Choose where data goes

The LLM provider is configured per Fabric Dev environment. To keep all data on-premises, configure a local hosted LLM provider instead of a foundation cloud provider. To restrict to a specific cloud provider that has an enterprise data-handling agreement with your organization, configure only that provider.

Configuring Fabric as the provider centralizes this choice: the model and its credentials are set once on the AI LLM interface, developers cannot point Studio at a provider of their own, and use of the endpoint is restricted by role.

Disable individual agents

In the Agents tab of AI Configuration, you can disable any built-in agent. A disabled agent does not appear in the chat and cannot be invoked, so no data is ever sent through it. See AI Configuration: Managing Agents and Settings.

Customize agent prompts

Edit an agent's prompt template to remove or change any auto-injected content you do not want sent. For example, you can remove a ~{readFile(...)} reference from the template to stop a specific file from being included on every request. See Agents Prompt Customization.

Capabilities and MCP are opt-in

Agent Capabilities reset to off at the start of every session, and MCP Servers must be explicitly added by an administrator. Neither adds data sources silently.

Audit with AI Agent History

Use the AI Agent History panel (described above) to periodically review what is actually being sent - both during a rollout and as part of ongoing security monitoring.

At a Glance

  • Where requests go: outbound HTTPS from the Fabric Dev environment directly to the configured LLM provider. No K2View proxy.
  • Who holds the API key: the customer's Fabric Dev environment - in Studio settings, or in the project's AI LLM interface when Fabric is the provider.
  • What is sent by default: the agent's system prompt, the conversation history, and the user's current message. Some agents additionally auto-inject project structure or configuration metadata (see the per-agent table above).
  • What is sent on demand: files the user attaches, files an agent reads via tools, and outputs of any enabled capabilities or MCP servers.
  • What is not sent: API keys, credentials, server environment variables, or any data outside the workspace.
  • How to audit: every request is fully visible in the AI Agent History panel inside the Studio.
  • How to restrict: disable AI globally, choose a local LLM, disable specific agents, edit agent prompts to remove auto-injected content, or leave capabilities and MCP servers turned off.

Security and Privacy

Studio AI is an in-Studio assistant for K2View project implementation and coding productivity. This article describes how it handles data - what reaches the LLM, where the request goes, and the controls available to security and compliance teams evaluating Studio AI before enabling it for their organization.

Intended Use

Studio AI assists developers with implementation tasks inside a Fabric project. In normal use, the content sent to the LLM provider is project implementation material - schemas and table definitions, Broadway flow YAML, Java enrichment code, Logical Unit configuration, Graphit services, and similar - not customer end-user data or production business records.

The project artifacts that may reach the LLM provider are relevant project files the AI needs in order to examine the project and suggest changes or fixes - either attached by the user via #file, #_f, #selectedText, drag-and-drop, or the paperclip button (see Using the AI Chat), or read by the agent on demand through its tools.

If a project's working tree happens to contain business data - sample data files, fixtures, or test datasets checked into the project - that data can be sent to the provider if the user or an agent reads it. There is no built-in scrubbing of file content; see Controls below for ways to restrict this, including running fully on-premises with a local model provider.

Where Requests Go

Studio AI runs inside the K2View Web Studio, served from a Fabric Dev environment deployed in K2View cloud or in your infrastructure. The user accesses the Studio in a web browser, but the AI logic runs in the Studio backend on this Fabric Dev server.

The request path is:

  1. The user types a message in the AI Chat panel in the browser.
  2. The browser forwards the message and any attached context references to the server running inside your Fabric Dev environment.
  3. The server assembles the full prompt (system prompt, conversation history, attached files, tool-call results, and auto-injected content from the agent's prompt template; it may also contain K2View-provided skills and reference content, when relevant).
  4. The server makes an outbound HTTPS call to the configured LLM provider (for example, Anthropic, OpenAI, Google) using the API key provisioned in Studio settings. When Fabric is configured as the LLM provider, the call goes to Fabric instead, and Fabric calls the upstream provider using the credentials held in the project's AI LLM interface.
  5. The provider's response streams back to the server, which forwards it to the browser to display in the chat.

K2View does not host or proxy LLM traffic. The API key is held by your Fabric Dev environment - either in the Studio settings, or, when Fabric is the provider, in the project's AI LLM interface - and is used to authenticate against the chosen provider. Network egress to the provider must be permitted by your network policy.

For fully on-premises operation, Studio AI supports local model providers such as Ollama. When configured like that, no data leaves your environment - the model runs on the Fabric Dev server (or a network-reachable host) and there is no outbound call to a third-party provider. See Choose and Provision LLM for the full list of supported providers. The same applies if you choose a self-hosted LLM at your organization's private premises or cloud, using the Custom Models settings.

API Keys

API keys are entered in Studio AI settings (see Getting Started with Studio AI) and are stored as part of the Studio setup on the Fabric Dev server. They are not sent to K2View and are not transmitted to the browser after being saved.

Alternatively, configure Fabric as the LLM provider. Users then enter no API key at all: the provider credentials are defined once on the Fabric AI LLM interface, and access to the endpoint is controlled by the LLM_INVOKE permission granted to Fabric roles.

What Each Request Contains

Every request that Studio AI sends to the LLM contains, at minimum:

  • The system prompt of the addressed agent - a static text describing the agent's role, capabilities, and behavior rules. You can view and edit any agent's system prompt; see Agents Prompt Customization.
  • The conversation history of the current chat session (all prior user messages and agent responses). Sessions are local to a Studio user.
  • The current user message and any context the user attached to it.
  • The tool definitions the agent is allowed to call (their names, descriptions, and parameter schemas - not their implementations or results).

The following are not sent automatically:

  • Files outside the current workspace, unless an agent's prompt template explicitly references them.
  • Files inside the workspace that are not attached by the user, not read by an agent tool call, and not referenced by the agent's prompt template.
  • Files matched by standard ignore patterns the agent respects (for example, .git/, node_modules/).
  • Credentials, API keys, or environment variables of the Fabric Dev server.

Additional data is included in a request only when one of the following happens:

1. The user attaches context explicitly

Anything the user attaches via #file:, #_f, #selectedText, #imageContext, drag-and-drop, or the paperclip button is included verbatim in the prompt. This is the most common way project data reaches the LLM, and it is fully under the user's control.

2. The agent calls a tool

Most agents have access to tools that can read files, list directories, query workspace metadata, or run commands. When an agent calls a tool, the tool's output is appended to the conversation and becomes part of subsequent requests. For example, if @Coder calls a readFile tool to inspect a Java file, the file content becomes part of the request to the next model turn.

Tool availability per agent is visible in the Tools tab of AI Configuration. See AI Configuration: Managing Agents and Settings.

3. The agent's prompt template auto-injects content

Prompt templates support ~{readFile('...')}, ~{fragment('...')}, and other function references that pull content into the prompt every time the agent runs. See Agents Prompt Customization. This is how some K2View agents (for example, @Data-Product-Explorer or @Interfaces) include project metadata by default.

4. A capability is enabled

Agent Capabilities such as AppTester or shell-command execution can introduce additional tools - and therefore additional data sources - for the duration of a session. Capabilities are off by default and explicitly enabled by the user.

5. An MCP server is connected

MCP Servers expose external tools to agents. When a connected MCP tool is called, its inputs and outputs flow through the prompt. Each MCP server has its own data-handling characteristics; see the security notes in the MCP article.

Per-Agent Data Profile

The table below summarizes, for each commonly used agent, the kinds of project information that may be sent to the LLM as part of doing its job. The list reflects each agent's tools and prompt template - to see them yourself, open the Agents tab in AI Configuration and click the edit (pencil) icon next to a prompt template in the agent's Prompt Templates table. See Customizing Agent Prompts.

Agent Project information that may be sent to the LLM
@k2-assistant Project structure and the content of files it reads directly to answer or make a small edit; for larger requests it delegates to @k2-worker, which then applies to the same request.
@k2-worker Content of workspace files it reads or edits, plus terminal output, test results, and build logs when it runs commands as part of a delegated task. See [Studio AI Agents](02_studio_ai_agents_reference.html#k2-worker).
@Interfaces The list of interfaces in the project; the list of schemas for an interface; the table and column metadata of a schema. Does not read or send any row data from the source databases.
@Data-Product-Explorer Data Product / Logical Unit metadata: the list of LUs or Data Products and, for a selected one, its tables and schema. Supersedes the earlier @LU agent, which no longer exists.
@KB Nothing from the workspace. Sends the user question and retrieves content from K2View product documentation.
@Architect Project structure and the content of files relevant to answering a question about the project. Earlier documentation described @Architect as also generating implementation plans; that capability is unconfirmed in the current version. See [Other Studio AI Agents](14_other_studio_ai_agents.html#architect).
@Coder Content of workspace files; in Agent Mode also terminal output, test results, and build logs. See [Other Studio AI Agents](14_other_studio_ai_agents.html#coder-superseded-by-k2-worker).
@Code Reviewer The current Git diff, the content of files referenced by the diff, and any available build/lint/test output.
@Universal Only what the user attaches in the message - no automatic workspace access.
@GitHub Current branch and Git diff; issues, pull requests, and other repository data fetched from the configured Git remote; commit messages.
@Studio-Commands The list of registered Studio commands and the output of any command the agent invokes on the user's behalf.
@Broadway-Explain The list of Broadway core actors (Fabric framework reference); content of the active Broadway flow or any flow/actor file the agent reads; flow validation errors and warnings.
@Broadway-Edit The list of Broadway core actors (Fabric framework reference); the live in-memory state of the active Broadway flow - stages, actors, links, and port values.
@Graphit The JSON of the active Graphit file.
@ClaudeCode Content of workspace files; in long autonomous sessions also terminal output and test results.

Custom agents created by your team (see Creating Custom Agents) follow the same rules but may send different content depending on how they are configured.

Agents and Skills from the Studio AI Core Artifacts Extension

K2View publishes a Studio extension, the Studio AI Core Artifacts extension (available on K2Exchange), that supplies all of the built-in K2View-specific agents and skills described throughout this article set, including @k2-assistant, @k2-worker, @Interfaces, @Data-Product-Explorer, @KB, @Architect, and @Agent-Builder. See Getting Started with Studio AI. After installation, its artifacts are located under .agents/agents/ (agents) and .agents/skills/ (skills) in the project, with some reference content under .fabric-wiki/.

In addition to its agents, the extension imports a set of skills that any agent can call via slash command (see Skills and Slash Commands). At the time of writing, the installed skill catalog was: broadway-actor-builder, broadway-flow-builder, data-product-builder, data-product-cowork, debug-broadway-flow, fabric-commands, fabric-java-docs, fabric-overview, fabric-project-helper, fabric-troubleshooting, interface-builder, report-builder, and web-service-builder. Each skill is a SKILL.html file that the agent reads when activated; when the agent calls a skill, the skill's content is appended to the prompt and the agent then reads any further reference files the skill points to.

Two important properties of the imported plugin content for security review:

  • The bundled .fabric-wiki/ content is K2View Fabric reference material - actor schemas, Java API documentation, example flow patterns. It does not contain customer project content.
  • None of the skills or agents auto-inject customer data. They auto-inject only metadata about themselves (skill list, product info) and read reference or workspace files on demand through the same tool mechanism described in What Each Request Contains.

Audit and Visibility

Studio AI provides full visibility into every request and response. For any chat message, you can view the complete prompt that was sent to the LLM, including the system prompt, all auto-injected content, the conversation history, the user message, and tool-call results.

Open the AI Agent History panel via More Actions… ("…") in the AI Chat panel toolbar, then Open AI Agent History, and select the agent and request you want to inspect. The panel shows the full request body and the full response, with a unique request ID for support correlation. See Viewing Token Consumption and AI History.

This is the authoritative source of truth for what left your environment on any given request, and it is the recommended tool for security teams who want to audit Studio AI activity in a specific Fabric Dev environment.

Controls

Studio AI provides several layered controls. Use them in combination to match your organization's data-handling policy.

Enable or disable AI globally

AI features are off until an administrator explicitly enables them and provisions an LLM provider. With AI disabled, no data is sent to any provider. See Enabling Studio AI.

Choose where data goes

The LLM provider is configured per Fabric Dev environment. To keep all data on-premises, configure a local hosted LLM provider instead of a foundation cloud provider. To restrict to a specific cloud provider that has an enterprise data-handling agreement with your organization, configure only that provider.

Configuring Fabric as the provider centralizes this choice: the model and its credentials are set once on the AI LLM interface, developers cannot point Studio at a provider of their own, and use of the endpoint is restricted by role.

Disable individual agents

In the Agents tab of AI Configuration, you can disable any built-in agent. A disabled agent does not appear in the chat and cannot be invoked, so no data is ever sent through it. See AI Configuration: Managing Agents and Settings.

Customize agent prompts

Edit an agent's prompt template to remove or change any auto-injected content you do not want sent. For example, you can remove a ~{readFile(...)} reference from the template to stop a specific file from being included on every request. See Agents Prompt Customization.

Capabilities and MCP are opt-in

Agent Capabilities reset to off at the start of every session, and MCP Servers must be explicitly added by an administrator. Neither adds data sources silently.

Audit with AI Agent History

Use the AI Agent History panel (described above) to periodically review what is actually being sent - both during a rollout and as part of ongoing security monitoring.

At a Glance

  • Where requests go: outbound HTTPS from the Fabric Dev environment directly to the configured LLM provider. No K2View proxy.
  • Who holds the API key: the customer's Fabric Dev environment - in Studio settings, or in the project's AI LLM interface when Fabric is the provider.
  • What is sent by default: the agent's system prompt, the conversation history, and the user's current message. Some agents additionally auto-inject project structure or configuration metadata (see the per-agent table above).
  • What is sent on demand: files the user attaches, files an agent reads via tools, and outputs of any enabled capabilities or MCP servers.
  • What is not sent: API keys, credentials, server environment variables, or any data outside the workspace.
  • How to audit: every request is fully visible in the AI Agent History panel inside the Studio.
  • How to restrict: disable AI globally, choose a local LLM, disable specific agents, edit agent prompts to remove auto-injected content, or leave capabilities and MCP servers turned off.

© Copyright 2026 K2VIEW