Principles
Read-only by default
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.
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.
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 |
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 |
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 |
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 |
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 |
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 for current region availability. |
| Sub-processors | Full list available on request, contact support@ewake.ai. |
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 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