When AI agents query your database, a critical question emerges: What data does the AI actually see? Where does it go? Who controls it?

Traditional BI tools route queries through semantic layers that abstract away the raw schema. Agentic BI is different. AI agents need schema details, sample rows, and field metadata to select the right chart types and generate accurate queries. This creates new security risks that most platforms don’t address.

Knowi’s approach: Zero-trust architecture for agentic analytics. Authorization is enforced at the resource level. Sensitive data is never sent to the AI model. Row-level security filters apply automatically. Destructive operations require explicit confirmation. And you choose which AI provider processes your requests, or run everything on-premise.

Here’s how Knowi protects your data when AI agents are doing the work.

The Data Security Problem in Agentic BI

Agentic BI requires schema awareness. For an AI agent to pick the right chart type, it needs to know:

• What tables exist in your database
• What fields are in each table
• What data types those fields contain
• Sample values to understand what the data looks like

In a traditional BI tool, a data engineer pre-builds a semantic layer that abstracts this complexity. The AI never sees the raw schema. But in agentic BI, there is no pre-built semantic layer. The agent needs direct access to schema metadata to operate autonomously.

This creates a problem: What if sample rows contain PII? Customer emails? Payment information? PHI in healthcare?

Most agentic BI platforms send schema + sample rows directly to their AI model (usually OpenAI or Claude). For highly regulated industries, healthcare, finance, government, this is a non-starter. Sensitive data can’t leave your environment.

Knowi solves this at the architectural level.

Authorization Enforcement: Resource-Level Access Control

Before any agent operation executes, Knowi verifies the user’s access to the specific resource:

• Dataset access: Does the user have permission to query this dataset?
• Dashboard access: Can the user edit this dashboard or only view it?
• Feature access: Is the user’s role permitted to create reports? Schedule alerts? Export data?

If access is denied, the agent never receives a schema or sample data. The operation is rejected immediately.

Example: A finance analyst asks an AI agent to “create a dashboard of Q2 revenue.” The agent checks: Does this user have access to the Q2 revenue dataset? If the dataset is restricted to managers, the agent denies the request. The analyst sees: “You don’t have access to that dataset.”

This prevents privilege escalation. An agent can’t be tricked into accessing resources the user isn’t authorized for, no matter how the natural language request is phrased.

Customer Isolation: No Cross-Organization Data Access

In multi-tenant Agentic BI deployments, customer isolation is non-negotiable. A customer’s agent should never access another customer’s data.

Knowi enforces tenant isolation at every step:

• Each agent request is tagged with a customer ID
• The orchestrator filters all data and schema lookups to that customer’s resources only
• The AI model never knows about other customers’ data
• All audit logs record which customer executed which operations

This matters for embedded deployments. If you embed Knowi’s agentic widget in your product for your customers, each customer’s agent operates in a fully isolated sandbox.

Selective Data Exposure: Schema vs Sample Rows vs Full Datasets

Not all AI requests need the same level of data exposure. Knowi follows a principle: send only what the agent needs to decide.

For schema-aware operations (query generation, chart type selection):

• Schema metadata is sent (table names, field names, data types)
• Sample rows are sent (a few rows to understand data format)
• Full datasets are never sent

For deterministic tools (data export, asset deletion, URL generation):

• The AI model is not involved at all
• Knowi’s backend executes the operation directly
• Zero hallucination risk. Zero data exposure.

This distinction is crucial. If a user says “delete this widget,” the system doesn’t send the widget to the AI and ask it to reason about deletion. The AI never sees it. The operation happens directly, and the user is asked to confirm first.

Row-Level Security: Automatic Filtering Based on User Role

When an agent queries a dataset, row-level security (RLS) filters are applied automatically.

Example: A sales rep uses an agent to ask “show me revenue by region.” If RLS rules restrict the rep to seeing only their own territory, the agent’s query is automatically filtered to show only that region’s data, even though the underlying dataset contains all regions.

The agent doesn’t know it’s operating on filtered data. It generates the correct query. The RLS filter applies at execution time. The result is correct and secure.

This is especially important in healthcare, pharma, and government where data compartmentalization is required by law.

Data Residency: Choose Where Your Data Is Processed

Knowi’s most powerful security feature: you choose which AI provider processes your requests.

Option 1: Knowi Internal (Private AI)

All AI processing runs on Knowi’s infrastructure. Your data schema and sample rows never leave Knowi’s environment. No third-party LLM involvement.

Option 2: OpenAI (via your API key)

Requests are routed to OpenAI’s API using your account. You retain control of billing and API rate limits. OpenAI’s standard data retention policies apply.

Option 3: Anthropic (via your API key)

Requests go to Claude via Anthropic’s API. Same control, same data handling as OpenAI.

Option 4: On-Premise Deployment

The entire Knowi system (agents, MCP server, AI inference) runs inside your infrastructure. Zero data leaves your network.

This granular control is why Knowi is deployed in regulated industries: healthcare (HIPAA), financial services (SOC 2), government (NIST). You choose the risk profile. You enforce the compliance requirement.

MCP-Specific Protections: Prompt Injection Detection & Confirmation Gates

When agents are exposed through the MCP protocol (connecting Claude Desktop directly to your Knowi instance), additional attack vectors emerge: prompt injection and accidental destructive operations.

Knowi defends against both:

Prompt Injection Detection

• All user inputs are scanned for injection patterns
• Suspicious requests are flagged and rejected before reaching the agent
• Character limits prevent encoding attacks
• Whitelist-only tool access: only approved operations are exposed

Confirmation Gates on Destructive Operations

• Delete dashboard? Requires confirmation
• Drop a dataset? Confirmation required
• Export sensitive data? Confirmation required

This prevents accidental deletions caused by ambiguous natural language requests.

Audit Logging: Complete Traceability

Every agent operation is logged:

• Who initiated the request (user ID, role, organization)
• What operation was requested (query, dashboard creation, export, etc.)
• What data was accessed or modified
• When it happened (timestamp)
• What the result was (success, denied, error)
• Whether an AI model was involved (or if it was a deterministic tool)

This is critical for compliance. Auditors can trace every AI-driven change to your analytics environment. Healthcare organizations need this for HIPAA. Financial firms need it for SOX. Government agencies need it for NIST.

Putting It Together: A Real-World Example

Scenario: A healthcare provider deploying Knowi’s agentic widget in their patient portal. Patients should be able to ask “show me my test results,” and an AI agent builds a dashboard, but only for that patient’s data.

Security flow:

• Patient authenticates to the portal (identity verified)
• Patient asks: “show me my lab results from the last 90 days”
• Agent receives request with patient ID in the session context
• Authorization check: Does this patient have access to lab result datasets? (Yes, via SSO rules)
• RLS filter applied: Query is constrained to this patient’s records only
• Schema metadata sent to Knowi’s Private AI (no third-party LLM)
• Private AI generates SQL query: “SELECT * FROM labs WHERE patient_id = [this patient] AND date > [90 days ago]”
• Query executes against the database with RLS filter in place
• Dashboard is generated and displayed to the patient
• Audit log records: Patient X requested and received their own lab result dashboard at [timestamp]

The agent never sees other patients’ data. The AI never touches PII. The entire operation is logged. HIPAA compliance is maintained.

Comparison: Agentic BI Security Approaches

Frequently Asked Questions

Security in agentic BI isn’t an afterthought. It’s architecture. Knowi enforces authorization, isolation, and data protection at every layer, because analytics agents need to be as secure as they are intelligent.Request a Security-Focused DemoView Security Documentation