Brezel / Governance & permissions

Who may do what?
And on whose behalf?

Governance defines how people and AI work together. It connects visibility, action permissions, authority and human responsibility. A good chat interface alone does not answer those questions.

01 /

Four questions before an action.

What may a role see? Which tools and records may it change? On whose behalf is it acting? Does the specific step need additional approval? These questions must be answered together.

Read access is not write access. Access to a document does not automatically permit sending it. An assignment does not itself expand the agent’s authority. Governance brings these layers together in the same work context.

Conceptual diagram
  1. 01Identity
  2. 02Access
  3. 03Assignment
  4. 04Approval

This diagram explains the relationship. It is not a live view or a commitment to future features.

02 /

One approach to permissions for people and AI.

Brezel places people and agents within roles and responsibilities. Employees and their personal assistants share the permitted access context. Independent agents receive a defined scope. Company and tenant boundaries also matter.

Management sets policy and business owners define suitable processes and approvals. Configuration must reflect that guidance. A prompt instruction alone is not a substitute for effective permission settings.

03 /

Distinguish personal and independent agents.

A personal assistant works for its associated person. It does not gain additional authority over colleagues. People communicate with people, rather than treating colleagues’ assistants as substitutes for their consent.

An independent agent can be assigned defined tasks by management or authorised employees. Its requester, necessary information and review owner must remain clear.

Four illustrative policy examples

The same AI.
Different permissions.

Personal sales assistant

Use an approved product sheet to draft a reply.

Within permitted read access

The assistant may use the document approved for its employee. This grants no additional access to other data or authority to send a message.

Examples of configured rules, not a live permission check. The actual scope is configured for the organisation.

04 /

Hierarchy means more than an organisation chart.

The governance concept accounts for lines of authority. Involving agents outside one’s responsibility or across departments needs an authorised assignment and, where required, approval by a responsible person with the appropriate authority. Exceptions should be scoped to the specific case.

Permission for one case is not permanent unrestricted access. Company policies can allow full, limited or no access. This does not create a blanket ban on ordinary collaboration between people.

05 /

Knowledge inheritance is not access to everything.

Management can set shared guidance, with departments and roles adding their professional ways of working. This does not automatically expose personal memories or confidential case content to the entire company or every management level.

A reviewed general lesson may be suitable for other roles. Raw HR conversations or sensitive case information are not automatically suitable. Sharing requires review and approval. The full learning loop with automatic role inheritance is a development topic.

06 /

Approvals must support a real decision.

A useful proposal explains the trigger, intended action, relevant evidence and open questions. Responsible people need to be able to edit or reject it. Approval should clearly identify the permitted step and scope.

Proposal, approval and execution are different states. One approval is not authority for unrelated follow-up actions. Automatic approvals for trusted cases and an expanded decision dashboard are separate development goals.

07 /

Tools, credentials and execution environments.

Integrated password management supports controlled access. Credentials are intended for authorised runtime use, rather than being included as plaintext in model requests. This requires suitable integrations and correct configuration.

Code and tools run in separated environments. A sandbox does not replace permission checks, network rules or secure operations. Delegated subtasks remain bounded by the original authority.

08 /

Trace, review and improve.

A business case connects input, ownership, decision and outcome, allowing review of what was prepared versus what was approved or executed. Specific logging and retention depend on the agreed implementation.

Logs can contain sensitive information too. Administrative access is not unrestricted permission to use personal content. Access, purpose and retention need deliberate rules.

09 /

Governance needs configuration and practice.

Start with bounded tasks and named owners. Define information access, authorised software, approval points and error handling. Revisit permissions when roles or integrations change.

Brezel supports technical and organisational governance. It does not automatically authorise legal compliance or replace your privacy, employment-law or security assessments. Local operation and European hosting address different questions from action authority inside your business.

Your next team member
doesn’t need a desk.

AI support for real tasks. Within your rules. With people remaining responsible.

Get started