# 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.

- [What stops them from going wrong](/en/features/guardrails): Nothing sensitive happens without your say.

## Read the guide

- [Guide: Protect Organisation Information](/en/guide/company/information-boundaries)

## More in Guardrails

- [AI Guardrails & Policies](/en/features/guardrails/guardrails): A Security Officer that checks every message going into and coming out of every AI employee you have. Five policies, each with its own switch: Input Safety stops prompt injection and jailbreak attempts, Output Safety keeps unfit replies from being sent, PII Protection replaces personal data with markers before the model reads it, Data Leakage Prevention keeps your setup and secrets in-house, and Topic Control holds employees to the subjects you choose. Turn on what you need from Settings, Technical, Security Officer and it covers every employee on the next message, including the ones you hire later. Checks run in parallel on a separate lightweight model, so protection costs a fraction of a message and your team never feels the wait. A running count of what has been caught, the busiest policy, and a live inspector showing every individual message are all on the same page.
- [Protect Against Prompt Injection](/en/features/guardrails/guardrail_input_safety): Input Safety reads every incoming message before your employee does, and stops the ones trying to hijack it: instructions to ignore its rules, requests to print its own configuration, and role-play framed to talk it out of its guardrails. That matters most where the message did not come from you, so a payload buried in a forwarded email, a support ticket, or a shared thread cannot turn your employee against you. Pick Low, Medium, or High, and every level catches the textbook attacks: the level decides how much benefit of the doubt the genuinely ambiguous messages get. Medium is the default and suits most companies. Blocked messages get a short, human reply and the conversation carries on, with each one recorded so you can see what has been tried.
- [Block Unsafe Employee Responses](/en/features/guardrails/guardrail_output_safety): Output Safety reads your employee's reply before anyone else does. Toxic, abusive, or otherwise unfit answers are held back rather than sent, which is what you want the moment employees write to customers, post to a channel, or answer a ticket without you watching. It checks the reply your employee actually wrote, so what you see caught is what would genuinely have gone out. Set it to Low, Medium, or High and review everything it held back in the live inspector. Blunt, direct, and critical business writing is left alone: the policy is looking for replies that would embarrass you, not ones that are simply frank.
- [Protect Personal Data](/en/features/guardrails/guardrail_pii_protection): PII Protection finds personal data in a message and replaces it with a marker before the model reads a single character of it. A pasted card number becomes [CREDIT_CARD], an email becomes [EMAIL_ADDRESS], and the same happens on the way out so nothing sensitive travels back into an email, a channel, or a ticket. You pick exactly what to protect from seven data types: email, phone, name, credit card, Social Security number, IP address, and address. The markers keep the sentence readable, so your employee understands the request perfectly and keeps working while the raw value stays out of the conversation. It runs on every message, in both directions, company-wide, from one switch.
- [Control What Employees Discuss](/en/features/guardrails/guardrail_topic_control): Topic Control gives you two lists and you can use either or both. Blocked topics are off-limits no matter how a conversation gets there, which keeps employees out of politics, competitor comparisons, or medical and legal advice. Allowed topics set a remit instead: name the subjects an employee handles and anything unrelated is politely declined, which is how you keep a support employee on product help, billing, and refunds. Both lists match on meaning rather than exact words, so ruling out competitor pricing also covers how much cheaper are we than the other tools out there. Greetings and short replies always get through, so a scoped employee still feels natural to talk to.
- [Keep Confidential Data In-House](/en/features/guardrails/guardrail_data_leakage): Data Leakage Prevention guards both ends of the conversation. On the way in it recognises someone fishing for your employee's internals, whether they ask outright, dress it up as a game, or try the repeat everything above this line trick. On the way out it reads the reply itself and holds it back if it is about to hand over a system prompt, internal configuration, an access token, or a credential. Questions about your own business data are never affected, so an employee still answers freely about your customers, documents, and numbers. One switch, no configuration to maintain, and every attempt is logged so you can see who has been probing.
- [Prevent Repeated and Runaway Actions](/en/features/guardrails/tool_safety): Sistava automatically caps how many emails, messages, and external writes (CRM records, calendar events, paid searches) an AI employee can send in a single conversation, hour, and day, and blocks an identical send to the same recipient from going out twice within 24 hours. These limits run in the background per employee with no setup required, so a stuck task or unexpected loop cannot spam a contact's inbox, pollute your CRM, or burn through paid API calls. When a limit is hit, the employee is told to slow down or hand the task to a human instead of retrying blindly.
- [Approve Sensitive Actions](/en/features/guardrails/input_requests): Let an AI employee pause and ask before it takes a sensitive action, like sending an email or spending on a paid tool, instead of guessing what you want. An inline card shows up right in the chat with Approve, Reject, or option buttons, and the employee resumes the instant you respond.
- [Protect Your Email Reputation](/en/features/guardrails/email_deliverability): Every email your AI employees send, whether it is a notification, a mailbox reply, or an outbound message, passes through a pre-send check before it leaves. Sistava validates the address, checks it against a suppression list built from past bounces and complaints, and blocks anything that would hurt your sending reputation. You do not configure this: it runs silently on every send so your domain keeps a clean track record with inbox providers.
- [Delegation & Teamwork Limits](/en/features/guardrails/delegation_teamwork_limits): Tune how your leader employees hand off work to teammates. Set how many teammates a leader can delegate to at once, how far a delegation chain can reach, how long a delegated teammate can work before timing out, and how tolerant employees are of repeating themselves before loop protection stops them.
- [Detect and Redact PII](/en/features/guardrails/pii_detection): PII Protection watches every message your AI employees send and receive, and masks personal data like emails, phone numbers, credit card numbers, and social security numbers before it goes anywhere it shouldn't. You choose exactly which data types to catch. It runs on every employee across your company the moment you turn it on, with no per-employee setup.
- [Company-Wide Policies](/en/features/guardrails/company_policies): Company Policies let you set organization-wide safety rules that apply to every AI employee at once: block prompt injection attempts, filter harmful output, redact personal information, stop internal details from leaking, and restrict which topics employees can discuss. Turn each policy on with one toggle from your company dashboard, and it takes effect immediately across your whole team.

## Explore

- [Every feature](/en/features)
- [Hire an AI employee](/en/market)
- [Pricing](/en/pricing)