Security and data
How Ace accesses your systems, what data it reads and keeps, how credentials and personal data are protected, and how your data stays inside your organization.
Ace reads from the tools you connect and changes nothing unless an admin allows it. This page covers what Ace can access, what it stores, how that data is protected and how to delete it. For SOC 2 Type II reports and subprocessors, see the Trust Center.
Read-only by default
Connecting a source gives Ace read access. Write access is a separate step an admin takes for each integration, and it can be turned off again.
| Integration | Read access | Write access |
|---|---|---|
| AWS | A read role in your account that never changes anything and is never given write access. It explicitly denies reading data inside your resources: S3 objects, DynamoDB items, SQS messages, Secrets Manager secrets, SSM parameters and full SQL text from Performance Insights. | A separate, optional actions role whose operations come in groups, each off until you choose it. |
| Kubernetes | A read-only reader Deployment that you run in your cluster. It connects out to Ace, so Ace needs no inbound access to your cluster API. | A separate, optional writer Deployment for approved actions, so read access never implies write access. |
| GitHub | The Ace GitHub App, with read access to the repositories you choose. | Ace opens pull requests and runs your deploy workflow only for approved actions. |
| Other integrations | The credential you provide. | Only after an admin turns on actions for that integration, and only for operations the credential allows. Ace never proposes an operation it knows the credential can't perform. |
With actions allowed, every change to code or infrastructure needs approval of its exact plan. The exception is earned autonomy, where an admin made an action automatic on a workload where it has a verified record of fixing incidents without making anything worse.
Updates that only change what your team sees in a tool, such as an annotation or an issue's state, run without approval and can be undone from the incident. An admin can also stop all actions at once. See Actions and approvals.
Until our team activates your workspace, Ace runs no investigations and no actions.
What Ace reads
- When it investigates a workload, Ace reads only the sources selected for that workload, plus any source that routes alerts to it. From GitHub it reads only the repositories linked to the workload. Admins choose these in the workload's settings.
- In Slack, Ace receives messages in channels it has been added to and in direct messages to it.
- For metric watches, Ace reads metrics from your providers. CloudWatch watches stay off until an admin turns them on, because those reads are billed to your AWS account.
- The AWS actions role can technically see some values that hold secrets, such as Lambda environment variables, but Ace doesn't store them.
- Ace keeps Kubernetes Secret values out of evidence.
What Ace keeps
Ace stores what it needs to investigate and to show you what happened:
- incidents, the evidence collected and investigation results, where evidence is made of snippets from logs, metrics, traces and changes rather than full copies of your data
- alert events and HTTP check results
- action plans, approvals and the result of each run
- a change ledger of deploys and other changes
- your System Map, built from your AWS accounts
- memory, meaning incident summaries and learned patterns
- notes and Slack replies from your team, after redaction
Your workspace has a history window, which sets how far back you can view incidents and activity in Ace. Older activity is kept but shown as outside the window. To change the window, talk to our team.
Some short-lived records are deleted on a schedule. Metric samples for metric watches go after 28 days, and MCP access records, which show which token read which incident, go after 90 days.
Credentials
Ace encrypts integration credentials, Slack installation tokens, webhook secrets and Kubernetes connector credentials at rest. MCP tokens are stored only as hashes and shown once, when created. Ace stores no AWS credential because it assumes the role you created, using an external ID unique to your organization.
Disconnecting an integration deletes the stored connection and credentials in Ace, but it doesn't revoke the credential at the provider or remove what you created on your side, such as a CloudFormation stack, a Helm release, the GitHub App installation or the Slack app. Remove those at the provider.
Tenant isolation
Ace resolves every request to the caller's organization and limits every read and write to it. Memory, including similar-incident search, covers only your organization, and nothing Ace learns in one organization is used in another.
MCP tokens are scoped to one organization, and each person belongs to one organization.
Redaction
Ace removes secrets and personal data from text before storing it. From Slack replies and incident notes, Ace removes credentials, tokens, keys, signed URLs, email addresses, payment card numbers, phone numbers and IBANs. It also removes other personal or secret details it detects, such as customer names, addresses, account numbers and health details. Each removed value becomes a marker naming its type, such as [REDACTED_EMAIL], before the text reaches memory, investigations or the MCP server.
From log text read from your providers, Ace scrubs credentials and common personal data, including email addresses and IPv4 addresses, before the text is used in an investigation or stored as evidence.
Ace also redacts HTTP check responses and removes sensitive fields from AWS responses. For Kubernetes, it keeps only the shape of configured values.
Redaction targets known kinds of secrets and personal data and can miss some, so avoid pasting secrets into Slack or notes.
AI models
Ace uses models from a third-party AI provider to investigate incidents, interpret Slack messages, detect personal data for redaction and run similar-incident search. For subprocessors, see the Trust Center.
Ace treats text from your systems and your team as data, never as instructions, and before activation it sends nothing to the AI provider.
Audit logs
| What | What's recorded |
|---|---|
| Actions | An append-only record of every plan decision with who made it and the exact plan, every approval, every run, and every policy change with its before and after values. You can see an action's activity on the incident. |
| Incident attempts | An append-only record of every investigation attempt and every question Ace asked, with who answered. |
| MCP access | Which token read which incident, kept for 90 days. |
Deleting data
- When an admin deletes a workload, Ace first stops its checks and watches, stops running investigations and voids action plans awaiting approval, so nothing acts on a workload that's going away. It then deletes the workload's incidents, HTTP check history, memory, change events and deployment links, and finally the workload itself.
- Disconnecting an integration deletes its stored connection and credentials in Ace.
- Deleting a metric watch deletes its history, but incidents it opened are kept.
- You can delete your own notes, and nobody who reads the incident later sees a deleted note.
Hosting
Ace is a hosted service at app.tryace.dev, and the Kubernetes connector runs inside your cluster and connects out to Ace.
Next steps
Ace MCP server
Give coding agents, code reviewers and other MCP clients read-only access to Ace's incident context, lessons from past fixes, your operating rules and the current state of a workload.
Roles and permissions
The two workspace roles in Ace, what admins and members can each do, how approval permissions work, and how people sign in and join.