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

# Permissions & Data Access

> Complete matrix of what ewake reads from each integration, scope by scope. The page InfoSec teams need.

This page lists every permission ewake requests, what it accesses with each one, and what it explicitly does **not** access. It is intended to be the single source of truth for security and compliance reviews.

***

## Principles

<CardGroup cols={2}>
  <Card title="Read-only by default" icon="eye">
    Every integration uses read-only credentials. Ewake never modifies, writes, or deletes data in your connected systems unless a feature explicitly requires a write scope and you opt in.
  </Card>

  <Card title="Customer-isolated" icon="lock">
    Each customer's knowledge map is stored in an isolated environment. No data is shared between customers. Models do not train on customer data.
  </Card>

  <Card title="No raw telemetry retention" icon="database">
    Logs, metrics, and traces are queried live from your sources at the moment of investigation. Ewake retains derived metadata (services, dependencies, incident summaries), not raw data.
  </Card>

  <Card title="Encrypted in transit and at rest" icon="key">
    All API traffic uses TLS 1.2+. Stored knowledge-map data is encrypted with AES-256 at rest.
  </Card>
</CardGroup>

***

## Per-integration access matrix

### Datadog

Ewake uses an **Application key** scoped to read-only operations. The full list:

| Scope                     | What it enables ewake to read | Why it's needed                                           |
| ------------------------- | ----------------------------- | --------------------------------------------------------- |
| `apm_read`                | APM trace data                | Investigating distributed-trace context for slow requests |
| `apm_api_catalog_read`    | API catalog metadata          | Understanding service contracts in your environment       |
| `apm_pipelines_read`      | APM pipeline configuration    | Mapping observability data flows                          |
| `apm_service_ingest_read` | Service ingestion metrics     | Detecting traffic anomalies per service                   |
| `dashboards_read`         | Existing dashboards           | Surfacing relevant Datadog views during investigation     |
| `debugger_read`           | Live Debugger captures        | Adding runtime state context to investigations            |
| `error_tracking_read`     | Error tracking data           | Correlating errors with deploys and alerts                |
| `events_read`             | Datadog events stream         | Detecting deployment and infrastructure events            |
| `llm_observability_read`  | LLM observability data        | Investigating issues in LLM-backed services               |
| `logs_read_archives`      | Archived logs                 | Querying historical log context for past incidents        |
| `logs_read_data`          | Log content                   | Reading log lines as evidence in investigations           |
| `logs_read_index_data`    | Log index metadata            | Building efficient log queries                            |
| `metrics_read`            | Metric series                 | Reading time-series metrics for any service               |
| `monitors_read`           | Monitor definitions           | Understanding what triggered an alert                     |
| `timeseries_query`        | Custom time-series queries    | Building correlation queries across metrics               |

**ewake does NOT request:** any `write`, `manage`, `admin`, or `*_create` scopes. It cannot modify monitors, dashboards, logs, or any Datadog configuration.

***

### GitHub

Ewake uses a **GitHub App** with the following installation permissions:

| Scope               | Access level | What it enables                                 |
| ------------------- | ------------ | ----------------------------------------------- |
| Repository contents | Read         | Reading source code and diffs for investigation |
| Repository metadata | Read         | Listing repos, branches, default branches       |
| Pull requests       | Read         | Correlating PRs with deployments and incidents  |
| Commits & pushes    | Read         | Mapping who deployed what and when              |
| Deployments         | Read         | Tracking deployment events                      |

**ewake does NOT request:** write access to code, branches, PRs, or repository settings. It cannot push commits, create branches, comment on PRs, or merge anything.

The user-level OAuth authorization grants ewake read access on your behalf to repositories you can already see. The App installation is what grants organisation-level access.

***

### GitLab

Ewake connects to GitLab with a **service account access token** scoped to read-only operations:

| Scope             | Access level | What it enables                                          |
| ----------------- | ------------ | -------------------------------------------------------- |
| `read_api`        | Read         | Project data, merge requests, pipelines, and deployments |
| `read_repository` | Read         | Source code and diffs                                    |

The service account is added to your groups and projects with the **Reporter** role, the minimum needed to read code and merge requests. Its access is bounded by that role, ewake only sees projects the service account is a member of.

**ewake does NOT request:** the `api`, `write_repository`, or any write scope. It cannot push commits, create branches, open or comment on merge requests, or change project settings.

We recommend a dedicated **service account** over a personal access token, so access stays least-privilege, auditable, and survives staff changes.

***

### Slack

Ewake's Slack app requests these bot scopes (same for OAuth and manifest installs):

| Scope               | What it enables                                     |
| ------------------- | --------------------------------------------------- |
| `app_mentions:read` | Respond when `@ewake` is mentioned                  |
| `assistant:write`   | Slack Assistant / AI features                       |
| `channels:history`  | Read messages in channels ewake is added to         |
| `channels:join`     | Join public channels when invited                   |
| `channels:read`     | List channels in the workspace                      |
| `chat:write`        | Post messages and replies                           |
| `groups:history`    | Read messages in private channels ewake is added to |
| `groups:read`       | List private channels                               |
| `im:history`        | Read direct message history                         |
| `mpim:history`      | Read group DM history                               |
| `reactions:read`    | Read emoji reactions on messages                    |
| `users:read`        | Read workspace member list                          |
| `users:read.email`  | Resolve user emails for routing                     |

Manifest installs must grant at least these scopes. The manifest shown in the Ewake dashboard dialog requests them all.

**ewake does NOT request:** access to private channels it has not been added to, file uploads it cannot read, admin-level workspace settings, or message deletion.

***

### Incident.io

Ewake requests an API key with these permission groups:

| Permission group                            | Scopes    | Required?                           |
| ------------------------------------------- | --------- | ----------------------------------- |
| View data (public incidents + org settings) | 18 scopes | ✅ Required                          |
| View catalog types and entries              | 3 scopes  | ✅ Required                          |
| Read schedules                              | 1 scope   | Optional, enables on-call reasoning |

**ewake does NOT request:** any incident creation, editing, or resolution permissions. It cannot declare incidents, change severity, or post on your behalf in Incident.io.

***

## What ewake does NOT access

To make this explicit, ewake never:

* Modifies, writes, or deletes data in any connected system
* Reads private Slack channels it has not been invited to
* Pushes commits, opens PRs, or modifies code
* Silences, acknowledges, or closes alerts
* Trains foundation models on your data
* Shares your knowledge map with other customers

***

## Data handling

| Topic              | Detail                                                                                                              |
| ------------------ | ------------------------------------------------------------------------------------------------------------------- |
| **Raw telemetry**  | Queried live from your sources at investigation time. Not retained by ewake.                                        |
| **knowledge map**  | Persisted per-customer. Stores derived metadata (service map, incident summaries, correlations). Encrypted at rest. |
| **PII / secrets**  | Logs are filtered through redaction patterns before being included in ewake outputs.                                |
| **Data residency** | Contact [support@ewake.ai](/support) for current region availability.                                               |
| **Sub-processors** | Full list available on request, contact [support@ewake.ai](/support).                                               |

***

## Compliance

<Note>
  **SOC 2**, ewake is in active SOC 2 Type II preparation through Sprinto. Contact [support@ewake.ai](/support) for the current report status and timeline.
</Note>

***

## Customer responsibilities

To get the strongest security posture from your ewake deployment:

* **Scope API keys minimally**, use the exact scopes listed above, no more
* **Rotate credentials regularly**, at least every 90 days
* **Use Google SSO** for ewake login rather than shared credentials
* **Audit Slack channel membership**, ewake only sees what's in channels it's invited to
* **Review the GitHub App scope**, install on the minimum repository set you need
* **Use a dedicated GitLab service account**, not a personal token, so access survives staff changes and stays auditable