Skip to main content
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

Read-only data access

Ewake reads from your connected systems. It does not modify, write, or delete data in them, with one exception you configure yourself: Actions.

Customer-isolated

Each customer’s knowledge map is stored in an isolated environment. No data is shared between customers. Models do not train on customer data.

No raw telemetry retention

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.

Encrypted in transit and at rest

All API traffic uses TLS 1.2+. Stored knowledge-map data is encrypted with AES-256 at rest.

​
Actions, the one write path

Investigation is read-only. Actions are not, and they are the one place ewake can change something outside itself. An Action is an optional follow-up you attach to an On-Call Agent trigger: after an investigation finishes, ewake carries out an instruction you wrote in plain words, for example “create a Linear ticket describing the root cause” or “post a summary to #incidents”. What bounds them:
  • Off unless enabled. Actions are a gated feature. If the Action field doesn’t appear on your trigger form, no Action can run on your workspace.
  • You write them. An Action only ever does what you typed into the trigger. Ewake does not invent follow-ups.
  • Bounded by your credentials. An Action can only use tools from integrations you’ve connected, with the access those credentials already grant. If you connected Linear with a read-only key, no ticket gets created.
  • Reviewable before saving. Parse action shows you the exact tool calls your wording becomes, before the trigger is saved.
  • Never infrastructure. Actions work through connected SaaS integrations. Ewake still cannot restart a service, change a monitor, push code, or touch your infrastructure.
If your security review needs “ewake cannot write anywhere, full stop”, ask support@ewake.ai to confirm Actions are disabled for your workspace.

​
Per-integration access matrix

​
Datadog

Ewake uses an Application key scoped to read-only operations. The full list: ewake does NOT request: any write, manage, admin, or *_create scope. It cannot modify monitors, dashboards, logs, or any Datadog configuration. It also does not request debugger_read, llm_observability_read, error_tracking_read, events_read, logs_read_archives, logs_read_index_data, apm_api_catalog_read, apm_pipelines_read, or apm_service_ingest_read. No ewake code path calls those APIs, so granting them would widen your exposure for no functional gain.
When you test the Datadog connection, ewake probes monitors_read, logs_read_data, metrics_read, apm_read and dashboards_read and reports each as granted or missing, so you can confirm the key before saving.

​
GitHub

Ewake uses a GitHub App with the following installation permissions: 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.

​
Connecting with a personal access token

Where organisation policy blocks third-party GitHub Apps — and on self-hosted deployments — ewake connects with a token instead. A fine-grained token carries these permissions, all Read: The equivalent classic scopes are repo and read:org. repo is broader than ewake needs — GitHub offers no read-only variant for private repository contents — which is why the fine-grained token is preferred. Ewake’s GitHub client issues read requests only: every call is a GET. There is no code path that writes to a repository, regardless of what the token would permit. Access is bounded by the repositories selected on the token, so a token scoped to three repos gives ewake three repos.

​
GitLab

Ewake connects to GitLab with a service account access token scoped to read-only operations: 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

Slack is the one integration where ewake holds write scopes, because posting investigations into your threads is the product. The app requests the same scopes on both install paths (OAuth and manifest). Verified at install. These thirteen are checked when you connect; a manifest install missing any of them is rejected and the missing ones are listed: Also present in the manifest. The manifest is a single shared definition covering every deployment, so it carries seventeen further scopes. Ewake’s current code paths don’t call the corresponding Slack APIs, and the install does not require them:
On a manifest install you own the app, so you can delete any scope outside the verified thirteen before creating it. On the standard OAuth install the scope set is fixed by the shared app.
ewake does NOT request: access to channels it has not been added to, admin-level workspace settings, or message deletion. It reads only the channels you invite it to.

​
Incident.io

Ewake requests an API key with these permission groups: 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.

​
Kubernetes and Custom MCP servers

Both connect to an MCP server you run and expose, not to a credential you hand over.

​
Credential-based integrations

The remaining integrations authenticate with a credential you create and paste in. In every case ewake reads only, and secrets are stored encrypted.

​
What ewake does NOT access

To make this explicit, ewake never:
  • Modifies, writes, or deletes data in any connected system, except through an Action you configured yourself
  • Reads Slack channels it has not been invited to
  • Pushes commits, opens PRs, or modifies code
  • Silences, acknowledges, or closes alerts
  • Restarts services, changes monitors, or touches your infrastructure
  • Trains foundation models on your data
  • Shares your knowledge map with other customers

​
API keys

Ewake API keys authenticate machine access to your workspace: deployment events and the MCP server. Treat a key as a full workspace credential. For anything a person uses, prefer MCP OAuth instead, so access is attributable to an individual and revoking one person doesn’t affect anyone else.

​
Data handling

​
Compliance

SOC 2, ewake is in active SOC 2 Type II preparation through Sprinto. Contact support@ewake.ai for the current report status and timeline.

​
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 SSO for ewake login rather than shared credentials
  • Treat ewake API keys as workspace credentials, prefer MCP OAuth for anything a person uses
  • 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
  • Connect MCP servers with read-only credentials, and keep the tool allowlist tight