> ## Documentation Index
> Fetch the complete documentation index at: https://docs.exec.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What the AI Can See

> Exactly what your AI assistant can read and change in Exec, and what to tell your security team.

Connecting an AI assistant to Exec does not change what you can access in Exec. The connection uses the same login and the same permission model as the product, so your assistant can reach only the data and actions your own account is allowed to reach, and nothing beyond that.

***

## Who sees what

|                                          | A member                    | A group admin                     | A workspace admin |
| :--------------------------------------- | :-------------------------- | :-------------------------------- | :---------------- |
| Their own roleplay sessions              | Yes                         | Yes                               | Yes               |
| Other people's sessions                  | No, unless shared with them | Members of groups they administer | Everyone          |
| Session transcripts and coach feedback   | Their own                   | Their groups                      | Everyone          |
| Assignments                              | Their own                   | Their groups                      | Everyone          |
| Skill proficiency and scenario analytics | **No**, not even their own  | Their groups                      | Everyone          |
| Member directory and group list          | Yes, workspace-wide         | Yes                               | Yes               |

Two points are worth spelling out, because they are what reviewers ask about.

**Analytics are not available to individual members, including about themselves.** If a rep asks their assistant which skill the team is weakest at, or for the breakdown on a scenario, the request is refused. So is the same question asked only about their own scores. This matches the product exactly, where the skills dashboard and scenario analytics return a permission error for anyone who is not a workspace admin or group admin.

That is narrower than it sounds, and it is worth being precise about what a rep does still get. Their own sessions, their per-criterion grades, and their coach feedback are all readable, so questions like "how am I doing" and "what feedback keeps coming up for me" work normally. What is withheld is the aggregated proficiency score and the scenario-level breakdown. The reason the refusal is outright rather than quietly narrowed to the person asking is that an assistant cannot tell a self-scoped answer from a team-wide one, and would present the first as the second.

**The member directory is visible to everybody in the workspace.** Any member can list their colleagues, including names and email addresses, and can list the groups. This matches the product, where the directory is also visible.

Program leads can also see sessions and assignments for the programs they lead, and anyone who can assign work can see the assignments they created.

***

## What it can change

One thing: it can create a roleplay scenario.

That is the entire write surface. It cannot delete anything, edit anything, assign work, invite or remove people, change settings, or touch billing. Requests to do any of those are refused rather than attempted.

When it builds a scenario, it produces a draft, describes what it made, and waits for you to approve before publishing.

<Warning>
  **A scenario published through an assistant is shared with the whole workspace.** To keep one private, just ask to set its visibility to you.
</Warning>

***

## What it cannot reach at all

* **Knowledge Hub content.** It cannot search or read your Knowledge Hub. It can use Knowledge Hub material as source material when building a scenario, but it cannot report your Knowledge Hub back to you.
* **Any other workspace.** A connection is bound to the one workspace chosen at sign-in. It cannot be pointed at a different one without disconnecting and reconnecting.
* **Billing and subscription data.**
* **Anything in Exec's admin surfaces.**

***

## Signing in, and what the consent screen says

When your assistant connects, Exec asks you to sign in on an Exec page. Single sign-on works if your company uses it. The same failed-login protection as the app applies, so somebody locked out of Exec is also locked out of connecting.

If you belong to more than one Exec workspace, you choose which one. That screen tells you the assistant will be able to view and update data in the workspace you select. If you belong to exactly one workspace, that step is skipped, which means you may never see a permission screen at all. This page is the full statement of what you granted.

**Reconnecting is often silent.** If you already have a live connection for the same assistant and reconnect, you may go straight through with no sign-in and no consent screen, reusing the workspace you chose originally. That is expected rather than a failure.

***

## Access, expiry, and revocation

|                                     |                                                                                                          |
| :---------------------------------- | :------------------------------------------------------------------------------------------------------- |
| How long access lasts               | Refreshed quietly in the background. About a month of inactivity before you would need to sign in again. |
| Deactivating someone in Exec        | Cuts their access on their next request, not whenever the connection would have expired                  |
| Removing someone from the workspace | Same, immediate on their next request                                                                    |
| Disconnecting from the assistant    | Ends the whole authorization, including its ability to refresh                                           |

**You do not need to touch anyone's AI assistant to cut off access.** Deactivate them in Exec, as you would anyway, and the connection stops working straight away.

***

## Two things a security reviewer should know

Both are worth understanding before you roll this out widely.

**Content your assistant reads can contain instructions.** This is inherent to the way AI assistants work rather than specific to Exec. If your assistant reads a document, a web page, or a transcript containing text written to influence it, that text can affect what it does next. Review what an assistant proposes before approving it, particularly when it is about to send something or publish something.

**An assistant with several tools connected can move data between them.** Once your assistant holds Exec data, it can include that data in something it writes elsewhere, such as a document, a message, or a ticket in another system. That is exactly what makes combining Exec with your other tools useful, and it is also the thing to be deliberate about. If your policies restrict where performance data may go, cover assistants explicitly in those policies, because the connection itself does not enforce them.

***

## Managing it centrally

There is no MCP settings page in Exec today, so there is no list of who has connected and no way to disconnect somebody else from inside Exec. See [Admin controls](/mcp/admin-controls) for what you can govern and where.

The practical position: access is always bounded by each person's own Exec permissions, and offboarding through Exec cuts access immediately. Central approval of whether Exec may be connected at all lives in your AI tool's organization settings.

***

## Next

<CardGroup cols={2}>
  <Card title="Admin controls" href="/mcp/admin-controls">
    What you can govern, and where
  </Card>

  <Card title="Available tools" href="/mcp/available-tools">
    The full list of what it can do
  </Card>
</CardGroup>