When building an AI Agent in Zenphi AI Studio, connecting it to your company Tables is only half the process. The most critical step before deployment is applying strict access controls to ensure every user gets a personalized, highly secure experience.

In Zenphi, we practice the principle of Least Privilege—meaning you grant the agent and the user exactly the data access and execution permissions they need to function, and absolutely nothing more.

To achieve this, Zenphi provides four layers of permission trimming:

• Agent Visibility: Controlling who is allowed to see and interact with the agent in their Zenphi Assistant menu.
• Agent Description & Guidelines (The Conversational Rules): Defining the AI’s operational boundaries through text prompts. This helps guide the AI’s behavior, scope, and responses.
• Row-Level Filtering (The Records): Applying conditions to restrict which specific data rows the AI is allowed to read based on who is asking.
• Column Exposure (The Fields): Controlling which specific data fields the AI is allowed to display within the chat window.

A Quick Example: Rules, Rows, and Columns

To understand how these layers work together, imagine you connect an “Employee HR & Payroll” table to an agent designed to help with time off.

• Agent Description & Guidelines: You instruct the agent: “You are an HR Leave Assistant. You only answer questions about time off. If a user asks about salaries, promotions, or IT support, strictly refuse to answer.” The AI now understands its conversational boundaries.
• Row-Level Filtering: You apply a condition so the AI only reads records where the Employee Email matches the User Email. When John asks about his remaining PTO, the AI only looks at John’s specific row. He cannot query Sarah’s or Mike’s records.
• Column Exposure: In the table settings, you hide the Bank Account Number and Internal Salary Band columns. Even when John queries his own approved record, the AI will never output his bank details or backend salary band into the chat interface.

Powered by User Attributes

All of these dynamic security rules—from who can see the agent to what data they can access—are driven by User Attributes.

User Attributes act like dynamic tags or variables attached to specific profiles in your Zenphi Workspace. Instead of creating separate agents for every department, you can often build a single intelligent agent and personalize access dynamically using attributes. Zenphi automatically identifies the current user, references their attributes, and trims the agent’s visibility and data access on the fly.

Recommended Attributes to Create

To maximize the utility of Row-Level Security (RLS) and visibility filtering, consider setting up these standard attributes for your workspace:

• Department (String): Useful for siloing data (e.g., table column Department Equals user attribute Department so the agent only queries data matching the user’s division).
• Region (String): Perfect for localized agents (e.g., US employees only see US-based policies and data sources).
• IsManager (Boolean): Excellent for Agent Visibility controls. Set this to True/False to display specific “Approval” or “Budget” agents exclusively to leadership.
• ClearanceLevel (String): Designed for restricting sensitive data rows to specific tiers of employees.

Additional Attributes For Customization:

• Operational: CostCenter, OfficeLocation, ShiftType, LanguagePreference
• Hierarchical: ManagerEmail, isSuperAdmin, Role, AccessLevel, level
• Identification: EmployeeNumber, SystemID

Note: User Attributes can be assigned globally across your Workspace or overridden for specific Spaces (e.g., a user might hold a “Manager” role globally, but be designated a “Volunteer” inside a specific project space). For a deep dive into creating, assigning, and managing the inheritance logic of these tags, see our full guide: Understanding User Attributes & Personalization.

Before You Build: The Stakes of AI Agent Governance

Before configuring your Zenphi AI Agents, it is crucial to understand the governance stakes. When you build an AI agent, you are establishing an autonomous bridge between your users and your enterprise database. How you architect its rules, visibility, and data access determines whether it operates securely or introduces compliance risks.

Failing to implement these configurations correctly carries significant structural liabilities:

• Data Leakage Risks: If you do not configure Row-Level Filters and Column Exposure, you risk exposing sensitive data—such as payroll details, HR records, or confidential strategic documents—to unauthorized employees. A standard user should never be able to request and receive another employee’s salary information via a natural language query.
• The Illusion of Prompt Security: A common mistake is assuming that writing “Do not share XYZ” in an agent’s Behavioral Guidelines is sufficient to protect data. It is not. Large Language Models can be manipulated by users via prompt injection or provide unsupported answers. Text prompts influence behavior; hard configuration rules secure data.
• Broken Access Hierarchies: Without leveraging dynamic user attributes (like checking if a user isSuperAdmin or evaluating their ClearanceLevel), organizational permissions can become flattened. An agent must dynamically adapt to the specific permissions of the person interacting with it.
• Interface Clutter: From a usability standpoint, failing to restrict Agent Visibility means users will be overwhelmed with tools they are not authorized or intended to use, leading to poor adoption and confusion.

The tools provided in Zenphi AI Studio give you granular control over who sees an agent, what data that agent can access, and how it behaves. The following configurations form the necessary foundation of enterprise AI security.

1. Agent Visibility: Controlling Menu Access

By default, a newly created AI Agent is visible to everyone in your workspace. However, you rarely want every employee to see every single agent you build. Configuring visibility allows you to apply conditional rules so the agent only appears in the Zenphi Assistant menu for authorized groups.

Configuring visibility serves as your primary line of defense. For admin-level or highly sensitive tools, restricting visibility acts as a strict security perimeter—if a user is not authorized to use the tool, it remains entirely hidden from them. As a secondary benefit, visibility filtering keeps the Zenphi Assistant interface clean, ensuring general employees only see tools relevant to their daily workflows.

You can restrict access by building rules based on specific User Emails or dynamic User Attributes, stringing them together with standard AND/OR logic.

Configuration Examples

• Targeting a Specific Individual: If you build a highly specialized tool meant only for a single stakeholder, you can isolate them directly.
  • Rule: User Email Equals [email protected]
  • Result: Only the CFO sees this agent in their menu. To everyone else, it is completely hidden.
• The Super Admin Tool (OR logic): Imagine a master system-monitoring agent. You want it visible to your workspace Super Admins, but also accessible to a specific external IT Auditor.
  • Rule: isSuperAdmin Equals True OR User Email Equals [email protected]
  • Result: Meeting either condition grants access, ensuring the tool is available to the right operational staff while remaining invisible to the rest of the company.
• Deep Tiered Targeting (AND logic): You are launching a sensitive “Level 3 Financial Approval” agent. It should not be visible to just any director—only those with the proper clearance level.
  • Rule: Role Equals Director AND AccessLevel Equals 3
  • Result: An employee must meet both criteria to see the agent. A Director with an Access Level of 2 will not see it, ensuring strict governance over sensitive actions.

Common Use Cases for Visibility Filtering

• Executive & Leadership Hubs: Restrict strategic planning or budget-tracking agents exclusively to leadership profiles (Role Equals Executive).
• Location-Specific Support: Ensure a “UK Health Insurance Benefits” agent is only visible to employees residing in that region, preventing confusion for global teams.
• Phased Rollouts / Beta Testing: When launching a major new internal agent, restrict visibility to a small pilot group first (User Email In List beta_testers) before opening it up to the wider company.
• Clean Menus for Deskless Workers: Keep the Assistant strictly operational for field or shift workers by only showing them daily task tools, hiding corporate or desk-centric AI agents.

2. Data Access: Row-Level Filtering (Filters)

While Visibility controls whether a user can interact with an agent at all, Row-Level Filtering (found under the Filters tab when configuring an agent’s Table access) controls exactly which pieces of data that agent is allowed to read on behalf of the user.

Think of it as looking through a targeted viewpoint rather than an open door. Two different employees can use the exact same agent, ask the exact same question (“What is the status of my current projects?”), and get two completely different answers—because the agent dynamically filters the underlying table based on who is asking.

By mapping User Attributes to specific Table Columns, you ensure the AI only retrieves rows that the current user is authorized to see. This guards against data leakage while allowing you to deploy a single, scalable agent for the entire company.

How to Configure Filters

To set up a filter, you define a rule that must evaluate to true for a row to be included in the AI’s search context. You can use operators (like Equals, Not Equal, or Contains) linked to dynamic variables, and stack rules using AND/OR logic to match a column in your table to an attribute of the user interacting with the agent.

• The “Own Data” Rule: The most common filter ensures users only see records assigned to them.
  • Configuration: Table Column Owner_Email Equals User Attribute User Email
  • Result: When an employee asks the agent about “recent tickets,” the agent only scans rows where the Owner_Email matches the email of the person typing the prompt.
• The Departmental Filter: Restricting data to a user’s specific business unit.
  • Configuration: Table Column Department Equals User Attribute Department
  • Result: If an HR rep and an IT rep both ask the agent “Show me the new hire list,” the HR rep only sees HR new hires, and the IT rep only sees IT new hires.

Practical Use Cases for Row-Level Filters

• Employee Self-Service (HR): You connect a master “Employee Records” table to an HR agent. By filtering Employee_Email to equal User Email, employees can ask “How much PTO do I have left?” or “What is my current benefits package?” without any risk of the AI accessing or revealing another coworker’s data.
• Territory-Based Sales Insights: You have a global sales database. You can filter the Region column to match the user’s Region attribute. A manager asking “What are the top closed deals this quarter?” will only receive a summary of deals within their specific territory, protecting data belonging to other regional managers.
• Support Ticket Management: You connect an IT Helpdesk table. By filtering the Requester_Email to the user, an employee can ask “Has there been an update on my laptop replacement request?” The agent will only parse their specific tickets, providing a highly relevant and secure status update.
• Project Management: Filter a “Task Tracker” table so the Team column matches the user’s Team attribute. When a user asks “What deadlines are approaching this week?”, the agent filters out the noise of the entire company’s operations and only summarizes tasks relevant to their immediate working group.

3. Data Exposure: Column-Level Control (Columns to display)

If Row-Level Filtering controls which records the AI can access, Column-Level Control dictates which specific details within those records the AI is allowed to read and share with the user.

Found under the Columns to display section when configuring a table, this setting lets you explicitly check or uncheck specific fields. If a column is unchecked, it is excluded from the agent’s available table context and cannot be displayed to users.

Configuration Examples

• Hiding Sensitive Fields: You connect an “Employee Database” table. You check Name, Role, and Manager, but uncheck Salary and Home Address. The AI can tell a user who the Marketing Director is, but cannot access or output their compensation data.
• Hiding System Clutter: You uncheck technical backend fields like Record_ID, System_Sync_Status, or Last_Modified_Date to keep the context clean.

Practical Use Cases

• Secure Employee Directories: Build a company-wide directory agent that safely exposes public info (Name, Job Title, Work Email) while protecting Personally Identifiable Information (PII) like dates of birth, social security numbers, or emergency contacts.
• External or Vendor-Facing Bots: If building an agent for contractors to check project statuses, expose fields like Task Name and Due Date, but hide sensitive internal columns like Profit Margin, Budget, or Internal Manager Notes.
• Improving AI Response Quality (Cleanliness): Databases often contain system-generated technical fields (like UUIDs or complex JSON logs). By hiding these irrelevant columns, you prevent the AI from becoming confused or including technical jargon in its conversational responses to the user.

4. Prompt Configuration & Behavioral Governance

Once you have locked down what data your agent can access using Row Filters and Column Exposure, the final step is to configure how the agent interacts with that data and the user.

In Zenphi AI Studio, this is managed through two natural-language configuration fields: the Agent Description and the Behavioral Guidelines. Together, these act as the agent’s operational rulebook.

Defining the Mission: The Agent Description

This field establishes the agent’s core identity. It tells the broader AI system exactly what this specific micro-agent helps users achieve and the specific scenarios where it should be triggered.

• The Goal: Clearly define the agent’s job so the system knows when to route a user’s request to it.
• Example: “This agent helps employees submit and manage time-off requests, check leave balances, and track request status. Use it when you need to request leave or ask questions about your HR records.”
• ZAIA Prompt Builder: You do not need to write a description from scratch. You can type a few rough keywords, click the ZAIA button (the spark icon), and let Zenphi’s built-in AI generate an optimized description for you. You can iterate with this tool until it captures the agent’s purpose.

Establishing Rules of Engagement: Behavioral Guidelines

While the Description dictates what the agent does, the Behavioral Guidelines dictate how it acts. This is where you configure the agent’s tone, operational boundaries, and decision-making logic.

• The Goal: Provide explicit instructions on how to handle user interactions, missing information, and edge cases.

• Examples of Solid Guidelines:

  • “Understand user requests and map them to available actions or data.”
  • “Ask for missing information before taking action.”
  • “Confirm with the user before submitting or updating any request.”
  • “When answering questions, only use the data available to you. If you are unsure, ask a follow-up question instead of making assumptions.”
• ZAIA Prompt Builder: Just like with the description, clicking the ZAIA button here will automatically generate behavioral rules tailored to the tables, flows, and actions you have connected to the agent.

Crucial Security Principle: Soft vs. Hard Restrictions

When configuring these text prompts, it is vital to understand the difference between guiding an AI’s conversation and securing your database. Because Large Language Models (LLMs) are conversational, users can sometimes bypass text-based rules using creative phrasing (known as prompt injection).

Therefore, apply the following standard when building in Zenphi:

• Soft Restrictions (Behavioral Guidelines): Use these to keep the agent polite, professional, and on-topic. You can instruct the agent, “Do not answer questions about marketing campaigns,” or “Politely redirect IT requests to the Helpdesk.” This is ideal for conversational governance.
• Hard Restrictions (Data Governance): Never rely on Behavioral Guidelines to protect highly sensitive information. You should not give an agent full access to a payroll table and simply write, “Do not share employee salaries” in the Behavioral Guidelines field.
• The Solution: To truly secure data, apply Hard Restrictions using row and column filters. If an agent should not access or discuss salaries, use Column Exposure to uncheck the salary column so the data is completely omitted from the AI’s data footprint.

By combining Zenphi’s absolute Data Permissions (Hard Restrictions) with well-crafted Prompt Configurations (Soft Restrictions), you create an agent that is both highly secure and operationally helpful.

5. Best Practices for Zenphi AI Agents

To ensure your AI agents remain secure, efficient, and easy to manage, follow these architectural guidelines:

• Embrace the “Micro-Agent” Architecture: Avoid building a single global agent that handles HR, Sales, IT, and Finance all at once. Instead, build specific, single-purpose agents (e.g., a “Time-Off Agent,” an “IT Ticket Agent,” or a “Quarterly Sales Agent”). This keeps focus narrow, reduces the risk of data leakage, and ensures a cleaner user experience.
• Enforce the Principle of Least Privilege: When configuring an agent, default to zero access. Only expose the exact tables, specific columns, and exact rows necessary for the agent to complete its specific mission. If the agent does not explicitly need a data point to do its job, hide it.
• Never Rely on Prompts for Security: Behavioral Guidelines are “soft” rules meant to dictate conversational flow, tone, and validation logic. They are not security firewalls. If you need to keep sensitive data away from unauthorized eyes, apply “hard” rules by removing the data via Column Exposure or Row-Level Filters.
• Leverage Dynamic User Attributes: Make your agents context-aware by utilizing User Attributes (like User_Email, Department, Role, or IsManager). Apply these attributes within your Row-Level Filters to ensure that the same agent dynamically serves tailored, secure data depending on exactly who is logged in.
• Use the ZAIA Builder to Establish Baselines: Avoid starting with a blank text box. Provide the Agent Description and Behavioral Guidelines fields with a few simple keywords and click the ZAIA (spark) button. Let the built-in AI analyze your connected tables and generate a robust baseline prompt, which you can then manually refine.
• Prompt for “Fail-Safes” in Guidelines: Always include rules in your Behavioral Guidelines instructing the agent on how to behave when it does not know the answer or when a user request falls outside its scope. Instructions like, “If a user asks an out-of-scope question, politely refuse and redirect them to the IT Helpdesk,” keep the agent operating within safe boundaries.

The End-User Experience in Action

To visualize how these permission layers execute in real-world scenarios, consider an environment where an administrator has configured a single “HR & Operations Hub” agent. The system dynamically processes the experience for two users with entirely different organizational profiles: John (a standard Account Executive in Sales) and Sarah (an HR Director).

• User Connection: Both employees independently access Zenphi Assistant and establish a session.

• John’s Execution Path (Sales Executive):

• Visibility Filter Check: The system evaluates John’s metadata attributes against the agent’s deployment settings. Because the administrator explicitly authorized access for the ‘Sales’ user group, the security layer validates the request, and the “HR & Operations Hub” agent populates inside John’s available agent menu.

• Sarah’s Execution Path (HR Director):

• Visibility Filter Check: The system evaluates Sarah’s organizational role against the security configuration. Since the agent is explicitly authorized for the ‘HR’ department, the validation checks pass, and the agent is rendered visible within her selection menu.

When both users type a natural language prompt, the hard boundaries and soft restrictions apply in real-time behind the scenes:

Scenario A: John (Sales Executive) asks: “Show me my performance reviews and what Sarah in HR makes.”

1. Agent receives the request: John submits the conversational query to the agent.
2. Behavioral Guidelines determine how to respond: The AI evaluates the instruction parameters set in its Guidelines (e.g., to remain professional, maintain an operational focus, and avoid out-of-scope conversational topics).
3. Data permissions determine what information is available: The database layer enforces hard controls before context generation. Row-Level Filtering actively uses the statement Employee_Email Equals User Email, anchoring the pull strictly to rows where the field matches [email protected]. Sarah’s records are completely excluded from the query payload. Concurrently, Column-Level Control has the Salary field unchecked, omitting compensation values entirely from the agent’s available context.
4. The AI generates a response only from permitted context: Because Sarah’s row data and the salary column fields do not exist within the compiled context, the AI cannot read or expose them. It builds a secure response from the remaining records: “Here is a summary of your recent sales performance reviews, John. However, I do not have access to salary data or records for other employees.”

Scenario B: Sarah (HR Director) asks: “Show me my performance reviews.”

1. Agent receives the request: Sarah submits her text inquiry through her current conversation.
2. Behavioral Guidelines determine how to respond: The AI reads the request scope against its foundational rules of engagement.
3. Data permissions determine what information is available: The database filter evaluates her query. The rule Employee_Email Equals User Email forces the query scope to target rows matching [email protected]. Because the Salary column is unchecked globally for this specific agent profile, the data processing layer completely excludes salary values from the payload—even though her user profile is an HR Director.
4. The AI generates a response only from permitted context: The AI pulls only her authorized row data and returns a conversational summary of her performance evaluations while maintaining complete technical compliance with the data configuration rules. If Sarah needs to perform structural payroll tasks, she must switch to a separate, purpose-built agent configured with explicit column exposure and restricted to her visibility profile.

Conclusion & Next Steps

Configuring security perimeters and permission trimming transforms standard automation into a secure enterprise AI ecosystem. By combining Agent Visibility, Row-Level Filtering, and Column Exposure, you ensure that organizational data assets remain protected while delivering a highly customized experience to your users.

To complete your understanding of deployment and operations within Zenphi AI Studio, consider exploring these complementary guides:

• Building and Initial Setup: Review the fundamental components of agent creation, platform channel mapping, and workflow routing in How to Create and Configure an AI Agent.
• The End-User Environment: Discover how authorized employees interact with these secured agents across daily platforms by visiting What is Zenphi Assistant?.