In this article
When an agent answers questions, a company cares about correctness. When it moves files, calls internal services, or changes configuration, another question becomes equally important: what is it allowed to do?
Understanding an instruction must not imply permission to execute it. Organizational responsibilities need enforceable rules at the point of action.
Identity, resource, action
“Access project materials” is imprecise. Seeing a directory, reading a file, overwriting it, and deleting it are different capabilities.
brazosd enterprise permissions express access in terms of an identity, a resource, and an action. Rules can apply to a drive directory, a device, or another supported platform resource.
| Element | Question | Example |
|---|---|---|
| Identity | Who is requesting? | Member, session user, function service identity |
| Resource | What is affected? | Directory, device, platform resource |
| Action | What will happen? | List, read, write, delete, access |
| Groups and policies | How are rules reused? | Project access and sensitive-folder restrictions |
Swipe to see the whole table
Permissions follow resources rather than the visibility of buttons.
How organizational rules combine
Rules can be assigned directly to users or through groups and reusable policies. The enterprise permission mode defaults to denial and gives explicit denial precedence over allowance.
A project-wide grant therefore does not override a specific finance-folder restriction. These checks supplement ownership and organization boundaries. Ordinary organizations and organizations with enterprise permissions enabled have different behavior.
Directory operations also have consequences below the selected folder. Moving or deleting a tree must account for protected descendants, rather than checking only its outermost directory.
Agents can configure permissions, not invent them
brazosd provides an enterprise permission management skill and a platform control tool. A user with suitable administrative rights can ask an agent to inspect existing policies, propose a change, and apply it through APIs.
Those calls represent the current session user. Device access also follows that user's identity and permissions. An agent's name, prompt, or fluency does not grant additional authority.
Permission preflight checks relevant API authorization without executing the target operation. It helps identify missing access but does not guarantee all business validations will pass. Changes still need to be read back and checked against the intended scope and existing restrictions.
Applications need identities too
A cloud function may read files and call platform APIs. Using an administrator's personal credentials makes program activity harder to distinguish and access harder to revoke independently.
Functions have dedicated service identities. Enterprise groups and policies can grant the access they require; creating a function does not grant unrestricted organization access.
This is a foundation for brazosd on brazosd: applications implementing product features remain governed participants.
Enforcement belongs behind the interface
Hiding a button can prevent mistakes, but agents, custom frontends, and functions may call APIs directly. The actual execution path needs authorization.
brazosd enforces checks in APIs and relevant resource access paths, including resource-specific Cloud Drive checks. New internal calls and background tasks still need their own authorization design and verification; a UI rule cannot be assumed to cover them all.
This is also distinct from claiming a compliance certification or universal audit coverage. Auditing, monitoring, and compliance requirements need explicit work for the relevant setting.
Boundaries make wider capability usable
The more an agent coordinates across modules, the more valuable stable access rules become. An organization can permit work on one project while retaining restrictions on finance or personnel materials.
Permissions are infrastructure for bringing agents into organizations. They connect the convenience of Agent > UI with the real effects of device connectivity and cloud applications.