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.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.
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 |
Slack
Ewake’s Slack app requests these OAuth scopes:| Scope | What it enables |
|---|---|
channels:history | Read messages in channels ewake is added to |
channels:read | List channels in the workspace |
chat:write | Post messages and replies |
im:write | Send direct messages to users |
users:read | Read workspace member list (for routing and mentions) |
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