AppsSecurity & Compliance

Every control

Autessa security features: SSO, RBAC, row-level security, secrets and audit

Autessa Security & Compliance covers identity and sign-in, access control, data protection, secrets management, API and machine access, and audit and evidence. Every control is built into every Autessa company and works out of the box. Controls marked as differentiators go beyond what a typical app platform offers.

Start free

§1 · IDENTITY AND SIGN-IN

Identity and sign-in

Members sign in through your Google Workspace or Microsoft Entra ID with SSO, add two-step verification, and stay signed in only as long as your company allows.

About identity and sign-in →

Single sign-on (SSO) →

Autessa includes single sign-on: pick Google or Microsoft Entra ID, verify your email domain with a DNS record, and turn on Require SSO so everyone with that address signs in through your provider.

Two-step verification →

Autessa includes two-step verification: after the password, members enter a 6-digit code from an authenticator app or from email, with single-use recovery codes as a backup.

Sign-in methods and passwords →

Members sign in to Autessa with Google, Microsoft, Apple, a one-time emailed code or a password of at least 12 characters, and a password change signs out their other devices.

Session controls →

Admins set one sign-out-after-inactivity length for the company, cap how long CLI sign-ins last, and decide whether Drive can be used from computers, while sign-in stays tied to the network it began on.

Sign-in for the apps you publish →

Every app you publish picks a hosting mode, from team-only to Custom Auth accounts with email, Google or Microsoft, and row rules can scope each visitor to their own records.

§2 · ACCESS CONTROL

Access control

Roles decide which parts of Autessa a member can use, and every resource starts private, then is shared at Viewer, Editor, Publisher or Admin, with the highest grant winning.

About access control →

Roles and permissions (RBAC) →

Autessa includes role-based access control: permissions gate whole areas of the product, built-in roles cover common jobs, and custom roles hold exactly the permissions you choose.

Sharing and access levels →

Every Autessa resource starts private and is shared from one dialog with people, teams, company roles or everyone, each at its own level, and a person gets the highest level of any grant.

Sharing what an app uses →

Sharing an app or agent lists every table, tool and agent it uses, gives each only the access it needs (or the same access as the app), never lowers anyone, and saves everything together or nothing.

Who a run acts as →

Tools, agents, multi-agents and scripts run as the person who started them, into every sub-agent and tool they call, and nothing a run passes along can change who it runs as.

Partner and consultant access →

An agency or consultant gets only what you switch on, usage, spending or working inside your company as Consultants, and nothing is shared until your company accepts.

§3 · DATA PROTECTION

Data protection

Row rules decide which records each person sees, column rules mask or hide fields, per-company keys encrypt sensitive data, and personal data can be stripped before any AI model reads it.

About data protection →

Row-level security (RLS) →

Autessa includes row-level security: AutessaDB roles filter which rows each person, app visitor or API key sees, with placeholders like $CURRENT_USER_TEAMS so one rule works for everyone.

Column-level security and masking →

Autessa includes column-level security: each role sees a column in full, masked (redacted, last four or a stable hash) or not at all, and masked columns can be stored encrypted.

Tenant isolation and encryption →

Every Autessa company is cryptographically separated: sensitive data is encrypted at rest with AES-256 using keys unique to your company, inside storage that is itself encrypted.

PII and PHI stripping for AI →

With PII and PHI stripping on, personal and health data in every prompt becomes a numbered placeholder such as [SSN_1] before it reaches any model, and the real values return in the answer.

Sensitive data in conversations →

Turn on Protect sensitive data for an agent and card numbers, bank details and Social Security numbers become placeholders the AI works with, while allowed tools can still use the real value.

§4 · SECRETS MANAGEMENT

Secrets management

A secret is used, never viewed: tools get a handle, the value is filled in only inside an HTTPS request to an allowed host, and seeing it takes two people.

About secrets management →

Secrets vault →

Autessa Secrets stores credentials your tools can use but nobody can read back: scripts hold an opaque handle, and the value is filled in only inside the outgoing HTTPS request.

Allowed hosts and bound tools →

A secret is sent only over HTTPS to the exact hostnames you list, so even an edited tool cannot send your Stripe key anywhere but Stripe, and binding limits it to the tools you trust.

Sealed secrets and two-person reveal →

Sealed secrets can never be seen by the owner, an admin or support; a Revealable secret is shown once, only after a second person approves a request, and automation can never reveal at all.

Secret rotation and audit log →

Rotating a secret bumps its version while tools keep working by name, and each secret keeps an audit log of every change, share, use, denial and reveal, never the value.

§5 · API AND MACHINE ACCESS

API and machine access

Every credential is company-scoped, owned by a person and never able to reach more than that person, and minting one always happens in the browser.

About api and machine access →

Scoped API keys →

Every Autessa API key belongs to a person, carries its own scope, rate limits and allowed origins, acts as its owner or with its own role, and is re-checked against the owner on every request.

Poweruser and temporary keys →

A poweruser key lets automation act as you, with one permanent key per person, unlimited 15-minute temporary keys, and rotation that kills the old secret immediately.

OAuth clients and CLI sessions →

Autessa acts as an OAuth 2.0 provider for your own apps, the CLI signs in with a short-lived company-scoped session, and minting credentials or changing SSO always needs a person in the browser.

§6 · AUDIT AND EVIDENCE

Audit and evidence

Every read and change of protected data is logged on a verified hash chain, every run keeps its history, and evidence can be sealed write-once with signed hashes.

About audit and evidence →

Data access log →

Autessa includes a tamper-evident data access log: every read, decrypt and change of protected table data, with the person, the key, tool or app it went through, the IP and a verified hash chain.

Execution history →

Every tool execution, agent and manager conversation, trigger firing, scheduled job run and inbound webhook call is recorded with its inputs and outputs, and each run says where it came from.

Evidence vault →

The Autessa evidence vault seals records into write-once storage with a SHA-256 hash for every item and a signed manifest, locks COMPLIANCE seals until their retention date, and logs every view in a chain of custody.

Append-only tables →

An append-only AutessaDB table accepts new rows and reads but rejects every update and delete for every caller, and the setting can be turned on but never off.

Every control, in every company

Sign up and every security control on this page is already on, or one switch away.

Start free

Reports, policies and questionnaires live on the Autessa Trust Center.

100% customizable, code and all

Make Autessa Security & Compliance 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