Access and audit trail
How admin-assigned access and profiles decide who sees what and how it is explained, why the check happens before the model sees anything, and how every action is logged.
Two separate settings
Each member has two settings, and they are kept apart on purpose.
Access decides what they can see and do. Admins assign who sees what. An admin places each member in an organization and in one or more projects, and sets their scope: what they can ask about, which flows they answer and approve for, and whether they manage members and sources. An outside party, such as an auditor, gets one scope, and their access ends on a set date, automatically.
A profile decides how answers are explained. A developer sees service names, APIs and stack traces. Support sees customer impact and next steps. A product manager sees the business rule and the decision behind it. An executive sees the outcome and who stands behind it.
A profile never widens access. A support member with a developer profile still sees only their own scope.
Members sign in through your company’s sign-in system, such as Okta, Google Workspace or Microsoft Entra ID. Access is set in AppThentic, so a guest does not need an account on your source systems to get a scoped answer.
Authorization before retrieval
Every question passes the same checks, in order, before anything reaches the model:
- Identity: who is asking.
- Organization and project membership: which projects they belong to.
- Assigned access: what an admin allowed this person.
- Scope and classification: which resources and data are inside their reach, and how sensitive each is.
- Permitted context: only what passes the checks above is retrieved for the model.
- Response: the model explains that context in a way that fits the person.
The model never decides what someone may see. If information is not authorized, it is never retrieved, so it cannot appear in an answer however the question is phrased.
Restriction rules
An admin can write a restriction in plain words, for a group of people or a project:
Don’t give payment provider details to developers.
AppThentic turns it into a rule and shows what it will hide before it applies:
Hide payment provider details: provider names, API keys and settlement terms
From developers, in every project
Hides 47 facts across Payouts and Billing. Developers still see that these rules exist, and who owns them.
Apply rule Edit
Once the admin applies it, the rule is checked at step 4 above, before anything is retrieved. The hidden facts never reach the model for those people, so no wording of a question can bring them back. The sentence the admin typed is never passed to the model as an instruction. Every rule, and every change to it, is in the audit trail.
The audit trail
Every action is logged with who and when:
- Each question asked, and to whom.
- Each call to or from om: who called, what om answered, whom it called and what they said.
- Each answer, approval, correction and rejection.
- Each change of owner, status or access.
- Each source connected or disconnected.
The trail is what lets an approval stand up later. See Audit and compliance.