Security, privacy and permissions
How Autessa Status Page keeps the public side read-only
Autessa Status Page separates writing from reading by design: staff change things in a signed-in console where every post is stamped with who made it, and the public status site can only read public fields. AI drafts never publish without a person.
- Status Admin (staff, signed in)Writes components, incidents, maintenance, changelog and settings with each person's own access.
- Your dataComponents, events, updates, changelog and settings tables.
- Two read-only toolsStatus and Changelog. Public fields only; approved entries only.
- Public status site (anyone)Reads and displays. Cannot write.
Controls
What is protected, and how?
| Area | How it works |
|---|---|
| Public site access | The public status site has no direct access to your data. It reads through read-only tools, one for status and history and one for the changelog. |
| Public fields only | Public answers include component names, descriptions and statuses, incident titles, impact, status, times and update text. Staff emails, source pull requests and original AI drafts are never returned. |
| Changelog approval | The nightly drafter can only create drafts, and the public changelog returns approved entries only, checked on the server. |
| Status Admin | Staff-only, shared inside your company and behind sign-in. Every read and write runs with the signed-in person's own access. |
| Audit stamps | Incidents record who created them, updates record who posted them, and changelog entries record who edited and approved them, with times. |
| Safe rendering | Updates and release notes are shown by a small Markdown renderer that builds the page from text only and never inserts raw HTML; links must be web links. |
| GitHub access | A read-only token (pull request and metadata read) stored as a sealed Autessa secret, usable only by the drafting tools and only to call the GitHub API. |
| AI writer rules | The changelog writer is told never to mention customer or people's names, emails, internal hostnames, account ids, secrets, prices or how something is protected, and never to name a vulnerability. |
| Approval checklist | Before publishing, reviewers are asked to check that the entry names no customers, people, internal systems or security details. |
| Reminder emails | Go only to the reviewers listed in Settings, and can never approve, publish or edit anything. |
Permissions
Who can do what?
| Who | Can | Cannot |
|---|---|---|
| Visitors | Read status, incidents, history and approved release notes | Change anything, see drafts, staff names or source pull requests |
| Staff in Status Admin | Manage components, incidents, maintenance, changelog, reviewers and repositories | Use the app without signing in |
| Nightly drafter | Insert one draft per day | Update, approve or publish an entry |
| Reviewer reminder | Email the listed reviewers | Approve, publish, edit or create an entry |
Trust Center
Security documentation for Autessa
Autessa's security program, policies and reports are published in the Autessa Trust Center.
Both halves of Status Page are Autessa apps, so they use the same sign-in, sharing and sealed secrets as the rest of your Autessa account.
FAQ
Security questions
Can visitors to the status page see internal data?
No. The public site reads only through read-only tools that return public fields, and it cannot reach your tables directly.
Can an AI-written changelog entry publish itself?
No. Only a person can approve an entry, and the public page refuses anything that is not approved.
Where can I read about Autessa's certifications and security program?
In the Autessa Trust Center at trust.autessa.com.
100% customizable, code and all
Make Autessa Status Page fully your own.
Use it out of the box, then change anything. Ask Autobot, Autessa’s AI builder, for a new field, screen, report, workflow or agent and it builds it into your copy of the app. Or open the code and edit it yourself. Nothing is locked: the app, its data and its code are yours.
Start free and make it yours