What the assistant will not do

The assistant’s limits are worth stating precisely, because “the AI is read-only” can mean several different things.

It cannot change anything

The assistant has no mutating capability. It cannot create, modify, or delete a resource in AWS, and it cannot change anything in Aletheia either — not an application, not an ownership assignment, not a mapping correction.

This is enforced structurally rather than by instruction. The assistant reaches your data through a fixed set of read-only operations; there is no write operation available for it to call, so there is nothing for a prompt to talk it into.

It has no AWS access of its own

The assistant never assumes your role and never calls an AWS API. It reads what discovery already collected and stored. Turning the assistant on grants it no additional access to your cloud.

It cannot leave your organization

The assistant’s queries are scoped to your organization on the same code path that scopes every other query. It cannot see, summarise, or infer another tenant’s data.

It does not answer without evidence

Answers are built from the results of the queries it ran, with citations back to the specific records. If the data does not support a statement, the assistant says so rather than filling the gap.

This is the property worth checking when you evaluate any AI feature. An assistant that produces a confident answer with nothing behind it is worse than one that declines, because you cannot tell the two apart from the output alone.

Everything it does is recorded

Every conversation and every question is written to an audit log — who asked, what they asked, and when. See Administration.

What this means in practice

You can give the assistant to anyone who is already allowed to read your infrastructure data, without expanding what they can do. It is a faster way to ask questions, not a new set of capabilities.

Where to go next

• Ask Aletheia for what it can answer.
• Roles and permissions for who can see what.