Principles
You decide what ewake can do
Ewake investigates by reading your connected systems. It writes only where you’ve given it access, through the actions you approve: see How ewake takes action.
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.
How ewake takes action
Investigation reads. Taking action, such as restarting a pod, opening a pull request or creating a Linear ticket, writes, and ewake does it only with access you’ve granted. There is no fixed list of things ewake will or won’t do. What it can do is defined by you: the integrations you connect, the access those credentials or MCP servers grant, and the actions you approve. What bounds it:- Approved at setup. Write actions are approved when you configure an On-Call Agent trigger in the dashboard. You describe the follow-up in plain words, for example “create a Linear ticket describing the root cause”, and ewake carries it out after the investigation.
- Confirmed in Slack, case by case. Some actions, such as opening a pull request, run only when someone on your team clicks to confirm in Slack.
- Bounded by the access you grant. Ewake can only use tools from integrations you’ve connected, with the access those credentials already grant. Expose only read tools on your Kubernetes MCP server and ewake can’t restart a pod; connect Linear with a read-only key and no ticket gets created.
- Reviewable before saving. Parse action shows you the exact tool calls your wording becomes, before the trigger is saved.
- 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.
If your security review needs ewake to be read-only, connect every integration with read-only credentials and 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, 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, timeseries_query, apm_read, dashboards_read, events_read and mcp_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.
A self-hosted deployment can act as a GitHub App you create in your own organisation, which grants exactly the read set above. The App is yours, its private key never leaves your account, and the installation is on your organisation rather than ewake’s. See GitHub App (self-hosted).
How the credential works
Ewake stores no GitHub credential. Each read mints an installation token from the App, scoped to that installation and valid for about an hour, and discards it. There is no token to rotate, nothing to leak from the database, and revoking access is a matter of uninstalling the App. Ewake’s GitHub client issues read requests only: every call is aGET. There is no
code path that writes to a repository, regardless of what the installation would permit.
Access is bounded by the repositories chosen at install time, so an App installed on
three repositories gives ewake three repositories.
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.
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 do
Ewake has no fixed list of actions it refuses: what it can do is the access you give it. What is fixed:- It never uses access you haven’t granted. It acts only through the integrations, tools and credentials you’ve connected
- It never reads Slack channels it has not been invited to
- It never trains foundation models on your data
- It never 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
- Give MCP servers only the access you want ewake to use, read-only unless you want ewake to act, and keep the tool allowlist tight