标签：#permission

AI agents don’t use web browsers. They don’t click buttons, submit forms, or trigger standard HTTP requests that pass through your middleware stack. They execute logic via API calls, background queues, or CLI commands using tool definitions. When an LLM decides to "fetch the latest invoices," it usually calls a tool function. If that tool function just runs Invoice::all() , your AI agent just became a god-mode data leak. The fundamental problem with integrating LLMs into existing applications is that agents operate in a detached, stateless execution context . They don't have a session cookie. They don't inherently know who invoked them. If you rely on the system prompt to tell the LLM, "Only show John his own data," you are trusting a probabilistic text generator to enforce your security boundary. That is a production incident waiting to happen. To build a secure AI agent in Laravel, you must treat the LLM not as a user, but as a proxy for the user. The agent must inherit the exact Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) constraints of the human sitting behind the keyboard, and it must enforce those constraints at the database query level, not the prompt level. TL;DR AI agents bypass traditional web middleware because they execute logic through background tools and function calling. Never trust the LLM to filter its own results. Force filtering through Eloquent scopes and authorization gates. Pass the acting user's identity explicitly into the agent's execution context using Laravel's auth guards or custom context DTOs. For complex rules (hierarchies, multi-tenancy, ABAC), standard role packages fall short. Tools like hosseinhezami/laravel-permission-manager are required to evaluate deep permission trees inside agent tools. Audit every tool execution with the acting user's ID, not the system service account. 📋 Table of Contents 1. The "God-Mode Tool" Problem 2. Passing Identity Down the Execution Chain 3. Enforcing RBAC Inside LLM

This is part three of our Directus Basics series. In part one we set up our instance, and in part two we covered relationships between collections. Today we're covering access control — what determines who can see and touch your data. The Core Concepts Access control in Directus comes down to three terms: Permission — applies to one collection and one action (create, read, update, delete, or share). Can be full access, no access, or custom rules. Policy — a group of permissions bundled together, applied to users or roles. Role — defines a user's position within a project. A role can hold any number of policies, apply to any number of users, and have child roles of its own. What Happens Without a Role? If an administrator creates a user but doesn't assign a role, that user has valid login credentials but still can't access the Data Studio. Creating a role and assigning the user to it isn't enough either — logging in at that point returns a "No App Access" error. The missing piece is that the role has no access policy attached. The policy is what actually tells the role what its users can and can't do. The Access Order Access in Directus flows in a specific direction: Access Policy → Role → User In practice: define what level of access a user needs, build an access policy to match, create a role and attach that policy to it, then register the user and assign them to the role. Default Policies Every fresh Directus instance ships with two default policies: Administrator — the role you're signed in as by default, with unrestricted access to everything. Public — for data that should be visible without logging in. Think of a product catalog on an e-commerce site — forcing a login just to browse products is a poor experience. Rule of thumb: give the Public policy Read access only. Never Create, Update, or Delete. The public should be able to view data, never manipulate it. Giving a Collection Public Access Go to Settings → Access Policies → Public Under Permissions, click A