# Cerbos MCP for AI Agents MCP > Cerbos provides an open standard connection for managing access control policies and checking permissions using your AI agent. It lets developers verify exactly if a user can perform a specific action on a resource, keeping authorization logic outside of application code. You'll audit complex security rules, manage policies (RBAC/ABAC), and generate query plans directly through natural language prompts. ## Overview - **Category:** developer-tools - **Price:** Free - **Tags:** authorization, rbac, abac, policy-as-code, access-control ## Description Managing permissions used to mean writing messy, complex logic into your main codebase—logic that breaks when requirements change or needs auditing. This MCP changes that process entirely. It lets you connect your AI agent to a dedicated policy engine, treating authorization rules like data instead of code. You can now ask questions like, 'Can this user delete this report?' and get an immediate, definitive answer based on your current security policies. Furthermore, if you need to check the health of the entire system or audit past access attempts, your agent handles it without needing manual API calls. By using Vinkius as your central catalog, you connect once from any compatible client and gain control over all these policy functions through conversation. ## Tools ### add_policy Creates a completely new access control rule for the system. ### add_schema Adds or updates the structural definition (schema) of a resource type. ### authzen_evaluation Performs a single, immediate test to determine if access is allowed using AuthZEN rules. ### authzen_evaluations Runs multiple, batch checks to evaluate permissions across several scenarios at once. ### check_resources Checks if a set of users have the required rights for specific resources. ### delete_policy Removes an existing policy entirely using its unique identifier. ### disable_policy Temporarily turns off a policy without deleting it, useful for testing or maintenance. ### enable_policy Restores a previously disabled access control policy to active status. ### get_authzen_config Retrieves metadata about the AuthZEN configuration setup. ### get_health Returns the current operational status of the Cerbos policy engine. ### get_metrics Pulls performance metrics data, useful for monitoring system load and usage patterns. ### get_policy Retrieves the full text of a specific policy by its ID. ### get_schema Fetches the detailed structure definition for a schema type. ### get_server_info Gets version and build information about the Cerbos server instance. ### list_audit_logs Generates a list of all recorded access control audit logs for review. ### list_policies Displays every single policy currently active in the system. ### list_schemas Lists all defined resource schemas available to the application. ### plan_resources Creates a database query plan (AST) that filters resources according to complex authorization logic. ### update_policy Modifies the rules and parameters of an existing policy. ## Prompt Examples **Prompt:** ``` I need to confirm if a user in the 'read-only' group can access financial records for Q3. ``` **Response:** ``` **Policy Check Results** * **Principal:** `user:jdoe` (Group: read-only) * **Action:** Read * **Resource:** Financial Record (Q3) * **Result:** ✅ **ALLOWED.** The policy 'finance.read.q3' grants read access to all users tagged with the 'read-only' group. No further actions needed; the system is compliant. ``` **Prompt:** ``` List all policies that affect resource types related to employee payroll. ``` **Response:** ``` **Payroll Policy Audit** I found 5 policies affecting payroll records: * `resource.payroll.view`: Allows read access for HR staff. * `resource.payroll.update`: Restricted to Payroll Managers only. * `resource.salary.delete`: Only permitted if the user is a system admin. * `resource.tax.read`: Available globally. * `resource.bonus.create`: Requires multi-factor approval. ``` **Prompt:** ``` What are the necessary database filters to ensure I only see records owned by my department? ``` **Response:** ``` **Query Plan Generated** The following Abstract Syntax Tree (AST) plan will filter your results correctly: ```json { "field": "department_id", "operator": "equals", "value": "{{current_user.dept_id}}", "join_condition": "is_active" } ``` This plan ensures that only records matching your department ID are returned. ``` ## Capabilities ### Check resource permissions Verify if a specific user or group is authorized to perform an action on a given data object. ## Use Cases ### Verifying a new feature rollout A backend developer needs to ensure that only managers can approve expenses. They prompt their agent: 'Check if the manager role can execute the approval action on expense reports.' The agent uses `check_resources` and confirms the exact required permissions before the code is merged. ### Investigating a data breach A security engineer discovers unusual access patterns. They prompt their agent to 'List all audit logs for resource type X in the last week.' The agent uses `list_audit_logs` and provides a chronological list, immediately narrowing down the scope of the investigation. ### Refactoring authorization logic A developer needs to change how department ownership works. They ask their agent to 'Update policy resource.dept.v1 to include owner attribute.' The agent uses `update_policy` and confirms the successful modification. ### Optimizing reporting queries The team needs a report that only shows records owned by the current user's department. Instead of writing complex SQL, they prompt their agent to 'Generate an AST query plan for filtering resources based on department ownership.' The agent uses `plan_resources`. ## Benefits - You stop manually running API calls. Your agent handles policy definitions, allowing you to quickly use `list_policies` or `update_policy` by simply asking a natural language question. - Audit risk instantly. Need to know if an action was allowed? Running the `check_resources` tool lets you test permissions for any user against any resource without touching your code base. - Improve developer speed. Instead of guessing how database filters work, use `plan_resources` to generate and test optimized query plans based on policy rules directly within your agent chat. - Ensure compliance easily. By using the audit logging tools like `list_audit_logs`, you can retrieve comprehensive records proving that security standards were followed. - Gain visibility into system health. You'll get immediate answers about performance or status by running `get_health` or pulling operational metrics with `get_metrics`. ## How It Works The bottom line is that you get an immediate, conversation-based interface for managing and testing core security rules without writing any code. 1. Subscribe to this MCP on Vinkius. 2. Provide your Cerbos Policy Decision Point URL and necessary administrative credentials to your AI client. 3. Ask your agent a natural language question—like, 'Show me all policies related to the expense report resource.'—and it handles the rest. ## Frequently Asked Questions **How does the Cerbos MCP help manage my company's access control policies?** You can use this MCP to centralize policy management. Instead of coding rules into your application, you define them using tools like `list_policies` and `add_policy`. Your agent then handles all checking and enforcement logic for you. **Can I audit past security events with the Cerbos MCP?** Yes. You can use this MCP to retrieve comprehensive records of every access decision using tools like `list_audit_logs`. This lets compliance teams prove exactly who accessed what and when. **Does this MCP help developers write more secure code?** Absolutely. You can use it during development to test authorization scenarios by generating query plans with `plan_resources`, ensuring your database queries are always correctly scoped based on security rules before they ever reach production. **What if I need to update a policy, but I'm not sure which one is correct?** You can list all available policies using `list_policies` and then use the agent to retrieve specific details about any rule with `get_policy`. This gives you the full context needed for safe updates. **How do I check if a user has permission without writing boilerplate code?** You simply ask your AI agent to check permissions using tools like `check_resources`. The MCP handles all the complex policy evaluation, returning a simple ALLOWED or DENIED status for you.