Sistava

Protect Organisation Information

Your AI employee treats what it learns in the workspace the way a careful coworker would: useful for doing the work, not free to repeat. It tells private, role-restricted, and confidential information apart from ordinary shared context, and it never volunteers the sensitive kind just because someone asked. When a teammate needs a restricted answer, the employee can request permission from the right person for that one specific answer instead of guessing or refusing outright.

Every workspace is a mix of people with different access, and not everything an AI employee learns is meant for everyone. A hiring freeze mentioned before the announcement, a salary figure, a customer complaint shared in confidence: an employee that repeats whatever it knows to whoever asks is a liability, not a convenience. Information Boundaries is the behavior that keeps organisation knowledge usable without turning every private conversation into a company-wide broadcast.

The employee sorts what it knows into four boundaries: organisation-shared context anyone in the workspace can draw on, role-restricted information tied to a responsibility like finance or people operations, private information from a one-to-one conversation or about a specific person, and confidential information that is highly sensitive regardless of who is asking. A workspace role of Owner, Admin, or Member describes operational access to the platform, not automatic access to every private or confidential fact the employee has picked up. An optional job title someone gives the employee is context for how to work with them; it never unlocks information on its own.

The alternative most tools default to is binary: either the AI answers from everything it has ever seen, or it refuses everything and forces a human to relay the answer manually. Neither holds up in a real team. Sistava's employee does neither: it distinguishes what is safe to share by default from what needs a person to say yes, and when a restricted answer is requested, it can ask the right decision-maker for permission to share that exact answer rather than the underlying conversation. That keeps the employee genuinely useful across a growing team instead of either leaking everything or becoming useless the moment sensitive information enters the picture.

When someone asks for something outside their boundary, the employee says plainly that it cannot share it. It does not pretend it does not know, and it does not name who does know. If the requester wants, the employee asks their permission first, then sends a bounded request to the person who can decide: what would be shared, at what boundary, nothing more. The decision-maker sees only that proposed answer, never a link into the requester's private chat. Approve it, and the employee shares exactly that one thing. Reject it, and the employee says it cannot share the information, full stop.

Four Information Boundaries

Organisation-shared covers the normal business context an employee can use freely across the workspace: company profile, goals, and general operating facts everyone already has visibility into.

Role-restricted covers work information tied to a specific responsibility, such as finance figures or people-operations detail, where being in the workspace is not the same as being entitled to that particular answer.

Private covers anything that came from a direct, one-to-one conversation, or personal information about a specific person, that was never meant for the wider team.

Confidential covers highly sensitive business or people information regardless of how it reached the employee: the kind of thing that needs a deliberate decision before it moves, not a default answer.

Requesting Permission Without Exposing The Conversation

When a restricted answer is asked for, the employee never forwards the original conversation to get a decision. It distills the request down to the smallest possible disclosure, for example one figure or one fact, and sends that alone to the workspace member entitled to approve it.

The requester is never shown who was asked, and the decision-maker is never shown where the question came from or the surrounding chat. Both sides get a bounded, single-purpose exchange: approve this one answer, or don't. This scoping also means one approval never becomes blanket access; a yes to sharing one number is not a yes to the conversation it came from.

How It Works

Four boundaries, one bounded approval request

Every fact an employee handles carries an implicit boundary. Organisation-shared information, the normal business context anyone in the workspace can draw on, needs no gate. Role-restricted, private, and confidential information do: before repeating any of it to someone who was not part of the original context, the employee checks whether this requester already has standing to hear it.

If they do not, the employee does not go silent and it does not guess. It tells the requester it cannot share the detail, and offers to ask the person entitled to decide. Only with the requester's explicit go-ahead does it use the workspace-members tool to send one specific, scoped request, naming exactly what would be disclosed and under which boundary label.

The decision-maker gets a notification with that exact proposed disclosure, nothing more: no transcript, no link to the requester's original conversation, no broader context. They approve or reject. On approval, the employee shares only the approved scope. On rejection, the employee reports that it cannot share the information and does not reveal that anyone was asked, protecting both sides of the exchange.

Use Cases

Keep a private heads-up private

An owner tells the employee, in a direct chat, that a hiring freeze is coming before it is announced. When another teammate later asks whether the company is hiring, the employee does not repeat the private discussion; it says it cannot share that yet and offers to check with the owner for a specific, approved answer.

Let finance detail stay with finance

A team member outside finance asks the employee for a specific budget or salary figure it picked up while helping with a finance task. Instead of answering directly or refusing outright, the employee explains the information is role-restricted and can request permission from the right person for that one number.

Route a customer-sensitive detail through the right person

A collaborator asks about a customer complaint or contract term the employee learned in a confidential context. Rather than guessing at what is safe to reveal, the employee flags the boundary, gets the requester's agreement to ask, and sends a scoped approval request to the person entitled to decide.

Onboard new teammates without exposing old conversations

As new people join the workspace, the employee keeps using organisation-shared context to work with them normally, but earlier private direct chats with other teammates do not retroactively become group knowledge just because someone new arrived.

FAQ

Does being an Owner mean the employee shares every private conversation with me?

No. Owner is the highest operational access role in the workspace, but it is not automatic entitlement to every private or confidential fact the employee has picked up. Restricted information still goes through the same bounded permission request as it would for anyone else.

Can I give my AI employee my job title so it understands my role better?

Yes, tell it in chat and it saves that as context for how you work together. A job title helps the employee understand your work, but it never grants access to role-restricted, private, or confidential information on its own; that still requires the boundary check.

How do I approve or reject a disclosure request from my employee?

You get a notification showing the exact scope the employee wants to share, nothing more. Approve or reject it directly from that notification. There is no separate settings page to configure.

If I ask for something restricted and get rejected, will the employee tell me who said no?

No. If a disclosure is rejected, the employee tells you it cannot share the information. It does not reveal who was asked or that a request was even sent, protecting the decision-maker's side of the exchange the same way it protects yours.

Where Protect Organisation Information fits

Protect Organisation Information is part of What stops them from going wrong.

Your AI agents pause before any sensitive action and wait for your approval. PII is detected and redacted before it reaches the model. Content policies block harmful or off-brand output. Execution limits prevent runaway tasks. A Sistava mentor pairs with every employee to spot blockers and keep work on track alongside their team leader. Set company-wide policies once and every employee follows them, including future hires.

Read the guide

More in Guardrails

Explore